Gérer les attributs d'identité avec le SCIM du compte
L'API du système de gestion des identités inter-domaines (SCIM) 2.1 du compte provisionne les neuf attributs d'identité aux utilisateurs du compte Databricks, soit via un connecteur de provisionnement, soit directement.
Bêta
Cette fonctionnalité est en version bêta. Les administrateurs de compte peuvent gérer l'accès à cette fonctionnalité depuis la page Aperçus de la console de compte. Consultez Gérer les aperçus au niveau du compte.
Databricks recommande la gestion automatique des identités plutôt que SCIM pour gérer les attributs d’identité. Pour plus d’informations, consultez Gestion automatique des identités.
Prérequis
- Vous devez être administrateur de compte.
- Configurez le provisionnement SCIM au niveau du compte pour votre compte. Voir Synchroniser les utilisateurs et les groupes avec votre compte Databricks.
- Les attributs d’identité sont gérés sur SCIM 2.1 du compte , à
https://accounts.cloud.databricks.com/api/2.1/accounts/<account-id>/scim/v2/. Il s’agit de la seule interface qui lit et écrit l’ensemble complet des attributs. - Vous n'avez pas besoin d'activer l'aperçu de la fonctionnalité Identity Attribute Control List pour écrire des attributs via SCIM. Si l'aperçu est activé, assurez-vous que les attributs que vous avez l'intention de pousser figurent dans l'Identity Attribute Control List de votre compte, sinon l'écriture sera rejetée. Voir Identity Attribute Control List.
Configurer un connecteur SCIM
Les attributs d'identité atteignent Databricks depuis votre fournisseur d'identité soit via un connecteur de provisionnement SCIM qui les pousse, soit via la gestion automatique des identités, qui les extrait. Cette section couvre la route du connecteur pour Okta et Microsoft Entra ID.
Pour les deux fournisseurs, le travail est globalement le même : étendre le schéma sortant du fournisseur afin qu'il reconnaisse l'existence des neuf attributs Databricks, mapper chacun d'eux à un attribut source sur le profil utilisateur, puis synchroniser. Vous pouvez mettre à jour votre application de connecteur SCIM existante pour ce faire ; vous n’avez pas besoin de créer une nouvelle application dans votre fournisseur d’identité.
Okta
Créez d'abord l'application de connecteur SCIM Databricks, en suivant la configuration Okta standard pour Databricks. Étendez ensuite son schéma sortant.
- Accédez à Applications > votre application Databricks > Provisionnement > Vers l’application , puis ouvrez Accéder à l’éditeur de profil .
- Choisissez Add Attribute et ajoutez les neuf attributs dans le tableau suivant. Les neuf sont du type de données string .
- Pour External namespace , utilisez
urn:ietf:params:scim:schemas:core:2.0:Userpour les cinq premiers attributs (de Title à Work Country) eturn:ietf:params:scim:schemas:extension:enterprise:2.0:Userpour les quatre derniers (de Cost Center à Department). - Revenez à la tab Provisioning et modifiez la section Mappings pour associer chaque attribut Databricks à l’attribut de profil utilisateur Okta dont il doit provenir.
Le nom externe et l’ espace de noms externe sont ce qu’Okta envoie sur le réseau ; ils doivent donc correspondre exactement aux chemins SCIM.
Nom d’affichage | Nom de variable | Nom externe |
|---|---|---|
Titre |
|
|
Type d'utilisateur |
|
|
Localité de travail |
|
|
Région de travail |
|
|
Pays de travail |
|
|
Centre de coûts |
|
|
Organisation |
|
|
Division |
|
|
Département |
|
|
Pour tester le résultat, créez un utilisateur sous Annuaire > Personnes > Ajouter une personne , définissez les attributs mappés sur son profil, puis affectez-le à l'application sous l'onglet tab . Ouvrez l'onglet Provisionnement et choisissez Forcer la synchronisation si vous avez besoin que les attributs soient synchronisés immédiatement. Les attributs apparaissent sur l'utilisateur dans la console de compte Databricks en environ cinq minutes.
Le connecteur Okta se comporte comme suit :
- Les valeurs d'attribut sont sensibles à la casse et sont stockées exactement telles qu'elles ont été envoyées.
- Les symboles
_,-,.et les espaces se synchronisent sans problème. - Les attributs de type tableau ne sont pas pris en charge. Le mappage de l'un produit une erreur dans Okta et la valeur dans Databricks est laissée inchangée. Cela s'applique même à un tableau à un seul élément.
Microsoft Entra ID
Créez l'application de provisionnement SCIM dans Microsoft Entra ID en suivant la configuration standard de Microsoft Entra ID pour Databricks.
L'éditeur de schéma n'est pas exposé par default. Ajoutez ?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true à l'URL du portail et conservez ce paramètre pour toute la session de configuration. Sans cela, l'option Modifier le schéma n'apparaîtra pas.
-
Ouvrez votre application et accédez à Provisionnement > Attribute mapping .
-
Sous Options avancées , choisissez Modifier les attributs utilisateur Databricks .
-
Ajoutez les neuf attributs suivants, tous de type String :
titleuserTypeaddresses[type eq "work"].localityaddresses[type eq "work"].regionaddresses[type eq "work"].countryurn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenterurn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organizationurn:ietf:params:scim:schemas:extension:enterprise:2.0:User:divisionurn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department
-
Revenez à l'écran de mappage d'attributs et choisissez Add Attribute Mapping pour chaque attribut, en utilisant un type de mappage Direct et les attributs source dans le tableau suivant.
Microsoft Entra ID ne dispose pas de champ source natif pour le centre de coûts ou la division ; laissez donc ces deux champs non mappés, sauf si vous disposez d'un attribut d'extension personnalisé ou d'une expression appropriée pour les lier.
Cible Databricks | Attribut source Microsoft Entra ID |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| non mappé |
| non mappé |
Pour tester, créez un utilisateur sous Users > New User et renseignez les champs mappés. Ajoutez-les à l'application sous Provisionnement > Users and Groups , puis ouvrez Provision on demand et sélectionnez l'utilisateur. Les attributs apparaissent ensuite sous l'onglet Identity attributes de l'utilisateur dans la console de compte Databricks. Effacer la valeur d'un attribut sur l'utilisateur Microsoft Entra ID et effectuer à nouveau un provisionnement à la demande supprime la valeur dans Databricks, afin que les deux côtés restent synchronisés.
Si un connecteur précédemment sain commence à échouer après l'activation ou la restriction de la liste de contrôle des attributs, la cause est presque toujours que le connecteur continue de pousser un attribut que le compte n'autorise plus. Databricks rejette l'intégralité de la requête avec un 400, la synchronisation échoue donc au lieu de s'appliquer partiellement. Pour corriger ce problème, ajoutez à nouveau l'attribut à la liste de contrôle ou supprimez cet attribut du mappage du connecteur, puis forcez une nouvelle synchronisation. Un connecteur qui renvoie une valeur inchangée n'est pas rejeté, car l'application ne concerne que les valeurs qui changent réellement. Voir Identity Attribute Control List.
Gérer les attributs avec l’API SCIM
Les attributs d'identité sont gérés sur le compte SCIM 2.1. Cinq des attributs se trouvent sur le schéma utilisateur principal SCIM, et les quatre autres se trouvent sur l'extension utilisateur d'entreprise standard, dont l'URN est urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.
Attribut | Où il se trouve dans SCIM |
|---|---|
| Utilisateur Core : |
| Utilisateur Core : |
| Utilisateur Core : |
| Utilisateur Core : |
| Utilisateur Core : |
| Extension Entreprise : |
| Extension Entreprise : |
| Extension Entreprise : |
| Extension Entreprise : |
Dans les requêtes et les réponses, les quatre attributs d'entreprise sont adressés par leur chemin complet. Par exemple, urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter.
Créer un utilisateur avec des attributs d'identité
POST /api/2.1/accounts/<account-id>/scim/v2/Users
Authorization: Bearer <token>
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "jane.doe@example.com",
"displayName": "Jane Doe",
"title": "Staff Engineer",
"userType": "Employee",
"addresses": [
{ "locality": "Mountain View", "region": "CA", "country": "US" }
],
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"costCenter": "4130",
"organization": "Databricks",
"division": "Platform",
"department": "Identity"
}
}
Databricks répond 201 Created avec l’enregistrement utilisateur complet. La forme de la réponse présente les caractéristiques suivantes :
schemasannonce toujours à la fois l’URN utilisateur principal et l’URN d’extension d’entreprise, même lorsqu’aucun attribut d’entreprise n’est défini.- Les attributs sans valeur stockée sont entièrement omis plutôt que renvoyés sous la forme
null. - Une seule adresse est stockée par utilisateur, donc
addressescontient toujours un seul élément. Databricks les marque automatiquement"type": "work"et"primary": true; les deux sont en lecture seule et ne peuvent pas être mappés à partir d’un fournisseur d’identité. - Le SCIM 2.1 de compte ne renvoie pas
metaouentitlementssur les utilisateurs.
Lire les attributs d’identité
GET /api/2.1/accounts/<account-id>/scim/v2/Users/<user-id>
Authorization: Bearer <token>
La réponse a la même forme que la réponse de création. Les lectures ne sont jamais filtrées par la liste de contrôle des attributs . Un attribut stocké précédemment reste entièrement visible sur un GET même après avoir été supprimé de la liste de contrôle. Seules les écritures sont contrôlées.
Mettre à jour les attributs d’identité
Les trois formes d'opération PATCH (add, replace et remove) fonctionnent pour chaque attribut, y compris les chemins d'entreprise entièrement qualifiés.
PATCH /api/2.1/accounts/<account-id>/scim/v2/Users/<user-id>
Authorization: Bearer <token>
Content-Type: application/scim+json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{ "op": "replace", "path": "title", "value": "Principal Engineer" },
{ "op": "replace", "path": "userType", "value": "Contractor" },
{
"op": "replace",
"path": "addresses",
"value": [{ "locality": "Seattle", "region": "WA", "country": "US" }]
},
{
"op": "replace",
"path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter",
"value": "9001"
}
]
}
Databricks répond 200 OK avec l'utilisateur mis à jour. addresses est remplacé en tant que valeur complexe entière, envoyez donc tous les sous-champs que vous souhaitez conserver. Omettre country de la valeur ci-dessus l'effacerait.
Supprimer les attributs d’identité
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{ "op": "remove", "path": "userType" },
{
"op": "remove",
"path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:division"
}
]
}
Databricks répond 200 OK, et les attributs supprimés n'apparaissent plus dans l'enregistrement utilisateur. Les suppressions réussissent toujours, indépendamment de l'Identity Attribute Control List ; un administrateur peut donc toujours retirer une valeur stockée, y compris pour un attribut que le compte n'est plus autorisé à écrire.
Lorsque la liste de contrôle des attributs rejette une écriture
Une fois votre compte inscrit à la préversion de la liste de contrôle des attributs d'identité, l'écriture d'un attribut qui ne figure pas sur la liste est rejetée. Par exemple, l'envoi de {"op": "replace", "path": "userType", "value": "Vendor"} lorsque userType est hors de la liste renvoie 400 Bad Request:
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"status": "400",
"scimType": "invalidValue",
"detail": "The following identity attributes are not on this account's attribute control list and cannot be created or updated: userType. Add them to the control list, or remove them from the request. Existing values can still be removed."
}
Avant d'effectuer l'intégration, comprenez les comportements d'application suivants :
- L'application est effectuée par attribut, et non par schéma. Un attribut d’entreprise hors liste tel que
divisionest rejeté, même lorsque d’autres attributs d’entreprise dans la même requête sont autorisés. - Un PATCH est atomique. Si une opération cible un attribut hors liste, l’ensemble de la requête est rejeté et aucune des modifications autorisées n’est appliquée. La validation s’exécute avant que l’enregistrement utilisateur ne soit modifié.
- Seules les valeurs modifiées sont vérifiées. Le renvoi d'une valeur identique à celle stockée est une opération nulle (no-op) et est acceptée même pour un attribut hors liste. Ceci est important pour les connecteurs de fournisseur d'identité, qui renvoient les valeurs inchangées à chaque synchronisation.
- Les sous-champs d’adresse sont vérifiés individuellement.
locality,regionetcountrynécessitent chacun leur propre entrée dans la liste de contrôle.
Pour savoir comment configurer la liste, consultez Liste de contrôle des attributs d'identité.
Découvrir les attributs pris en charge
GET /api/2.1/accounts/<account-id>/scim/v2/Schemas renvoie un ListResponse SCIM. Lorsque les attributs d’identité sont activés pour la surface, elle contient quatre ressources de schéma : User (qui prend en charge les attributs supplémentaires décrits sur cette page), Group, ServicePrincipal et l’extension utilisateur d’entreprise.
Le schéma utilisateur principal annonce title, userType et addresses. Au sein de addresses, les trois sous-attributs provenant du fournisseur d’identité sont readWrite, tandis que type et primary sont readOnly car Databricks les définit :
{
"name": "addresses",
"type": "complex",
"multiValued": true,
"description": "A physical mailing address for this user.",
"mutability": "readWrite",
"returned": "default",
"subAttributes": [
{ "name": "locality", "type": "string", "mutability": "readWrite" },
{ "name": "region", "type": "string", "mutability": "readWrite" },
{ "name": "country", "type": "string", "mutability": "readWrite" },
{ "name": "type", "type": "string", "mutability": "readOnly", "canonicalValues": ["work"] },
{ "name": "primary", "type": "boolean", "mutability": "readOnly" }
]
}
L’extension d’entreprise est également résolvable seule sur GET /api/2.1/accounts/<account-id>/scim/v2/Schemas/urn:ietf:params:scim:schemas:extension:enterprise:2.0:User, ce qui renvoie les quatre attributs d’entreprise sous forme de chaînes readWrite :
{
"id": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
"name": "EnterpriseUser",
"description": "Enterprise User",
"attributes": [
{ "name": "costCenter", "type": "string", "mutability": "readWrite" },
{ "name": "department", "type": "string", "mutability": "readWrite" },
{ "name": "division", "type": "string", "mutability": "readWrite" },
{ "name": "organization", "type": "string", "mutability": "readWrite" }
],
"meta": { "resourceType": "Schema" }
}
La sortie /Schemas est statique. Il n’est pas affecté par la liste de contrôle des attributs ni par ce qu’un utilisateur individuel a défini. Il reflète uniquement si la surface gère ou non les attributs d’identité.
Lire vos propres attributs
Le SCIM de compte pour les Workspace est servi depuis l'hôte du Workspace à l'adresse https://<workspace-host>/api/2.0/account/scim/v2/. Cette surface n’expose pas les attributs d’identité en lecture ou en écriture, et les administrateurs de workspace ne sont pas autorisés à lire ou à modifier les attributs d’identité d’autres utilisateurs.
Les écritures sur les attributs d’identité sur cette surface renvoient 2xx mais sont ignorées silencieusement , et non rejetées. Une réponse réussie ne signifie pas que l’attribut a été stocké. Pour écrire des attributs d’identité, utilisez SCIM 2.1 de compte. Consultez Gérer les attributs avec l’API SCIM.
/Me est la seule exception. Comme il ne renvoie que le profil de l’appelant, un utilisateur peut y lire ses propres attributs d’identité :
GET /api/2.0/account/scim/v2/Me
Authorization: Bearer <workspace-token>
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
"id": "1234567890123456",
"userName": "jane.doe@example.com",
"displayName": "Jane Doe",
"active": true,
"emails": [{ "type": "work", "primary": true, "value": "jane.doe@example.com" }],
"name": { "givenName": "Jane", "familyName": "Doe" },
"title": "Staff Engineer",
"userType": "Employee",
"addresses": [
{
"locality": "Mountain View",
"region": "CA",
"country": "US",
"type": "work",
"primary": true
}
],
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"costCenter": "4130",
"organization": "Databricks",
"division": "Platform",
"department": "Identity"
},
"groups": [{ "value": "987654321098765", "display": "engineering" }]
}
Gardez à l'esprit les points suivants concernant /Me:
/Meest en lecture seule ici.POST,PUT,PATCHetDELETErenvoient501avec"detail": "Endpoint not supported."groupsest toujours renvoyé sur/Me, contrairement à une lecture d'utilisateur administratif.- La liste de contrôle des attributs n’a aucun effet sur
/Me, car la liste régit les écritures et/Mene peut pas écrire. - Le SCIM au niveau du Workspace (
/api/2.0/preview/scim/v2/) est une API différente qui n’expose jamais les attributs d’identité au niveau du compte sur aucun Endpoint, y compris son propre/Me.