Okta-SCIM-Integration mit Snowflake

Diese Anleitung enthält die erforderlichen Schritte zum Konfigurieren der Bereitstellung (in Okta) von Okta-Benutzern und -Gruppen in Snowflake. Sie enthält folgende Abschnitte:

Funktionen

Die Benutzer- und Rollenverwaltung wird für die Snowflake-Anwendung unterstützt.

Okta bietet Folgendes:

  • Verwalten des Benutzerlebenszyklus (Erstellen, Aktualisieren und Löschen) in Snowflake.

  • Verwalten des Rollenlebenszyklus (Erstellen, Aktualisieren und Löschen) in Snowflake.

  • Verwalten der Zuweisungen von Benutzer zu Rollen in Snowflake.

Die folgenden Bereitstellungsfunktionen werden unterstützt:

Neue Benutzer mit Push übertragen

Neue Benutzer, die mit OKTA erstellt wurden, werden auch in Snowflake erstellt.

Profilaktualisierungen mit Push übertragen

Über OKTA am Benutzerprofil vorgenommene Aktualisierungen werden an Snowflake weitergeleitet.

Benutzerdeaktivierung mit Push übertragen

Bei Deaktivieren des Benutzers oder des Benutzerzugriffs auf Snowflake über OKTA wird der Benutzer in Snowflake deaktiviert.

Bemerkung

Bei Snowflake bedeutet das Deaktivieren eines Benutzers, dass das Attribut isActive für den Benutzer auf „false“ gesetzt wird.

Benutzer reaktivieren

Benutzerkonten können in Snowflake reaktiviert werden.

Kennwort synchronisieren

Das Benutzerkennwort kann bei Bedarf von Okta an Snowflake übertragen werden.

Tipp

In der Standardeinstellung wird ein zufälliges Kennwort für Benutzer erstellt, wobei dem Benutzer die Attributeinstellung has_Password=true zugewiesen wird. Ohne Kennwort müssen Benutzer über Okta SSO auf Snowflake zugreifen. Um zu verhindern, dass ein Kennwort für Benutzer generiert wird, können Sie vor dem Bereitstellen von Benutzern diese Einstellung wie folgt deaktivieren:

  1. Klicken Sie auf Edit.

  2. Deaktivieren Sie unter Sync Password die Einstellung Generate a new random password whenever the user’s Okta password changes.

  3. Speichern Sie die Änderung.

Wenn Sie diese Einstellung in Okta aktivieren, wird ein Kennwort erstellt, mit dem der Benutzer auf Snowflake zugreifen kann. Dies kann dazu führen, dass Benutzer ohne SSO auf Snowflake zugreifen können.

Gruppen mit Push übertragen

The Push Groups feature creates roles in Snowflake and facilitates role management. The roles created in Snowflake using Okta Push Groups have the same names in Okta and Snowflake. Always create roles in Okta first and use Push Groups to update Snowflake to ensure Okta and Snowflake can synchronize. Okta and the OKTA_PROVISIONER custom role in Snowflake cannot manage manually created roles in Snowflake. Push Groups do not create users in Snowflake.

Tipp

Okta can create users in Snowflake if the Snowflake application in Okta is assigned to a user in Okta.

For more information, see Assign an application to a user.

Die folgenden Benutzerattribute werden unterstützt:

Attributtyp

SCIM-Benutzerattribut

Snowflake-Benutzerattribut

Basisattribute

userName

name und login_name

givenName

first_name

familyName

last_name

email

email

Benutzerdefinierte Attribute

defaultRole

default_role

defaultWarehouse

default_warehouse

Nicht unterstützt

  • Okta-Funktionen Enhanced Group Push und Push Now.

    Bemerkung

    Die Attribute defaultRole und defaultWarehouse werden nicht zugeordnet, da sie optional sind. Bei Bedarf können Sie diese mit einem Okta-Profil oder -Ausdruck zuordnen oder für alle Benutzer den gleichen Wert festlegen.

  • Wenn Sie mit AWS PrivateLink auf Snowflake zugreifen, stellen Sie sicher, dass Sie in den Integrationseinstellungen nicht die PrivateLink-URL eingeben. Geben Sie den öffentlichen Endpunkt ein (d. h. ohne .privatelink) und stellen Sie sicher, dass die Netzwerkrichtlinie den Zugriff von der hier angegebenen Okta-IP-Adresse aus zulässt. Andernfalls können Sie diese Integration nicht verwenden.

  • Okta unterstützt derzeit nicht das Importieren von verschachtelten Active Directory-Gruppen. Wenn Ihre Okta-Integration verschachtelte Gruppen in AD verwendet, können Sie die Snowflake-Okta-SCIM-Integration daher nicht zum Bereitstellen oder Verwalten verschachtelter Gruppen in Snowflake verwenden. Wenden Sie sich an Okta und Microsoft, um die Unterstützung verschachtelter Gruppen anzufordern.

Bekannte Probleme

  • Wenn Ihr Snowflake-Konto mit Unterstrichen im Kontonamen (z. B. my_account) erstellt wurde, können Sie auf Ihr Snowflake-Konto zugreifen, wobei der Kontoname Unterstriche oder Bindestriche enthält (z. B. my-account). Wenn Sie den getrennten Kontonamen sowohl für Okta SAML SSO als auch für Okta SCIM wiederverwenden, werden Kontonamen mit Unterstrichen nicht unterstützt. Verwenden Sie den Kontonamen mit Bindestrich, um SCIM zu konfigurieren.

  • Bestehende Snowflake-Benutzer können durch Übertragung der Eigentümerschaft unter die Verwaltung von Okta genommen werden. Weitere Informationen dazu finden Sie unter Tipps zur Problembehandlung (unter diesem Thema).

Voraussetzungen

  1. Stellen Sie vor dem Bereitstellen von Benutzern oder Gruppen sicher, dass die Netzwerkrichtlinie in Snowflake den Zugriff über die IP-Adressen von Okta ermöglicht, die hier dokumentiert sind. Weitere Informationen dazu finden Sie unter Verwalten von SCIM-Netzwerkrichtlinien.

  2. Stellen Sie vor dem Konfigurieren der Bereitstellung für Snowflake sicher, dass Sie General Settings und alle Sign-On Options für die Snowflake-Anwendung in Okta konfiguriert haben.

Wenn die obigen Schritte abgeschlossen sind, klicken Sie in Okta auf Next, um zur Registerkarte Provisioning zurückzukehren.

Konfigurationsschritte

Für die Konfiguration müssen Sie Schritte in Snowflake und in Okta ausführen.

Snowflake-Konfiguration

The Snowflake configuration process creates a SCIM security integration to allow users and roles created in Okta to be owned by the OKTA_PROVISIONER SCIM role in Snowflake and creates an access token to use in SCIM API requests. The access token is valid for six months. Upon expiration, create a new access token manually using SYSTEM$GENERATE_SCIM_ACCESS_TOKEN as shown below.

Führen Sie die folgenden SQL-Anweisungen in Ihrem bevorzugten Snowflake-Client aus.

use role accountadmin;
create or replace role okta_provisioner;
grant create user on account to role okta_provisioner;
grant create role on account to role okta_provisioner;
grant role okta_provisioner to role accountadmin;
create or replace security integration okta_provisioning
    type=scim
    scim_client='okta'
    run_as_role='OKTA_PROVISIONER';
select system$generate_scim_access_token('OKTA_PROVISIONING');

