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.

Übersicht zu SCIM

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

  • 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, Azure AD und die kundenspezifische 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

string

Der unveränderliche, eindeutige Bezeichner (d. h. GUID) des Benutzers in Snowflake.

Snowflake zeigt diesen Wert weder in der DESCRIBE USER- noch in der SHOW USERS-Ausgabe an.

Bei bestimmten Anforderungspfaden, die dieses Attribut enthalten (z. B. PATCH), kann id durch Aufruf der Tabellenfunktion REST_EVENT_HISTORY ermittelt werden.

Überprüfen Sie die IdP-Protokolle, um sicherzustellen, dass die Werte übereinstimmen.

userName

userName, loginName

string

Der Bezeichner für die Anmeldung bei Snowflake. Weitere Informationen zu diesen Snowflake-Attributen finden Sie unter CREATE USER.

name.givenName

firstName

string

Der Vorname des Benutzers.

name.familyName

familyName

string

Der Nachname des Benutzers.

emails

email

string

Die E-Mail Adresse des Benutzers. Der Wert unterstützt eine einzelne E-Mail-Adresse.

displayName

displayName

string

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

externalID

N/A

string

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

password

password

string

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

Hinweis: Wenn die Eigenschaft SYNC_PASSWORD der SCIM-Sicherheitsintegration auf FALSE gesetzt ist und die SCIM-API-Anforderung das Attribut password angibt, ignoriert Snowflake den Wert für das Attribut password. Alle anderen Attribute in der API-Anforderung werden entsprechend verarbeitet.

active

disabled

Boolean

Deaktiviert den Benutzer, wenn false eingestellt ist.

groups

N/A

string

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

string

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

meta.lastModified

lastModified

string

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

meta.resourceType

N/A

string

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

schemas

N/A

string

Ein durch Kommas getrenntes Array von Zeichenfolgen, das die Namespace-URIs angibt. Zu den unterstützten Werten gehören:

  • 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:2.0:User

Kundenspezifische Attribute

Snowflake unterstützt das Festlegen von kundenspezifischen Attributen, die nicht durch RFC 7643 definiert sind, wie defaultRole, defaultWarehouse und defaultSecondaryRoles.

Derzeit unterstützt Snowflake die Verwendung von zwei Namespaces, um kundenspezifische Attribute für die folgenden POST-, PUT- und PATCH API-Anforderungen festzulegen:

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

Dieser Namespace war Teil der ursprünglichen SCIM-Implementierung in Snowflake und kann nur verwendet werden, um kundenspezifische Attribute für Okta-SCIM-Integrationen festzulegen.

Dieser Namespace wird nicht unterstützt, um kundenspezifische Attribute für Microsoft Azure-SCIM-Integrationen oder kundenspezifische SCIM-Integrationen festzulegen.

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

Dieser neuere Namespace kann zum Festlegen von kundenspezifischen Attributen für alle SCIM-Integrationen verwendet werden und muss für kundenspezifische Attribute entweder mit einer kundenspezifischen SCIM-Integration oder einer Microsoft Azure-SCIM-Integration verwendet werden.

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

GET scim/v2/Users?filter=userName eq "{{user_name}}"

Gibt bei Erfolg Details des Benutzerkontos mit dem entsprechenden userName und mit dem HTTP-Statuscode 200 zurück.

Details zu einem bestimmten Benutzer abrufen

GET scim/v2/Users/{{user_id}}

Gibt bei Erfolg Details des Benutzerkontos mit dem entsprechenden user_id und mit dem HTTP-Statuscode 200 zurück.

Details zu einem bestimmten Benutzer abrufen

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

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

Benutzer erstellen

POST scim/v2/Users

Erstellt einen Benutzer in Snowflake und gibt bei Erfolg den HTTP-Statuscode 201 zurück.

Wenn der Benutzer bereits existiert oder ein anderer Konflikt auftritt, gibt Snowflake den HTTP-Statuscode 409 zurück.

Benutzer mit Teilattributen aktualisieren

PATCH scim/v2/Users/{id}

Deaktiviert den entsprechenden Benutzer, wenn der 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 HTTP-Statuscode 200 zurück, andernfalls 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 die Änderung unveränderlicher Attribute angefordert wird.

Andernfalls werden die Schreib- oder Leseattribute basierend auf der Anforderung ersetzt.

Gibt den HTTP-Statuscode 400 zurück, wenn die unveränderlichen Attributwerte im Anforderungstext nicht mit den Werten in Snowflake übereinstimmen.

Benutzer löschen

DELETE scim/v2/Users/{id}

Weitere Informationen zu SCIM-API-Anforderungen finden Sie unter Erstellen einer SCIM-API-Anforderung.

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
}
Copy

Benutzer mit userName und loginName erstellen, die unterschiedlichen Werten zugeordnet sind

Wenn Okta Ihr Identitätsanbieter ist, führen Sie diese 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"
}
Copy
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
        }
    }]
}
Copy

Benutzer mit userName und loginName aktualisieren, die verschiedenen Werten zugeordnet sind.

Wenn Okta Ihr Identitätsanbieter ist, führen Sie diese 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"
    ]
}
Copy
PUT scim/v2/Users/{ID}

Aktualisieren Sie einen Benutzer, einschließlich der Einstellungen in den Feldern "defaultRole", "defaultSecondaryRoles" und "defaultWarehouse".

Um die Eigenschaften "defaultRole", "defaultSecondaryRoles" und "defaultWarehouse" zu spezifizieren, benötigt Snowflake unbedingt eines der extension-Schemas. Beachten Sie, dass der einzig mögliche Wert für defaultSecondaryRoles der Wert "ALL" ist.

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

Verwalten von Rollen mit SCIM

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

String

Der unveränderliche, eindeutige Bezeichner (d. h. GUID) der Rolle in Snowflake.

Snowflake zeigt diesen Wert nicht an. Er kann durch Aufruf der Information Schema-Tabellenfunktion REST_EVENT_HISTORY ermittelt werden.

Überprüfen Sie die IdP-Protokolle, um sicherzustellen, dass die Werte übereinstimmen.

displayName

name

String

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

members.value

N/A

String

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

schemas

N/A

String

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 die Details der Gruppe mit dem angegebenen displayName und mit dem HTTP-Statuscode 200 zurück.

Gruppe anhand ihrer Gruppen-ID (groupId) abrufen

GET scim/v2/Groups/{group_id}

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

Beispielgruppe abrufen

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

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

Neue Gruppe erstellen

POST scim/v2/Groups

Erstellt bei Erfolg eine neue Gruppe mit dem HTTP-Statuscode 201.

Gruppe aktualisieren

PATCH scim/v2/Groups/{id}

Aktualisiert das Attribut für den Gruppenanzeigenamen oder die Gruppenmitgliedschaft.

PATCH erfordert einen Operationsschlüssel (d. h. op) mit einem Array, das angibt, ob hinzugefügt oder ersetzt werden soll.

Gibt bei Erfolg den HTTP-Statuscode 200 zurück, andernfalls 204 (d. h. kein Inhalt).

Gruppe löschen

DELETE scim/v2/Groups/{id}

Weitere Informationen zu SCIM-API-Anforderungen finden Sie unter Erstellen einer SCIM-API-Anforderung.

POST scim/v2/Groups
{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "displayName":"scim_test_group2"
}
Copy
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"
            }]
        }
    ]
}
Copy

Ü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 den Aufruf der Information Schema-Tabellenfunktion 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',
        dateadd('minutes',-5,current_timestamp()),
        current_timestamp(),
        200))
    order by event_timestamp;
Copy

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

    Bemerkung

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

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

Verwenden der Replikation mit SCIM

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: