Kundenspezifische SCIM-Integration mit Snowflake

Kundenspezifische SCIM-Integrationen ermöglichen es Benutzern, eigene Anwendungen zu erstellen, die mit ihrem Identitätsanbieter kommunizieren, um Benutzer und Rollen für Snowflake bereitzustellen, zuzuordnen und zu verwalten.

Derzeit werden kundenspezifische SCIM-Integrationen für Identitätsanbieter unterstützt, die weder Okta noch Microsoft Azure AD sind.

Gehen Sie nach dem Erstellen Ihrer SCIM-Anwendung wie folgt vor, um eine Snowflake-Sicherheitsintegration zu erstellen und ein SCIM-API-Autorisierungstoken zu generieren. Speichern Sie das Autorisierungstoken, und fügen Sie es in den SCIM-API-Anforderungsheader ein, wie unter Erstellen einer SCIM-API-Anforderung beschrieben.

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 einen 429-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.

  • Wenn Ihre Snowflake-Konto-URL mit Unterstrichen im Kontonamen erstellt wurde, können Sie auf Ihr Snowflake-Konto zugreifen, wobei die Konto-URL Unterstriche oder Bindestriche enthält.

    Wenn Ihr SCIM-Anbieter dieselbe Konto-URL für SAML SSO und SCIM wiederverwendet, werden URLs mit Unterstrichen nicht unterstützt. Verwenden Sie die Konto-URL mit Bindestrichen, um SCIM zu konfigurieren.

    Snowflake-Konto-URLs, die keine Unterstriche enthalten, werden durch diese Einschränkung nicht eingeschränkt.

  • Eine kundenspezifische SCIM-Integration kann die Bereitstellung und Verwaltung verschachtelter Gruppen ermöglichen oder nicht. Bevor Sie versuchen, eine kundenspezifische SCIM-Integration zum Bereitstellen verschachtelter Gruppen in Snowflake zu verwenden, wenden Sie sich an Ihren Identitätsanbieter, um festzustellen, ob verschachtelte Gruppen mit einer SCIM-Integration verwendet werden dürfen.

  • 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 IdP-IP-Adresse aus zulässt. Andernfalls können Sie diese Integration nicht verwenden.

  • Aktivieren oder Deaktivieren Sie die Kennwortsynchronisierung von einem benutzerspezifischen Identitätsanbieter zu Snowflake.

    Die Einstellung der Eigenschaft SYNC_PASSWORD in der Snowflake-Sicherheitsintegration wird nur für Okta SCIM-Integrationen unterstützt.

Voraussetzungen

Stellen Sie vor dem Bereitstellen von Benutzern oder Gruppen sicher, dass die Netzwerkrichtlinie in Snowflake den Zugriff aus den IP-Bereichen zulässt, die Ihrer Organisation entsprechen. Weitere Informationen dazu finden Sie unter Verwalten von SCIM-Netzwerkrichtlinien.

Kundenspezifische SCIM-Sicherheitsintegration und API-Token erstellen

Bei der Konfiguration in Snowflake wird eine SCIM-Sicherheitsintegration erstellt, damit die beim Identitätsanbieter erstellten Benutzer und Rollen Eigentum der Snowflake-Rolle GENERIC_SCIM_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 Anweisungen wird unten erläutert.

use role accountadmin;
create role if not exists generic_scim_provisioner;
grant create user on account to role generic_scim_provisioner;
grant create role on account to role generic_scim_provisioner;
grant role generic_scim_provisioner to role accountadmin;
create or replace security integration generic_scim_provisioning
    type=scim
    scim_client='generic'
    run_as_role='GENERIC_SCIM_PROVISIONER';
select system$generate_scim_access_token('GENERIC_SCIM_PROVISIONING');
Copy

Wichtig

In den SQL-Beispielanweisungen wird die Systemrolle ACCOUNTADMIN verwendet, und die kundenspezifische Rolle GENERIC_SCIM_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:

  1. Verwenden Sie die Rolle ACCOUNTADMIN, wie in den SQL-Beispielanweisungen gezeigt.

  2. Verwenden Sie eine Rolle mit der globalen Berechtigung MANAGE GRANTS.

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

  1. Verwenden Sie die Rolle ACCOUNTADMIN.

    use role accountadmin;
    Copy

  2. Erstellen Sie die kundenspezifische Rolle GENERIC_SCIM_PROVISIONER. Alle vom IdP erstellten Benutzer und Rollen in Snowflake gehören der Rolle GENERIC_SCIM_PROVISIONER mit eingeschränktem Geltungsbereich.

    create role if not exists generic_scim_provisioner;
grant create user on account to role generic_scim_provisioner;
grant create role on account to role generic_scim_provisioner;
    Copy

  3. Erstellen Sie als ACCOUNTADMIN die Sicherheitsintegration mithilfe der Rolle GENERIC_SCIM_PROVISIONER. Weitere Informationen dazu finden Sie unter CREATE SECURITY INTEGRATION.

    grant role generic_scim_provisioner to role accountadmin;
create or replace security integration generic_scim_provisioning
    type = scim
    scim_client = 'generic'
    run_as_role = 'GENERIC_SCIM_PROVISIONER';
    Copy

  4. Erstellen Sie das Autorisierungstoken, 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('GENERIC_SCIM_PROVISIONING');
    Copy

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 generic_scim_provisioning set network_policy = <scim_network_policy>;
Copy

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

alter security integration generic_scim_provisioning unset network_policy;
Copy

Wobei:

generic_scim_provisioning

Gibt den Namen der kundenspezifische SCIM-Sicherheitsintegration an.

scim_network_policy

Gibt die kundenspezifische 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 kundenspezifischen 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.

Nächste Themen:

Sprache: Deutsch