Jede der folgenden SQL-Anweisungen wird unten erläutert.

  1. Überprüfen Sie die ACCOUNTADMIN-Rolle.

    use role accountadmin;
    
  2. Erstellen Sie die benutzerdefinierte Rolle OKTA_PROVISIONER. Alle von Okta erstellten Benutzer und Rollen in Snowflake gehören der Rolle OKTA_PROVISIONER mit eingeschränktem Geltungsbereich.

    create or replace role okta_provisioner;
    grant create user on account to role okta_provisioner;
    grant create role on account to role okta_provisioner;
    
  3. Erstellen Sie als ACCOUNTADMIN die Sicherheitsintegration mithilfe der Rolle OKTA_PROVISIONER. Weitere Informationen dazu finden Sie unter CREATE SECURITY INTEGRATION.

    create or replace security integration okta_provisioning
        type=scim
        scim_client='okta'
        run_as_role='OKTA_PROVISIONER';
    
  4. Erstellen Sie das Autorisierungstoken, kopieren Sie es in die Zwischenablage, und speichern Sie es für die spätere Verwendung. Verwenden Sie dieses Token für jede SCIM-REST-API-Anforderung, und platzieren Sie es im Anforderungsheader. Das Zugriffstoken läuft nach sechs Monaten ab, doch mit dieser Anweisung kann ein neues Zugriffstoken generiert werden.

    select system$generate_scim_access_token('OKTA_PROVISIONING');
    

    Wichtig

    Alle von Okta erstellten Benutzer und Rollen in Snowflake gehören der Rolle okta_provisioner mit eingeschränktem Geltungsbereich.

    Wenn Sie vorhandene Snowflake-Benutzer und -Rollen über Okta verwalten möchten, führen Sie die folgenden Schritte aus:

    1. Übertragen Sie die Eigentümerschaft der vorhandenen Benutzer und Rollen auf die Rolle „okta_provisioner“.

      use role accountadmin;
      grant ownership on user <user_name> to role okta_provisioner;
      grant ownership on role <role_name> to role okta_provisioner;
      
    2. Stellen Sie sicher, dass die Eigenschaft login_name für vorhandene Benutzer festgelegt ist. Sie sollte bereits festgelegt sein, bevor diese vorhandenen Snowflake-Benutzer Okta-SSO verwenden.

    3. Beachten Sie, dass die Namen vorhandener Benutzer, die unter die Verwaltung von Okta gestellt wurden, so aktualisiert werden, dass sie den Benutzernamen von Okta entsprechen. Informieren Sie Ihre Benutzer über diese Änderung, da sie möglicherweise den Namen verwenden, um von einer anderen Integration (z. B. Tableau) aus eine Verbindung zu Snowflake herzustellen.

Okta-Konfiguration

Greifen Sie in Okta auf die Snowflake-Anwendung zu, und führen Sie die folgenden Schritte aus.

  1. Wählen Sie in Settings im Menü auf der linken Seite Integration aus, und aktivieren Sie das Kontrollkästchen Enable API Integration.

  2. Geben Sie für API Token den oben generierten Wert aus der Zwischenablage ein. Klicken Sie auf die Schaltfläche Test API Credentials, und speichern Sie bei Erfolg die Konfiguration.

  3. Wählen Sie im Menü auf der linken Seite die Option To App aus.

  4. Wählen Sie das Provisioning Features aus, das Sie aktivieren möchten.

  5. Überprüfen Sie die Attributzuordnungen. Die Attribute defaultRole und defaultWarehouse werden nicht zugeordnet, da sie optional sind. Bei Bedarf können Sie diese mit einem Okta-Profil oder -Ausdruck zuordnen oder für alle Benutzer den gleichen Wert festlegen.

Sie können der Snowflake-Anwendung jetzt Benutzer zuweisen (falls erforderlich) und das Einrichten der Anwendung abschließen.

Bemerkung

Okta unterstützt ein Attribut namens snowflakeUserName, das dem Feld name des Snowflake-Benutzers zugeordnet ist.

Wenn die Felder name und login_name für den Snowflake-Benutzer unterschiedliche Werte haben sollen, gehen Sie folgendermaßen vor.

  1. Wenden Sie sich an den Snowflake-Support, um die separate Zuordnung für Ihr Konto zu aktivieren.

  2. Greifen Sie in Okta auf die Snowflake-Anwendung zu, und navigieren Sie zu Provisioning > Attribute Mappings > Edit Mappings.

  3. Suchen Sie nach dem Attribut snowflakeUserName.

  4. Wird das Attribut nicht gefunden, wurde die Snowflake-Anwendung erstellt, bevor dieses Attribut verfügbar war. Erstellen Sie die Snowflake-Anwendung mit den unten gezeigten Zuordnungen neu, oder fügen Sie das Attribut manuell wie folgt hinzu:

    • Klicken Sie auf Add Attribute.

    • Stellen Sie die folgenden Werte für jedes der aufgelisteten Felder in der Tabelle ein.

    Feld

    Wert

    Datentyp

    Zeichenfolge

    Anzeigename

    Snowflake-Benutzername

    Variablenname

    snowflakeUserName

    Externer Name

    snowflakeUserName

    Externer Namespace

    urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

    Beschreibung

    Wird dem Feld name des Benutzers in Snowflake zugeordnet.

    Bereich

    Benutzer persönlich

  5. Klicken Sie auf Save.

Von Snowflake initiiertes SSO aktivieren

Der SCIM-Bereitstellungsprozess aktiviert Single Sign-On (SSO) nicht automatisch.

Um SSO nach Abschluss des SCIM-Bereitstellungsprozesses zu verwenden, aktivieren Sie Von Snowflake initiiertes SSO.

Verwalten von SCIM-Netzwerkrichtlinien

Die SCIM-Netzwerkrichtlinie verfügt über eine eigene Einstellung, sodass der SCIM-Anbieter eine spezifische Erlaubnis zum Bereitstellen von Benutzern und Gruppen erhalten kann, ohne dass diese IP-Adressen für den normalen Benutzerzugriff hinzugefügt werden.

Durch das Einrichten einer für die SCIM-Integration spezifischen Netzwerkrichtlinie kann SCIM von anderen Netzwerkrichtlinien unterschieden werden, die möglicherweise für das Snowflake-Konto gelten. Die SCIM-Netzwerkrichtlinie wirkt sich nicht auf andere Netzwerkrichtlinien des Kontos aus, und ebenso wirken sich andere Netzwerkrichtlinien des Kontos nicht auf die SCIM-Netzwerkrichtlinie aus. Daher ermöglicht die SCIM-Netzwerkrichtlinie die Snowflake-SCIM-Integration, um Benutzer und Gruppen wie beabsichtigt bereitzustellen.

Erstellen Sie zuerst die SCIM-Sicherheitsintegration und danach die SCIM-Netzwerkrichtlinie mit dem folgenden Befehl:

alter security integration okta_provisioning set network_policy = <SCIM-Netzwerkrichtlinie>;

Verwenden Sie folgenden Befehl, um die SCIM-Netzwerkrichtlinie zu deaktivieren:

alter security integration okta_provisioning unset <SCIM-Netzwerkrichtlinie>;

Wobei:

okta_provisioning

Gibt den Namen der Okta-SCIM-Sicherheitsintegration an.

<scim_network_policy>

Gibt die Okta-SCIM-Netzwerkrichtlinie in Snowflake an.

Weitere Informationen dazu finden Sie unter Netzwerkrichtlinien und ALTER SECURITY INTEGRATION.

Tipps zur Problembehandlung

  • Übertragen der Eigentümerschaft. Wenn die Benutzeraktualisierung fehlschlägt, überprüfen Sie die Eigentümerschaft des Benutzers in Snowflake. Wenn die Aktualisierung nicht der Rolle okta_provisioner gehört (oder der Rolle, die beim Erstellen der Sicherheitsintegration in Snowflake im Parameter run_as_role festgelegt wurde), schlägt die Aktualisierung fehl. Übertragen Sie die Eigentümerschaft, indem Sie die folgende SQL-Anweisung in Snowflake ausführen und es erneut versuchen.

    grant ownership on user <username> to role OKTA_PROVISIONER;
    
  • Stellen Sie sicher, dass die Eigenschaft login_name für vorhandene Benutzer festgelegt ist. Sie sollte bereits festgelegt sein, bevor diese vorhandenen Snowflake-Benutzer Okta-SSO verwenden.

  • Um sicherzustellen, dass Okta Aktualisierungen an Snowflake sendet, überprüfen Sie die Protokollereignisse in Okta für die Snowflake-Anwendung, und überprüfen Sie die SCIM-Überwachungsprotokolle in Snowflake, um sicherzustellen, dass Snowflake Aktualisierungen von Okta empfängt. Verwenden Sie Folgendes, um die Snowflake SCIM-Überwachungsprotokolle abzufragen.

    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;
    
  • Möglicherweise tritt während des Bereitstellungsvorgangs ein Authentifizierungsfehler auf. Eine mögliche Fehlermeldung lautet wie folgt:

    Error authenticating: Forbidden. Errors reported by remote server: Invalid JSON: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.StringReader@4c76ba04; line: 1, column: 2]
    

    Wenn diese Fehlermeldung oder andere Authentifizierungsfehlermeldungen auftreten, versuchen Sie Folgendes:

    1. Entfernen Sie in Okta die aktuelle Snowflake-Anwendung, und erstellen Sie eine neue Snowflake-Anwendung.

    2. Erstellen Sie in Snowflake eine neue SCIM-Sicherheitsintegration, und generieren Sie ein neues Zugriffstoken.

    3. Kopieren Sie das neue Token, indem Sie auf Copy klicken.

    4. Fügen Sie in Okta das neue Zugriffstoken ein, und überprüfen Sie es, wie unter Konfigurieren von Okta als SCIM-Identitätsanbieter beschrieben.

    5. Stellen Sie Benutzer und Rollen von Okta für Snowflake mit der neuen Snowflake-Anwendung in Okta bereit.