Verwalten von Benutzern und Gruppen mit SCIM¶
Unter diesem Thema wird Folgendes beschrieben:
SCIM-Integrationen mit Snowflake
SCIM-Anwendungsfälle mit Snowflake
Verwenden der Snowflake-SCIM-APIs, um Anforderungen an einen Identitätsanbieter zu stellen.
Übersicht zu SCIM¶
SCIM ist eine offene Spezifikation zur Vereinfachung der automatisierten Verwaltung von Benutzeridentitäten und -gruppen (d. h. Rollen) in Cloudanwendungen mithilfe von RESTful-APIs.
Diese APIs verwenden gängige Methoden (z. B. GET, POST) mit Schlüssel-Wert-Paar-Attributen im JSON-Format. Die Benutzerattribute sind für den Benutzer eindeutig. Ebenso sind die Gruppenattribute für die Gruppe eindeutig.
Derzeit unterstützt Snowflake SCIM 2.0 die Integration von Snowflake in Okta und Microsoft Azure AD, die beide als Identitätsanbieter fungieren. Snowflake unterstützt auch Identitätsanbieter, die weder Okta noch Microsoft Azure (d. h. kundenspezifisch) sind. Benutzer und Gruppen des Identitätsanbieters können in Snowflake bereitgestellt werden, wobei Snowflake als Dienstanbieter fungiert.
Wichtig
Die spezifische SCIM-Rolle in Snowflake muss über alle Benutzer und Rollen verfügen, die vom Identitätsanbieter importiert werden. Wenn die Snowflake-SCIM-Rolle nicht Eigentümer der importierten Benutzer oder Rollen ist, werden Aktualisierungen beim Identitätsanbieter nicht mit Snowflake synchronisiert. Die Snowflake-SCIM-Rolle ist spezifisch für den Identitätsanbieter (IdP) und lautet wie folgt:
Okta-SCIM-Rolle:
okta_provisioner
Azure AD-SCIM-Rolle:
aad_provisioner
Kundenspezifische SCIM-Rolle:
generic_scim_provisioner
Weitere Informationen zur Verwendung der Snowflake-SCIM-Rolle finden Sie in den Abschnitten zur SCIM-Konfiguration für Okta, Azure AD und die kundenspezifische SCIM-Integration.
Der Identitätsanbieter verwendet einen SCIM-Client, um die RESTful-API-Anforderung an den Snowflake-SCIM-Server zu richten. Nach Überprüfung der API-Anforderung führt Snowflake Aktionen für den Benutzer oder die Gruppe aus.
Der Authentifizierungsprozess verwendet ein OAuth-Bearer-Token, das sechs Monate gültig ist. Kunden müssen ihr Authentifizierungstoken im Blick behalten und können bei Bedarf ein neues Token generieren. Bei jeder API-Anforderung wird das Token als Autorisierungs-Bearer-Parameter an den Header übergeben.
Nach der ersten Snowflake-SCIM-Konfiguration können Sie die Snowflake-SCIM-API verwenden, um die folgenden Anwendungsfälle zu behandeln:
User Lifecycle Management
Zuordnen von Active Directory-Gruppen zu Snowflake-Rollen
Vorsicht
Derzeit können Administratoren mithilfe der Snowflake-SCIM-API Benutzer und Gruppen des Identitätsanbieter des Kunden für Snowflake verwalten.
Wenn Sie die Snowflake-SCIM-API für die Verwaltung der Benutzer- und Gruppenidentitäten und für die Zugriffsverwaltung verwenden, nehmen Sie keine Benutzer- und Gruppenänderungen in Snowflake vor, da diese Änderungen nicht mit dem benutzerspezifischen Identitätsanbieter synchronisiert werden.
SCIM-Anwendungsfälle¶
Die Snowflake-SCIM-API kann die folgenden Anwendungsfälle behandeln.
- Benutzer verwalten:
Administratoren können ihre Benutzer vom Identitätsanbieter ihrer Organisation für Snowflake bereitstellen und verwalten lassen. Die Benutzerverwaltung ist eine Eins-zu-Eins-Zuordnung vom Identitätsanbieter zu Snowflake.
- Rollen verwalten:
Administratoren können ihre Gruppen (d. h. Rollen) vom Identitätsanbieter ihrer Organisation für Snowflake bereitstellen und verwalten lassen. Die Rollenverwaltung ist eine Eins-zu-Eins-Zuordnung vom Identitätsanbieter zu Snowflake.
- Überwachung:
Administratoren können die Tabelle
rest_event_history
abfragen, um festzustellen, ob der Identitätsanbieter Aktualisierungen (d. h. SCIM-API-Anforderungen) an Snowflake sendet.
Verwalten von Benutzern mit SCIM¶
Snowflake unterstützt die Verwaltung des Benutzerlebenszyklus mit SCIM-APIs. Die Verwaltung des Benutzerlebenszyklus ist eine administrative Aktivität, die mit dem Weg übereinstimmt, den der Benutzer während seiner Tätigkeit im Unternehmen nimmt. Häufige Ereignisse im Lebenszyklus des Benutzers sind folgende Aktivitäten.
Erstellen und Aktivieren des Benutzers
Aktualisieren von Benutzerattributen, z. B.
email
oderpassword
Deaktivieren eines Benutzers bei Ausscheiden
In Snowflake erfordert die Automatisierung des Benutzerlebenszyklus mithilfe von SCIM die Übergabe von Benutzerattributen im Hauptteil der API-Anforderung. Eine erfolgreiche API-Anforderung des Identitätsanbieters wirkt sich fast unmittelbar auf den Benutzer in Snowflake aus.
Benutzerattribute¶
Benutzerattribute sind die Schlüssel-Wert-Paare, die dem Benutzer zugeordnet sind. Diese Paare sind Informationen über den Benutzer, wie z. B. sein Anzeigename und seine E-Mail-Adresse. Identitätsanbieter definieren Attributschlüssel manchmal anders, z. B. surname
, familyName
oder lastName
, die alle für den Nachnamen des Benutzers stehen. Snowflake unterstützt keine mehrwertigen Benutzerattribute.
Die Snowflake-SCIM-API übergibt Benutzerattribute im JSON-Format, die in den entsprechenden Benutzer-API-Beispielen gezeigt werden.
Snowflake unterstützt die folgenden SCIM-Attribute für die Verwaltung des Benutzerlebenszyklus. Attribute sind beschreibbar, sofern nicht anders angegeben.
Wichtig
In der Tabelle werden die Snowflake-Attribute userName
und loginName
beide dem SCIM-Attribut userName
zugeordnet. Snowflake unterstützt verschiedene Werte für das Snowflake-Attribut von userName
und loginName
. Durch diese Attributwerttrennung können Kunden genauer steuern, welcher Attributwert für den Zugriff auf Snowflake verwendet werden kann.
Weitere Informationen dazu finden Sie in den Beispielen für Benutzer-API für POST und PATCH.
SCIM-Benutzerattribut |
Snowflake-Benutzerattribut |
Typ |
Beschreibung |
---|---|---|---|
|
|
string |
Der unveränderliche, eindeutige Bezeichner (d. h. GUID) des Benutzers in Snowflake. Snowflake zeigt diesen Wert weder in der DESCRIBE USER- noch in der SHOW USERS-Ausgabe an. Bei bestimmten Anforderungspfaden, die dieses Attribut enthalten (z. B. PATCH), kann Überprüfen Sie die IdP-Protokolle, um sicherzustellen, dass die Werte übereinstimmen. |
|
|
string |
Der Bezeichner für die Anmeldung bei Snowflake. Weitere Informationen zu diesen Snowflake-Attributen finden Sie unter CREATE USER. |
|
|
string |
Der Vorname des Benutzers. |
|
|
string |
Der Nachname des Benutzers. |
|
|
string |
Die E-Mail Adresse des Benutzers. Der Wert unterstützt eine einzelne E-Mail-Adresse. |
|
|
string |
Der Name, den die Benutzeroberfläche für den Benutzer anzeigt. |
|
N/A |
string |
Der vom Bereitstellungsclient (z. B. Azure, Okta) festgelegte eindeutige Bezeichner. |
|
|
string |
Das Kennwort für den Benutzer. Dieser Wert wird in der JSON-Antwort nicht zurückgegeben. Hinweis: Wenn die Eigenschaft |
|
|
Boolean |
Deaktiviert den Benutzer, wenn |
|
N/A |
string |
Eine Liste von Gruppen, zu denen der Benutzer gehört. Die Gruppe „displayName“ ist erforderlich. Die Benutzergruppen sind schreibgeschützt. Die Mitgliedschaft muss über die SCIM-Gruppen-API aktualisiert werden. |
|
|
string |
Der Zeitpunkt, zu der der Benutzer zu Snowflake hinzugefügt wurde. |
|
|
string |
Der Zeitpunkt, zu der der Benutzer zuletzt in Snowflake geändert wurde. |
|
N/A |
string |
„Users“ sollten einen „user“-Wert haben. |
|
N/A |
string |
Ein durch Kommas getrenntes Array von Zeichenfolgen, das die Namespace-URIs angibt. Zu den unterstützten Werten gehören:
|
Kundenspezifische Attribute¶
Snowflake unterstützt das Festlegen von kundenspezifischen Attributen, die nicht durch RFC 7643 definiert sind, wie defaultRole
, defaultWarehouse
und defaultSecondaryRoles
.
Derzeit unterstützt Snowflake die Verwendung von zwei Namespaces, um kundenspezifische Attribute für die folgenden POST-, PUT- und PATCH API-Anforderungen festzulegen:
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User
Dieser Namespace war Teil der ursprünglichen SCIM-Implementierung in Snowflake und kann nur verwendet werden, um kundenspezifische Attribute für Okta-SCIM-Integrationen festzulegen.
Dieser Namespace wird nicht unterstützt, um kundenspezifische Attribute für Microsoft Azure-SCIM-Integrationen oder kundenspezifische SCIM-Integrationen festzulegen.
urn:ietf:params:scim:schemas:extension:2.0:User
Dieser neuere Namespace kann zum Festlegen von kundenspezifischen Attributen für alle SCIM-Integrationen verwendet werden und muss für kundenspezifische Attribute entweder mit einer kundenspezifischen SCIM-Integration oder einer Microsoft Azure-SCIM-Integration verwendet werden.
Benutzer-APIs¶
Snowflake unterstützt die folgenden APIs, um die Verwaltung des Benutzerlebenszyklus zu vereinfachen. Sie können Benutzerinformationen mit Filtern abrufen und Benutzer erstellen, aktualisieren, deaktivieren und löschen.
Zweck |
Methode und API |
Anmerkungen |
---|---|---|
Überprüfen, ob ein Benutzer existiert |
|
Gibt bei Erfolg Details des Benutzerkontos mit dem entsprechenden |
Details zu einem bestimmten Benutzer abrufen |
|
Gibt bei Erfolg Details des Benutzerkontos mit dem entsprechenden |
Details zu einem bestimmten Benutzer abrufen |
|
Gibt bei Erfolg einen Beispielbenutzer zurück, damit der SCIM-Client das Schema lesen kann, sowie den HTTP-Statuscode |
Benutzer erstellen |
|
Erstellt einen Benutzer in Snowflake und gibt bei Erfolg den HTTP-Statuscode Wenn der Benutzer bereits existiert oder ein anderer Konflikt auftritt, gibt Snowflake den HTTP-Statuscode |
Benutzer mit Teilattributen aktualisieren |
|
Deaktiviert den entsprechenden Benutzer, wenn der Schlüssel Um einen aktuell deaktivierten Benutzer zu aktivieren, setzen Sie PATCH erfordert einen Operationsschlüssel (d. h. Gibt bei Erfolg den HTTP-Statuscode |
Benutzer aktualisieren. |
|
Prüft, ob ein Benutzer mit der angegebenen Andernfalls werden die Schreib- oder Leseattribute basierend auf der Anforderung ersetzt. Gibt den HTTP-Statuscode |
Benutzer löschen |
|
Weitere Informationen zu SCIM-API-Anforderungen finden Sie unter Erstellen einer SCIM-API-Anforderung.
POST scim/v2/Users¶
Benutzer mit
userName
undloginName
erstellen, die demselben Wert zugeordnet sind{ "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:2.0:User" ], "userName": "test_user_1", "password": "test", "name": { "givenName": "test", "familyName": "user" }, "emails": [{ "value": "test.user@snowflake.com" } ], "displayName": "test user", "active": true }Benutzer mit
userName
undloginName
erstellen, die unterschiedlichen Werten zugeordnet sindWenn Okta Ihr Identitätsanbieter ist, führen Sie diese Schritte aus.
{ "active": true, "displayName": "test user", "emails": [ { "value": "test.user@snowflake.com" } ], "name": { "familyName": "test_last_name", "givenName": "test_first_name" }, "password": "test_password", "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" ], "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "snowflakeUserName": "USER5" }, "userName": "USER5" }
PATCH scim/v2/Users/{ID}¶
Benutzer mit
userName
undloginName
aktualisieren, die demselben Wert zugeordnet sind.{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op": "replace", "value": { "active": false } }] }Benutzer mit
userName
undloginName
aktualisieren, die verschiedenen Werten zugeordnet sind.Wenn Okta Ihr Identitätsanbieter ist, führen Sie diese Schritte aus.
{ "Operations": [ { "op": "Replace", "path": "userName", "value": "test_updated_name" }, { "op": "Replace", "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.snowflakeUserName", "value": "USER5" } ], "schemas": [ "urn:ietf:params:scim:api:messages:2.0:PatchOp" ] }
PUT scim/v2/Users/{ID}¶
Aktualisieren Sie einen Benutzer, einschließlich der Einstellungen in den Feldern "defaultRole"
, "defaultSecondaryRoles"
und "defaultWarehouse"
.
Um die Eigenschaften "defaultRole"
, "defaultSecondaryRoles"
und "defaultWarehouse"
zu spezifizieren, benötigt Snowflake unbedingt eines der extension
-Schemas. Beachten Sie, dass der einzig mögliche Wert für defaultSecondaryRoles
der Wert "ALL"
ist.
Bemerkung
Obwohl Snowflake dies unterstützt, sollten Sie bei Verwendung der PUT-Operation vorsichtig sein, da sie teurer ist als eine PATCH-Operation. Verwenden Sie stattdessen die Operation PATCH.
{ "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" ], "userName": "test_user_1", "password": "test", "name": { "givenName": "test", "familyName": "user" }, "emails": [{ "primary": true, "value": "test.user@snowflake.com", "type": "work" } ], "displayName": "test user", "active": true, "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "defaultRole" : "test_role", "defaultSecondaryRoles" : "ALL", "defaultWarehouse" : "test_warehouse" } }
Verwalten von Rollen mit SCIM¶
Snowflake unterstützt die Verwendung von SCIM zum Importieren von Rollen aus Okta, Azure AD und kundenspezifischen Anwendungen. Es gibt eine direkte Eins-zu-Eins-Zuordnung dieser Rollen zu Snowflake-Rollen.
Rollen, die normalerweise mit Gruppen synonym sind, sind eine logische Sammlung von Zugriffsrechte. Im Snowflake-Modell ist der Zugriff auf sicherungsfähige Objekte über Berechtigungen erlaubt, die den Rollen zugewiesen sind, die wiederum anderen Rollen oder Benutzern zugewiesen sind.
Zugriffsberechtigungen und Rechte, die der Rolle zugewiesen werden, werden automatisch von jedem Mitglied (d. h. Benutzer) der Rolle übernommen. Weitere Informationen dazu finden Sie unter Übersicht zur Zugriffssteuerung.
Während sich Benutzer in ihrem Unternehmen beruflich weiterentwickeln, können sich ihre Zugriffsanforderungen auf Snowflake ändern. Beispielsweise kann ein Benutzer von einem einzelnen Mitarbeiter zu einem Manager mit direkten Berichten wechseln. Bei einem Rollenwechsel muss der Zugriff in Snowflake möglicherweise auch Datasets zulassen, die nur Vorgesetzten zur Verfügung stehen.
Wenn sich die Rollenmitgliedschaft des Benutzers in seiner Organisation ändert, kann sich der Zugriff auf Snowflake automatisch ändern, sobald seine Organisationsrollen der entsprechenden Snowflake-Rolle zugeordnet sind.
Rollenattribute¶
Die Snowflake-SCIM-API übergibt Rollenattribute im JSON-Format, die in den entsprechenden API-Beispielen gezeigt werden.
Snowflake unterstützt die folgenden SCIM-Attribute für die Verwaltung des Rollenlebenszyklus. Attribute sind beschreibbar, sofern nicht anders angegeben.
SCIM-Gruppenattribut |
Snowflake-Gruppenattribut |
Typ |
Beschreibung |
---|---|---|---|
|
|
String |
Der unveränderliche, eindeutige Bezeichner (d. h. GUID) der Rolle in Snowflake. Snowflake zeigt diesen Wert nicht an. Er kann durch Aufruf der Information Schema-Tabellenfunktion REST_EVENT_HISTORY ermittelt werden. Überprüfen Sie die IdP-Protokolle, um sicherzustellen, dass die Werte übereinstimmen. |
|
|
String |
Der Name, den die Benutzeroberfläche für die Rolle anzeigt. |
|
N/A |
String |
Der userID-Wert des Benutzers, der Mitglied der Rolle ist. |
|
N/A |
String |
Ein Array von Zeichenfolgen zur Angabe der Namespace-URIs. Beispiel: |
Rollen-APIs¶
Sie können Rolleninformationen mit Filtern abrufen und auch eine Rolle erstellen, die Rollenmitgliedschaft aktualisieren und eine Rolle löschen. Snowflake unterstützt die folgenden APIs, um die Rollenverwaltung zu vereinfachen.
Zweck |
Methode und API |
Anmerkungen |
---|---|---|
Gruppe nach Anzeigenamen abrufen |
|
Gibt bei Erfolg die Details der Gruppe mit dem angegebenen |
Gruppe anhand ihrer Gruppen-ID ( |
|
Gibt bei Erfolg die Details der Gruppe mit dem angegebenen |
Beispielgruppe abrufen |
|
Gibt bei Erfolg eine Beispielgruppe zurück, damit der SCIM-Client das Schema lesen kann, sowie den HTTP-Statuscode |
Neue Gruppe erstellen |
|
Erstellt bei Erfolg eine neue Gruppe mit dem HTTP-Statuscode |
Gruppe aktualisieren |
|
Aktualisiert das Attribut für den Gruppenanzeigenamen oder die Gruppenmitgliedschaft. PATCH erfordert einen Operationsschlüssel (d. h. Gibt bei Erfolg den HTTP-Statuscode |
Gruppe löschen |
|
Weitere Informationen zu SCIM-API-Anforderungen finden Sie unter Erstellen einer SCIM-API-Anforderung.
POST scim/v2/Groups¶
{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"], "displayName":"scim_test_group2" }
PATCH scim/v2/Groups/{ID}¶
{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op": "replace", "value": { "displayName": "updated_name" } }, { "op" : "remove", "path": "members[value eq \"user_id_1\"]" }, { "op": "add", "value": [{ "value": "user_id_2" }] } ] }
Überwachen mit SCIM¶
Es ist möglich, Snowflake abzufragen, um festzustellen, welche SCIM-API-Anforderungen in einem bestimmten Zeitintervall gestellt wurden.
Mithilfe dieser Informationen kann beispielsweise festgestellt werden, ob die aktive Benutzergruppe der Organisation, die in Snowflake bereitgestellt werden soll, mit den in Snowflake bereitgestellten Benutzern übereinstimmt.
Die unten aufgeführten SQL-Anweisungen sind ein repräsentatives Beispiel für den Aufruf der Information Schema-Tabellenfunktion REST_EVENT_HISTORY, um zu ermitteln, welche SCIM-REST-API-Anforderungen in den letzten fünf Minuten (bis zu 200 Anforderungen) gestellt wurden.
use role accountadmin;
use database demo_db;
use schema information_schema;
select *
from table(rest_event_history(
'scim',
dateadd('minutes',-5,current_timestamp()),
current_timestamp(),
200))
order by event_timestamp;
Weitere Informationen zum Ändern dieser Abfrage finden Sie unter den Funktionen DATEADD und CURRENT_TIMESTAMP.
Unterstützte SCIM-Integrationen¶
Snowflake kann in die folgenden Identitätsanbieter integriert werden, um Benutzer und Gruppen für Snowflake bereitzustellen, zu verwalten und zu synchronisieren.
Okta
Microsoft Azure Active Directory
Kundenspezifisch
Bemerkung
Kundenspezifische SCIM-Integrationen ermöglichen Identitätsanbietern ohne dedizierte Integration, Benutzer und Gruppen in Snowflake bereitzustellen, zu verwalten und zu synchronisieren.
Derzeit sollte die kundenspezifische SCIM-Integration für Identitätsanbieter verwendet werden, die weder Okta noch Microsoft Azure AD sind.
Kunden, die Okta als Identitätsanbieter verwenden, sollten unter Okta-SCIM-Integration mit Snowflake beschriebenen Anweisungen befolgen.
Kunden, die Microsoft Azure Active Directory als Identitätsanbieter verwenden, sollten die unter Azure-SCIM-Integration mit Snowflake beschriebenen Anweisungen befolgen.
Kunden, die Okta oder Microsoft Azure Active Directory nicht als Identitätsanbieter verwenden, sollten ihren eigenen SCIM-Client erstellen und dann die Anweisungen unter Kundenspezifische SCIM-Integration mit Snowflake befolgen.
Verwenden der Replikation mit SCIM¶
Snowflake unterstützt Replikation und Failover/Failback der SCIM-Sicherheitsintegration vom Quellkonto in das Zielkonto.
Weitere Details dazu finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.
Nächste Themen: