Okta-SCIM-Integration mit Snowflake¶
Diese Anleitung enthält die erforderlichen Schritte zum Konfigurieren der Bereitstellung in Okta für 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 (d. h. Erstellen, Aktualisieren und Löschen) in Snowflake.
Verwalten des Rollenlebenszyklus (d. h. 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 die Eigenschaft
DISABLED
für den Benutzer aufTRUE
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:Klicken Sie auf Edit.
Deaktivieren Sie unter Sync Password die Einstellung Generate a new random password whenever the user’s Okta password changes.
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.
Um die Kennwortsynchronisierung zu deaktivieren, müssen Sie diese Option in Okta deaktivieren und die Snowflake-Okta-SCIM-Sicherheitsintegration aktualisieren, um die Eigenschaft
SYNC_PASSWORD
aufFalse
zu setzen.- Gruppen mit Push übertragen (Push Groups):
Die „Push Groups“-Funktion erstellt Rollen in Snowflake und erleichtert die Rollenverwaltung. Die in Snowflake mit Okta Push Groups erstellten Rollen haben in Okta und Snowflake die gleichen Namen. Erstellen Sie immer zuerst Rollen in Okta, und aktualisieren Sie dann Snowflake mithilfe von „Push Groups“, um sicherzustellen, dass Okta und Snowflake synchronisiert werden können. Okta und die kundenspezifische Snowflake-Rolle OKTA_PROVISIONER können manuell erstellte Rollen nicht in Snowflake verwalten. „Push Groups“ erstellen keine Benutzer in Snowflake.
Tipp
Okta kann Benutzer in Snowflake erstellen, wenn die Snowflake-Anwendung in Okta einem Benutzer in Okta zugewiesen ist.
Weitere Informationen dazu finden Sie unter Zuweisen einer Anwendung zu einem Benutzer.
Die folgenden Benutzerattribute werden unterstützt:
Attributtyp |
SCIM-Benutzerattribut |
Snowflake-Benutzerattribut |
Anmerkungen |
---|---|---|---|
Basisattribute |
userName |
name und login_name |
|
givenName |
first_name |
||
familyName |
last_name |
||
Kundenspezifische Attribute |
defaultRole |
default_role |
|
defaultWarehouse |
default_warehouse |
||
defaultSecondaryRoles |
default_secondary_role |
Sie können als Wert nur |
Bekannte Probleme¶
Okta unterstützt keine URLs, die Unterstriche enthalten. Wenn der Name des Snowflake-Kontos einen Unterstrich enthält, müssen Sie eine spezielle Konto-URL verwenden, die den Unterstrich durch einen Bindestrich ersetzt. Wenn Sie das URL-Format mit Kontonamen verwenden, könnte die spezielle URL wie folgt sein:
https://myorg-account-name.snowflakecomputing.com
.Bestehende Snowflake-Rollen können nicht durch Übertragung der Eigentümerschaft unter die Verwaltung von Okta gebracht werden. Über Okta können nur neue Rollen erstellt werden.
Bestehende Snowflake-Benutzer können durch Übertragung der Eigentümerschaft unter die Verwaltung von Okta genommen werden. Weitere Informationen dazu finden Sie unter Problembehandlung (unter diesem Thema).
Einschränkungen¶
Snowflake unterstützt maximal 500 gleichzeitige Anforderungen pro Konto und SCIM-Endpunkt (z. B. den
/Users
-Endpunkt, den/Groups
-Endpunkt). Nachdem Ihr Konto diesen Schwellenwert überschritten hat, gibt Snowflake einen429
-HTTP-Statuscode zurück (d. h. zu viele Anforderungen). Beachten Sie, dass diese Anforderungsbegrenzung in der Regel nur während der erstmaligen Bereitstellung auftritt, wenn eine relativ große Anzahl von Anforderungen (d. h. mehr als 10.000) an Bereitstellungsbenutzer oder -gruppen erfolgt.
Nicht unterstützt¶
Okta-Funktionen Enhanced Group Push und Push Now.
Bemerkung
Die Attribute
defaultRole
,defaultSecondaryRoles
unddefaultWarehouse
werden nicht zugeordnet, da sie optional sind. Um diese Attribute in Okta zuzuordnen, verwenden Sie Profile oder Ausdrücke oder legen Sie einen Standardwert für alle Benutzer fest. Weitere Informationen dazu finden Sie unter Profile verwalten (in Okta).Wenn Sie mit privater Konnektivität zum Snowflake-Dienst auf Snowflake zugreifen, stellen Sie sicher, dass Sie nicht diese URLs in den Integrationseinstellungen angeben. 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 in AD verschachtelte Gruppen verwendet, können Sie die Snowflake-Okta-SCIM-Integration nicht zum Bereitstellen oder Verwalten verschachtelter Gruppen in Snowflake verwenden. Wenden Sie sich an Okta und Microsoft, um die Unterstützung verschachtelter Gruppen anzufordern.
Voraussetzungen¶
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.
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¶
Bei der Konfiguration in Snowflake wird eine SCIM-Sicherheitsintegration erstellt, damit die in Okta erstellten Benutzer und Rollen Eigentum der Snowflake-Rolle OKTA_PROVISIONER SCIM sind. Außerdem wird ein Zugriffstoken zur Verwendung in SCIM-API-Anforderungen erstellt. Das Zugriffstoken ist sechs Monate gültig. Nach Ablauf müssen Sie ein neues Zugriffstoken manuell mit SYSTEM$GENERATE_SCIM_ACCESS_TOKEN erstellen, wie unten gezeigt.
Bemerkung
Um ein vorhandenes Zugriffstoken für eine SCIM-Integration ungültig zu machen, führen Sie eine DROP INTEGRATION-Anweisung aus.
Um die Verwendung von SCIM mit Snowflake fortzusetzen, erstellen Sie die SCIM-Integration mit einer CREATE SECURITY INTEGRATION-Anweisung neu, und generieren Sie dann mit SYSTEM$GENERATE_SCIM_ACCESS_TOKEN ein neues Zugriffstoken.
Führen Sie die folgenden SQL-Anweisungen in Ihrem bevorzugten Snowflake-Client aus. Jede der folgenden SQL-Anweisungen wird unten erläutert.
use role accountadmin;
create role if not exists 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');
Wichtig
In den SQL-Beispielanweisungen wird die Systemrolle ACCOUNTADMIN verwendet, und die kundenspezifische Rolle OKTA_PROVISIONER wird der Rolle ACCOUNTADMIN zugewiesen.
Es ist möglich, statt der Rolle ACCOUNTADMIN auch eine Rolle mit niedrigeren Berechtigungen zu verwenden. Die Verwendung einer Rolle mit niedrigeren Berechtigungen kann dazu beitragen, Konformitätsprobleme im Zusammenhang mit dem Zugriff mit den niedrigsten Berechtigungen zu beheben, jedoch kann die Verwendung einer Rolle mit niedrigeren Berechtigungen zu unerwarteten Fehlern bei der SCIM-Konfiguration und -Verwaltung führen.
Diese Fehler könnten darauf zurückzuführen sein, dass die Rolle mit niedrigeren Berechtigungen aufgrund der Art und Weise, wie die Rollen erstellt werden, und der daraus resultierenden Rollenhierarchie nicht über ausreichende Berechtigungen verfügt, um alle Rollen über SCIM zu verwalten. Um also Fehler in den Konfigurations- und Verwaltungsprozessen zu vermeiden, sollten Sie eine der folgenden Optionen wählen:
Verwenden Sie die Rolle ACCOUNTADMIN, wie in den SQL-Beispielanweisungen gezeigt.
Verwenden Sie eine Rolle mit der globalen Berechtigung MANAGE GRANTS.
Wenn keine dieser beiden Optionen wünschenswert ist, verwenden Sie eine kundenspezifische Rolle, die über OWNERSHIP-Berechtigung für alle Rollen verfügt, die mit SCIM verwaltet werden.
Verwenden Sie die Rolle ACCOUNTADMIN.
use role accountadmin;
Erstellen Sie die kundenspezifische Rolle OKTA_PROVISIONER. Alle von Okta erstellten Benutzer und Rollen in Snowflake gehören der Rolle OKTA_PROVISIONER mit eingeschränktem Geltungsbereich.
create role if not exists okta_provisioner; grant create user on account to role okta_provisioner; grant create role on account to role okta_provisioner;
Erstellen Sie als ACCOUNTADMIN die Sicherheitsintegration mithilfe der Rolle OKTA_PROVISIONER. Weitere Informationen dazu finden Sie unter CREATE SECURITY INTEGRATION.
grant role okta_provisioner to role accountadmin; create or replace security integration okta_provisioning type = scim scim_client = 'okta' run_as_role = 'OKTA_PROVISIONER';
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 über Okta verwalten möchten, führen Sie die folgenden Schritte aus:
Übertragen Sie die Eigentümerschaft der vorhandenen Benutzer auf die Rolle „okta_provisioner“.
use role accountadmin; grant ownership on user <user_name> 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.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¶
In diesem Abschnitt wird beschrieben, wie Sie eine Snowflake-Anwendung in Okta erstellen und konfigurieren.
Bemerkung
Beim Erstellen der Snowflake-Anwendung in Okta muss das Feld SubDomain der Anwendung den Kontobezeichner Ihres Snowflake-Kontos enthalten. Wenn der Snowflake-Kontoname einen Unterstrich enthält und Sie das Kontonamenformat des Bezeichners verwenden, müssen Sie den Unterstrich in einen Bindestrich umwandeln, da Okta Unterstriche in URLs nicht unterstützt (z. B. myorg-account-name
).
Fügen Sie kein privatelink
-Segment in das SubDomain-Feld ein, da private Konnektivität nicht unterstützt wird und die Eingabe dieses Segments die SCIM-Verbindung zum Scheitern bringt.
Um die Snowflake-Anwendung in Okta zu konfigurieren, führen Sie die folgenden Schritte aus:
Wählen Sie in Settings im Menü auf der linken Seite Integration aus, und aktivieren Sie das Kontrollkästchen Enable API Integration.
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.
Wählen Sie im Menü auf der linken Seite die Option To App aus.
Wählen Sie das Provisioning Features aus, das Sie aktivieren möchten.
Überprüfen Sie die Attributzuordnungen. Die Attribute
defaultRole
,defaultSecondaryRoles
unddefaultWarehouse
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.
Wenden Sie sich an den Snowflake-Support, um die separate Zuordnung für Ihr Konto zu aktivieren.
Greifen Sie in Okta auf die Snowflake-Anwendung zu, und navigieren Sie zu Provisioning > Attribute Mappings > Edit Mappings.
Suchen Sie nach dem Attribut
snowflakeUserName
.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
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¶
Durch das Anwenden einer Netzwerkrichtlinie auf einer SCIM-Sicherheitsintegration kann die SCIM-Netzwerkrichtlinie von den Netzwerkrichtlinien, die für das gesamte Snowflake-Konto gelten, unterschieden werden. Dadurch kann der SCIM-Anbieter Benutzer und Gruppen bereitstellen, ohne IP-Adressen zu der Netzwerkrichtlinie hinzuzufügen, mit der der Zugriff für normale Benutzer kontrolliert wird.
Eine Netzwerkrichtlinie, die auf eine SCIM-Integration angewendet wird, überschreibt die Netzwerkrichtlinie, die auf das gesamte Snowflake-Konto angewendet wird, sie kann aber selbst von einer Netzwerkrichtlinie überschieben werden, die einem Benutzer zugewiesen ist.
Erstellen Sie zuerst die SCIM-Sicherheitsintegration und danach die SCIM-Netzwerkrichtlinie mit dem folgenden Befehl:
alter security integration okta_provisioning set network_policy = <scim_network_policy>;
Verwenden Sie folgenden Befehl, um die SCIM-Netzwerkrichtlinie zu deaktivieren:
alter security integration okta_provisioning unset network_policy;
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 Steuern des Netzwerkdatenverkehrs mit Netzwerkrichtlinien und ALTER SECURITY INTEGRATION.
Verwenden von Sekundärrollen mit SCIM¶
Snowflake unterstützt das Festlegen der Benutzer-Eigenschaft DEFAULT_SECONDARY_ROLES
auf 'ALL'
mit SCIM, um Benutzern die Verwendung von Sekundärrollen in einer Snowflake-Sitzung zu ermöglichen.
Ein typisches Beispiel finden Sie unter PUT scim/v2/Users/{ID}.
Replizieren der Okta-SCIM-Sicherheitsintegration¶
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.
Problembehandlung¶
Übertragen der Eigentümerschaft. Wenn die Benutzeraktualisierung fehlschlägt, überprüfen Sie die Eigentümerschaft des Benutzers in Snowflake. Wenn der Benutzer nicht der Rolle
okta_provisioner
gehört (oder der Rolle, die beim Erstellen der Sicherheitsintegration in Snowflake im Parameterrun_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:
Entfernen Sie in Okta die aktuelle Snowflake-Anwendung, und erstellen Sie eine neue Snowflake-Anwendung.
Erstellen Sie in Snowflake eine neue SCIM-Sicherheitsintegration, und generieren Sie ein neues Zugriffstoken.
Kopieren Sie das neue Token, indem Sie auf Copy klicken.
Fügen Sie in Okta das neue Zugriffstoken ein, und überprüfen Sie es, wie unter Konfigurieren von Okta als SCIM-Identitätsanbieter beschrieben.
Stellen Sie Benutzer und Rollen von Okta für Snowflake mit der neuen Snowflake-Anwendung in Okta bereit.
Nächste Themen: