Snowflake-SCIM-Unterstützung¶
Snowflake unterstützt SCIM 2.0 und ermöglicht Ihnen die Integration von Snowflake in Okta und Microsoft Azure AD als Identitätsanbieter. Sie können benutzerdefinierte Identitätsanbieter verwenden, d. h. Identitätsanbieter, die weder Okta noch Microsoft Azure sind. Sie können Benutzer und Gruppen (Rollen) vom Identitätsanbieter in Snowflake bereitstellen, wobei Snowflake als Dienstanbieter fungiert.
Bemerkung
SCIM-Rollen in Snowflake müssen Eigentümer aller Benutzer und Rollen sein, 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. Snowflake-SCIM-Rollen korrelieren mit ihrem Identitätsanbieter (IdP):
Okta-SCIM-Rolle:
okta_provisioner
Microsoft Entra ID 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, Microsoft Entra ID und die kundenspezifische SCIM-Integration.
Anwendungsfälle¶
Die Snowflake-SCIM-API kann die folgenden Anwendungsfälle behandeln.
Verwalten von Benutzern: 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.
Verwalten von Gruppen: 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.
Prüfung von SCIM-API-Anforderungen: Administratoren können die Tabelle
rest_event_history
abfragen, um festzustellen, ob der Identitätsanbieter Aktualisierungen (d. h. SCIM-API-Anforderungen) an Snowflake sendet.
SCIM API¶
Identitätsanbieter können einen SCIM-Client verwenden, um RESTful-API-Anforderungen an den Snowflake-SCIM-Server zu senden. Nach der Validierung der API-Anforderung führt Snowflake die von den Identitätsanbietern angeforderten Aktionen für Benutzer oder Gruppen aus.
Snowflake authentifiziert SCIM-API-Anforderungen von Identitätsanbietern über ein OAuth Bearer-Token in der Authorization
-Kopfzeile von HTTP-Anforderungen. Das Token ist sechs Monate gültig. Sie müssen sicherstellen, dass Ihr Token bei der Authentifizierung nicht abgelaufen ist. Wenn Ihr Token abläuft, können Sie mit der Funktion SYSTEM$GENERATE_SCIM_ACCESS_TOKEN ein neues Zugriffstoken generieren.
Vorsicht
Derzeit können Administratoren mithilfe der Snowflake-SCIM-API Benutzer und Gruppen vom Identitätsanbieter des Kunden für Snowflake verwalten. Wenn Sie Änderungen an Benutzern und Gruppen direkt in Snowflake vornehmen, werden die Änderungen nicht mit dem Identitätsanbieter des Kunden synchronisiert.
Weitere Informationen zu SCIM-API-Anforderungen an Snowflake finden Sie unter SCIM-API-Referenz.
Prüfung von SCIM-API-Anforderungen¶
Sie können Snowflake abfragen, um Informationen zu SCIM-API-Anforderungen zu finden, die über einen bestimmten Zeitraum hinweg gesendet wurden. Anhand dieser Informationen können Sie feststellen, ob die aktiven Benutzer Ihrer Organisation mit den in Snowflake eingerichteten Benutzern übereinstimmen.
Um beispielsweise zu ermitteln, welche SCIM-API-Anforderungen in den letzten fünf Minuten gesendet wurden, wobei maximal 200 Anforderungen zurückgegeben werden sollen, können Sie die Information Schema-Tabellenfunktion REST_EVENT_HISTORY verwenden:
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 DATEADD und CURRENT_TIMESTAMP.
Unterstützte SCIM-Sicherheitsintegrationen¶
Replizieren von Sicherheitsintegrationen¶
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.