Verwalten von Benutzern und Gruppen mit SCIM

Unter diesem Thema wird Folgendes beschrieben:

  1. SCIM-Integrationen mit Snowflake

  2. SCIM-Anwendungsfälle mit Snowflake

  3. Verwenden der Snowflake-SCIM-APIs, um Anforderungen an einen Identitätsanbieter zu stellen.

SCIM-Übersicht

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. benutzerdefiniert) 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

  • Benutzerdefinierte 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 benutzerdefinierte 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:

  1. User Lifecycle Management

  2. 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.

  1. Erstellen und Aktivieren des Benutzers

  2. Aktualisieren von Benutzerattributen, z. B. email oder password

  3. 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

id

id

Zeichenfolge

Der unveränderliche, eindeutige Bezeichner (d. h. GUID) des Benutzers in Snowflake. . Snowflake legt diesen Wert in der Ausgabe von DESCRIBE USER oder SHOW USERS nicht offen. . Für bestimmte Anforderungspfade, die dieses Attribut enthalten (z. B. PATCH), befindet sich die id in der Snowflake-Tabelle rest_event_history. . Überprüfen Sie die IdP-Protokolle, um sicherzustellen, dass die Werte übereinstimmen.

userName

userName, loginName

Zeichenfolge

Der Benutzername, mit dem sich der Benutzer anmeldet.

name.givenName

firstName

Zeichenfolge

Der Vorname des Benutzers.

name.familyName

familyName

Zeichenfolge

Der Nachname des Benutzers.

emails

email

Zeichenfolge

Unterstützt nur eine E-Mail-Adresse.

displayName

displayName

Zeichenfolge

Der Name, den die Benutzeroberfläche für den Benutzer anzeigt.

externalID

N/A

Zeichenfolge

Der vom Bereitstellungsclient (z. B. Azure, Okta) festgelegte eindeutige Bezeichner.

password

password

Zeichenfolge

Das Kennwort für den Benutzer. Dieser Wert wird in der JSON-Antwort nicht zurückgegeben.

active

disabled

Boolean

Deaktiviert den Benutzer, wenn false eingestellt ist.

groups

N/A

Zeichenfolge

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.

meta.created

createdON

Zeichenfolge

Der Zeitpunkt, zu der der Benutzer zu Snowflake hinzugefügt wurde.

meta.lastModified

lastModified

Zeichenfolge

Der Zeitpunkt, zu der der Benutzer zuletzt in Snowflake geändert wurde.

meta.resourceType

N/A

Zeichenfolge

„Users“ sollten einen „user“-Wert haben.

schemas

N/A

Zeichenfolge

Ein durch Kommas getrenntes Array von Zeichenfolgen, das die Namespace-URIs angibt. . urn:ietf:params:scim:schemas:core:2.0:User . urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

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 Benutzer existiert

GET scim/v2/Users?filter=userName eq „{{Benutzername}}“

Gibt bei Erfolg Details eines Benutzerkontos mit dem angegebenen userName und dem Statuscode 200 zurück.

Details zu einem bestimmten Benutzer abrufen

GET scim/v2/Users/{{Benutzer-ID}}

Gibt bei Erfolg Details eines Benutzerkontos mit der angegebenen user_id und dem Statuscode 200 zurück.

Details zu einem bestimmten Benutzer abrufen

GET scim/v2/Users?startIndex=0&count=1

Gibt einen Beispielbenutzer zurück, damit der SCIM-Client das Schema lesen, und bei Erfolg den Statuscode 200.

Benutzer erstellen

POST scim/v2/Users

Erstellt einen Benutzer in Snowflake und gibt bei Erfolg einen 201-Statuscode zurück. . Wenn der Benutzer bereits existiert oder ein anderer Konflikt auftritt, gibt Snowflake einen 409-Statuscode zurück.

Benutzer mit Teilattributen aktualisieren

PATCH scim/v2/Users/{id}

Deaktiviert den entsprechenden Benutzer, wenn der aktive Schlüssel (active) auf „false“ gesetzt ist. Um einen aktuell deaktivierten Benutzer zu aktivieren, setzen Sie active auf „true“. . PATCH erfordert einen Operationsschlüssel (d. h. op) mit einem Array, das angibt, einen Attributwert zu ersetzen. . Gibt bei Erfolg den Statuscode 200 zurück und bei Nichterfolg den Status 204 (d. h. kein Inhalt).

Benutzer aktualisieren

PUT scim/v2/Users/{id}

Prüft, ob ein Benutzer mit der angegebenen id vorhanden ist. Diese Operation schlägt fehl, wenn unveränderliche Attribute zum Ändern angefordert werden. . Andernfalls werden die Schreib- oder Leseattribute basierend auf der Anforderung ersetzt. . Gibt Statuscode 400 zurück, wenn die unveränderlichen Attributwerte im Anforderungshauptteil nicht mit den Werten in Snowflake übereinstimmen.

Benutzer löschen

DELETE scim/v2/Users/{id}

POST scim/v2/Users

Benutzer mit userName und loginName 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 und loginName erstellen, die unterschiedlichen Werten zugeordnet sind

Wenn Okta Ihr Identitätsanbieter ist, führen Sie die folgenden 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 und loginName 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 und loginName aktualisieren, die verschiedenen Werten zugeordnet sind

Wenn Okta Ihr Identitätsanbieter ist, führen Sie die folgenden 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}

Benutzer aktualisieren.

  • Derzeit ist das Festlegen der Felder "defaultWarehouse" und "defaultRole" nur mit Okta möglich. Azure AD unterstützt diese Konfiguration nicht.

    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": {
        "defaultWarehouse" : "test_warehouse",
        "defaultRole" : "test_role"
    }
}

Verwalten von Rollen mit SCIM

Snowflake unterstützt die Verwendung von SCIM zum Importieren von Rollen aus Okta, Azure AD und benutzerdefinierten 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

id

id

Zeichenfolge

Der unveränderliche, eindeutige Bezeichner (d. h. GUID) der Rolle in Snowflake. . Snowflake legt diesen Wert nicht offen. Er ist in der Snowflake-Tabelle rest_event_history zu finden. . Überprüfen Sie auch die IdP-Protokolle, um sicherzustellen, dass die Werte übereinstimmen.

displayName

name

Zeichenfolge

Der Name, den die Benutzeroberfläche für die Rolle anzeigt.

members.value

N/A

Zeichenfolge

Der userID-Wert des Benutzers, der Mitglied der Rolle ist.

schemas

N/A

Zeichenfolge

Ein Array von Zeichenfolgen zur Angabe der Namespace-URIs. . Beispiel: urn:ietf:params:scim:schemas:core:2.0:Group.

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

GET scim/v2/Groups?filter=displayName=“scim_test_group“

Gibt bei Erfolg Details der Gruppe mit dem angegebenen Anzeigenamen (displayName) und mit dem Statuscode 200 zurück.

Gruppe anhand ihrer Gruppen-ID (groupId) abrufen

GET scim/v2/Groups/{Gruppen-ID}

Gibt bei Erfolg Details der Gruppe mit der angegebenen groupId und dem Statuscode 200 zurück.

Beispielgruppe abrufen

GET scim/v2/Groups?startIndex=0&count=1

Gibt eine Beispielgruppe zurück, damit der SCIM-Client das Schema lesen und bei Erfolg den Statuscode 200 erhalten kann.

Neue Gruppe erstellen

POST scim/v2/Groups

Erstellt bei Erfolg eine neue Gruppe mit dem Statuscode 201.

Gruppe aktualisieren

PATCH scim/v2/Groups/{id}

Aktualisiert das Gruppenanzeigenamenattribut oder die Gruppenmitgliedschaft. . PATCH erfordert einen Operationsschlüssel (d. h. op) mit einem Array, das angibt, ob hinzugefügt oder ersetzt werden soll. . Gibt einen Statuscode von 200 zurück, wenn dies erfolgreich ist, oder 204 (d. h. kein Inhalt), wenn dies nicht erfolgreich ist.

Gruppe löschen

DELETE scim/v2/Groups/{id})

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 die Abfrage der Tabelle 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'));
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.

  1. Okta

  2. Microsoft Azure Active Directory

  3. Benutzerdefiniert

    Bemerkung

    Benutzerdefinierte SCIM-Integrationen ermöglichen Identitätsanbietern ohne dedizierte Integration, Benutzer und Gruppen in Snowflake bereitzustellen, zu verwalten und zu synchronisieren.

    Derzeit sollte die benutzerdefinierte 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 Benutzerdefinierte SCIM-Integration mit Snowflake befolgen.