Snowflake OAuth für benutzerdefinierte Clients konfigurieren

Unter diesem Thema wird beschrieben, wie Sie die Unterstützung von OAuth für benutzerdefinierte Clients konfigurieren.

Unter diesem Thema:

Workflow

Die folgenden allgemeinen Schritte sind erforderlich, um OAuth für benutzerdefinierte Clients zu konfigurieren:

  1. Registrieren Sie Ihren Client bei Snowflake. Erstellen Sie eine Integration, um Ihren Client zu registrieren. Eine Integration ist ein Snowflake-Objekt, das eine Schnittstelle zwischen Snowflake und Services von Drittanbietern bereitstellt, z. B. ein Client, der OAuth unterstützt.

    Der Registrierungsprozess definiert eine Client-ID und Clientgeheimnisse.

  2. Konfigurieren Sie Aufrufe an die Snowflake OAuth -Endpunkte, um Autorisierungscodes vom Snowflake-Autorisierungsserver anzufordern sowie Zugriffstoken anzufordern und zu aktualisieren.

    Mit den optionalen „scope“-Parameter lässt sich bei der erstmaligen Autorisierungsanforderung die vom Zugriffstoken zugelassene Rolle begrenzen. Außerdem können sie zum Konfigurieren des Verhaltens des Aktualisierungstokens verwendet werden.

Schritt 1: OAuth-Integration erstellen

Erstellen Sie mit dem Befehl CREATE SECURITY INTEGRATION eine Integration.

Bemerkung

Dieser SQL-Befehl kann nur von Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) oder von Rollen mit der globalen Berechtigung CREATE INTEGRATION ausgeführt werden.

Blockieren der Verwendung der Integration für bestimmte Rollen

Mit dem optionalen Parameter BLOCKED_ROLES_LIST können Sie Snowflake-Rollen auflisten, denen ein Benutzer mit der Integration nicht ausdrücklich zustimmen kann.

Standardmäßig sind die Rollen des Kontoadministrators (ACCOUNTADMIN) und des Sicherheitsadministrators (SECURITYADMIN) in dieser Liste enthalten und können nicht entfernt werden. Wenn Sie Benutzern aus geschäftlichen Gründen die Verwendung von OAuth bei diesen Rollen gestatten müssen und Ihr Sicherheitsteam damit einverstanden ist, wenden Sie sich an den Snowflake-Support mit der Anforderung, dass die Rollen für Ihr Konto zugelassen werden.

Verwalten von Netzwerkrichtlinien

Snowflake unterstützt Netzwerkrichtlinien für OAuth. Weitere Informationen dazu finden Sie unter OAuth und Netzwerkrichtlinien.

Integrationsbeispiel

Im folgenden Beispiel wird eine OAuth-Integration erstellt, die die Schlüsselpaarauthentifizierung verwendet. Die Integration erlaubt eine Nutzung von Aktualisierungstoken, die nach 1 Tag (86400 Sekunden) ablaufen. Die Integration verhindert, dass Benutzer eine Sitzung mit SYSADMIN als aktiver Rolle starten können:

CREATE SECURITY INTEGRATION oauth_kp_int
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'http://localhost.com'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 86400
  BLOCKED_ROLES_LIST = ('SYSADMIN')
  OAUTH_CLIENT_RSA_PUBLIC_KEY ='
  MIIBI
  ..
  ';

Schritt 2: OAuth-Endpunkte aufrufen

OAuth-Endpunkte sind die URLs, die Clients aufrufen, um Autorisierungscodes anzufordern und um Zugriffstoken anzufordern und zu aktualisieren. Diese Endpunkte verweisen auf bestimmte OAuth 2.0-Richtlinien, die beim Aufrufen des Endpunkts ausgeführt werden.

Snowflake bietet die folgenden OAuth-Endpunkte:

Autorisierung

https://<Kontoname>.snowflakecomputing.com/oauth/authorize

Tokenanforderungen

https://<Kontoname>.snowflakecomputing.com/oauth/token-request

Der Einfachheit halber definiert Snowflake die Endpunkte, wenn ein Client registriert wird. Führen Sie DESCRIBE INTEGRATION aus, um die Endpunkte Ihrer Integration anzuzeigen.

Im folgenden Beispiel werden die Endpunkte der Integration zurückgegeben, die in Schritt 1: OAuth-Integration erstellen (unter diesem Thema) erstellt wurde.

DESC SECURITY INTEGRATION oauth_kp_int;

+----------------------------------+---------------+----------------------------------------------------------------------+------------------+
| property                         | property_type | property_value                                                       | property_default |
|----------------------------------+---------------+----------------------------------------------------------------------+------------------|
...
| OAUTH_AUTHORIZATION_ENDPOINT     | String        | https://myaccount.snowflakecomputing.com/oauth/authorize             |                  |
| OAUTH_TOKEN_ENDPOINT             | String        | https://myaccount.snowflakecomputing.com/oauth/token-request         |                  |
...
+----------------------------------+---------------+----------------------------------------------------------------------+------------------+

Autorisierungsendpunkt

Der Autorisierungsendpunkt wird verwendet, um eine Autorisierungsgewährung zu erhalten, nachdem ein Benutzer einen Client erfolgreich bei Snowflake autorisiert hat. Der Autorisierungsendpunkt lautet wie folgt:

https://<account_name>.snowflakecomputing.com/oauth/authorize

Wobei:

<Kontoname>

Gibt den vollen Namen Ihres Kontos an (bereitgestellt von Snowflake).

Beachten Sie, dass Ihr vollständiger Kontoname möglicherweise zusätzliche Segmente enthält, die die Region und die Cloudplattform angeben, wo Ihr Konto gehostet wird.

Beispiele für Kontonamen nach Region

Wenn Ihr Kontoname beispielsweise xy12345 ist:

Cloudplattform/Region

Vollständiger Kontoname

AWS

US West (Oregon)

xy12345

US East (Ohio)

xy12345.us-east-2.aws

US East (N. Virginia)

xy12345.us-east-1

US East (Commercial Gov - N. Virginia)

xy12345.us-east-1-gov.aws

Canada (Central)

xy12345.ca-central-1.aws

EU (Irland)

xy12345.eu-west-1

EU (Frankfurt)

xy12345.eu-central-1

Asia Pacific (Tokio)

xy12345.ap-northeast-1.aws

Asia Pacific (Mumbai)

xy12345.ap-south-1.aws

Asia Pacific (Singapur)

xy12345.ap-southeast-1

Asia Pacific (Sydney)

xy12345.ap-southeast-2

GCP

US Central1 (Iowa)

xy12345.us-central1.gcp

Europe West2 (London)

xy12345.europe-west2.gcp

Europe West4 (Niederlande)

xy12345.europe-west4.gcp

Azure

West US 2 (Washington)

xy12345.west-us-2.azure

East US 2 (Virginia)

xy12345.east-us-2.azure

US Gov Virginia

xy12345.us-gov-virginia.azure

Canada Central (Toronto)

xy12345.canada-central.azure

West Europe (Niederlande)

xy12345.west-europe.azure

Switzerland North (Zürich)

xy12345.switzerland-north.azure

Southeast Asia (Singapur)

xy12345.southeast-asia.azure

Australia East (New South Wales)

xy12345.australia-east.azure

Wichtig

Wenn eine der folgenden Bedingungen zutrifft, unterscheidet sich Ihr Kontoname von der oben beschriebenen Struktur:

  • Wenn Ihre Snowflake Edition VPS ist, wenden Sie sich an den Snowflake-Support, um Details zu Ihrem Kontonamen zu erhalten.

  • Wenn für Ihr Konto AWS PrivateLink aktiviert ist, muss der Kontoname ein zusätzliches privatelink-Segment enthalten. Weitere Details dazu finden Sie unter AWS PrivateLink & Snowflake.

method

GET

Wichtig

Der Autorisierungsendpunkt muss in einem Browser geöffnet werden, mit dem der Benutzer interagieren kann. Verwenden Sie für diesen Endpunkt nicht cURL.

query parameters

Bemerkung

Die folgenden Parameter sollten URL-codiert sein.

Parameter

Datentyp

Erforderlich

Beschreibung

client_id

String

Ja

Client-ID (von Snowflake bereitgestellt, wenn der Client registriert wird)

response_type

String

Ja

Erstellter Antworttyp. Unterstützt derzeit den Wert code, da Snowflake nur Autorisierungscodes ausgibt.

redirect_uri

String

Ja

URI, an den der Benutzer nach erfolgreicher Autorisierung weitergeleitet wird. Muss mit dem Wert übereinstimmen, der bei der Clientregistrierung bei Snowflake registriert wurde.

state

String

Nein

Zeichenfolge mit maximal 2.048 ASCII-Zeichen, die mit der Antwort vom Snowflake-Autorisierungsserver zurückgegeben wird. Wird in der Regel verwendet, um Site-übergreifende Fälschungsangriffe auf Anforderungen zu verhindern.

scope

String

Nein

Durch Leerzeichen getrennte Zeichenfolge, mit der der Bereich der Zugriffsanforderung begrenzt wird. Weitere Informationen dazu finden Sie unter Bereich (unter diesem Thema).

code_challenge

String

Nein

Abfrage für Proof Key for Code Exchange (PKCE). Zeichenfolge, die über eine geheime und eine Code-Abfragemethode generiert wurde. Weitere Informationen dazu finden Sie unter Proof Key for Code Exchange (PKCE) (unter diesem Thema).

code_challenge_method

String

Nein

Zeichenfolge, die die Methode angibt, mit der die Code-Abfrage für PKCE abgeleitet wurde. Weitere Informationen dazu finden Sie unter Proof Key for Code Exchange (PKCE) (unter diesem Thema).

Wenn ein Benutzer den Client autorisiert, erfolgt eine Weiterleitung an die redirect_uri, die Folgendes in einer GET-Anforderung enthält:

Parameter

Beschreibung

code

Kurzfristiger Autorisierungscode, der am Token-Endpunkt gegen ein Zugriffstoken ausgetauscht werden kann.

state

state-Wert, der in der ursprünglichen Anforderung angegeben und unverändert ist.

scope

Bereich der Zugriffsanforderung; derzeit identisch mit dem Wert scope in der erstmaligen Autorisierungsanforderung, kann sich jedoch in Zukunft unterscheiden. Weitere Informationen dazu finden Sie unter Bereich (unter diesem Thema).

Bereich

Die Bereichsparameter in der anfänglichen Autorisierungsanforderung begrenzen optional die Operationen und die Rolle, die vom Zugriffstoken zugelassen werden.

Der Bereich wird sofort validiert, wenn eine Autorisierungsanforderung bezüglich der Semantik gestellt wird, jedoch nicht unbedingt bezüglich der Gültigkeit. Das heißt, ungültige Bereiche (z. B. „bogus_scope“) werden abgelehnt, bevor der Benutzer sich authentifiziert. Ein Bereich, auf den der Benutzer keinen Zugriff hat (eine bestimmte Rolle usw.), führt jedoch erst nach der Authentifizierung des Benutzers zu einem Fehler. Gültige Bereichsparameter lauten wie folgt:

query parameters

Parameter

Erforderlich

Beschreibung

refresh_token

Nein

Wenn in der Autorisierungs-URL enthalten, bietet Snowflake dem Benutzer die Möglichkeit, dem Offlinezugriff zuzustimmen. In diesem Zusammenhang bezieht sich Offlinezugriff darauf, dass der Client Zugriffstoken aktualisieren darf, wenn der Benutzer nicht anwesend ist. Mit Zustimmung des Benutzers gibt der Autorisierungsserver beim Einlösen des Autorisierungscodes zusätzlich zu einem Zugriffstoken ein Aktualisierungstoken zurück.

session:role:Rollenname

Nein

Wird verwendet, um das Zugriffstoken auf eine einzelne Rolle zu beschränken, der der Benutzer für die Sitzung zustimmen kann. Es kann nur ein Rollenbereich für die Sitzung angegeben werden. Wenn dieser Bereich weggelassen wird, wird stattdessen die Standardrolle für den Benutzer verwendet. Wenn ein Benutzer seine Zustimmung erteilt, zeigt Snowflake immer die Rolle für die Sitzung an, unabhängig davon, ob dieser Bereich in der Autorisierungs-URL enthalten ist. . Beachten Sie, dass Rollenname zwischen Groß- und Kleinschreibung unterscheidet und komplett in Großbuchstaben eingegeben werden muss, es sei denn, der Rollenname wurde bei der Erstellung mit CREATE ROLE in Anführungszeichen gesetzt. Um den Fall zu prüfen, führen Sie in Snowflake SHOW ROLES aus, und entnehmen Sie den Rollennamen der Ausgabe.

Hängen Sie Bereichsparameter an die Autorisierungs-URL an.

Das folgende Beispiel beschränkt die Autorisierung auf die benutzerdefinierte Rolle R1:

scope=session:role:R1

Das folgende Beispiel gibt an, dass Zugriffs-/Aktualisierungstoken die Standardrolle für den Benutzer verwenden und ein Aktualisierungstoken anfordern sollen, damit Offlinezugriff möglich wird:

scope=refresh_token

Das folgende Beispiel beschränkt die Autorisierung auf die benutzerdefinierte Rolle R1 und fordert ein Aktualisierungstoken an, damit Offlinezugriff möglich wird:

scope=refresh_token session:role:SYSADMIN

Token-Endpunkt

Dieser Endpunkt gibt abhängig von den Anforderungsparametern Zugriffstoken oder Aktualisierungstoken zurück. Der Token-Endpunkt lautet wie folgt:

https://<account_name>.snowflakecomputing.com/oauth/token-request

Wobei:

<Kontoname>

Gibt den vollen Namen Ihres Kontos an (bereitgestellt von Snowflake).

Beachten Sie, dass Ihr vollständiger Kontoname möglicherweise zusätzliche Segmente enthält, die die Region und die Cloudplattform angeben, wo Ihr Konto gehostet wird.

Beispiele von Kontonamen für Cloudplattformen und Regionen

Wenn Ihr Kontoname beispielsweise xy12345 ist:

Cloudplattform/Region

Vollständiger Kontoname

AWS

US West (Oregon)

xy12345

US East (Ohio)

xy12345.us-east-2.aws

US East (N. Virginia)

xy12345.us-east-1

US East (Commercial Gov - N. Virginia)

xy12345.us-east-1-gov.aws

Canada (Central)

xy12345.ca-central-1.aws

EU (Irland)

xy12345.eu-west-1

EU (Frankfurt)

xy12345.eu-central-1

Asia Pacific (Tokio)

xy12345.ap-northeast-1.aws

Asia Pacific (Mumbai)

xy12345.ap-south-1.aws

Asia Pacific (Singapur)

xy12345.ap-southeast-1

Asia Pacific (Sydney)

xy12345.ap-southeast-2

GCP

US Central1 (Iowa)

xy12345.us-central1.gcp

Europe West2 (London)

xy12345.europe-west2.gcp

Europe West4 (Niederlande)

xy12345.europe-west4.gcp

Azure

West US 2 (Washington)

xy12345.west-us-2.azure

East US 2 (Virginia)

xy12345.east-us-2.azure

US Gov Virginia

xy12345.us-gov-virginia.azure

Canada Central (Toronto)

xy12345.canada-central.azure

West Europe (Niederlande)

xy12345.west-europe.azure

Switzerland North (Zürich)

xy12345.switzerland-north.azure

Southeast Asia (Singapur)

xy12345.southeast-asia.azure

Australia East (New South Wales)

xy12345.australia-east.azure

Wichtig

Wenn eine der folgenden Bedingungen zutrifft, unterscheidet sich Ihr Kontoname von der oben beschriebenen Struktur:

  • Wenn Ihre Snowflake Edition VPS ist, wenden Sie sich an den Snowflake-Support, um Details zu Ihrem Kontonamen zu erhalten.

  • Wenn für Ihr Konto AWS PrivateLink aktiviert ist, muss der Kontoname ein zusätzliches privatelink-Segment enthalten. Weitere Details dazu finden Sie unter AWS PrivateLink & Snowflake.

method

POST

query parameters

Parameter

Datentyp

Erforderlich

Beschreibung

grant_type

String

Ja

Typ der angeforderten Gewährung: . authorization_code gibt an, dass ein Autorisierungscode gegen ein Zugriffstoken ausgetauscht werden soll. . refresh_token gibt eine Anforderung zum Aktualisieren eines Zugriffstokens an.

code

String

Ja

Vom Token-Endpunkt zurückgegebener Autorisierungscode. Wird verwendet und ist erforderlich, wenn grant_type auf authorization_code gesetzt ist.

refresh_token

String

Ja

Aktualisierungstoken, das von einer früheren Anforderung an den Token-Endpunkt zurückgegeben wurde, als der Autorisierungscode eingelöst wurde. Wird verwendet und ist erforderlich, wenn grant_type auf refresh_token gesetzt ist.

redirect_uri

String

Ja

Leitet die URI wie in der Sicherheitsintegration abgegeben um (siehe Schritt 1: OAuth-Integration erstellen) und wird in der Autorisierungs-URL beim Anfordern eines Autorisierungscodes verwendet. Wird verwendet und ist erforderlich, wenn grant_type auf authorization_code gesetzt ist.

code_verifier

String

Nein

Nur erforderlich, wenn die Autorisierungsanforderung mit einem Parameterwert code_challenge an den Autorisierungsendpunkt gesendet wurde. Codeprüfer für PKCE. Weitere Informationen dazu finden Sie unter Proof Key for Code Exchange (PKCE) (unter diesem Thema).

Die Client-ID und das Clientgeheimnis müssen im Autorisierungsheader enthalten sein. Derzeit unterstützt Snowflake nur das Standardauthentifizierungsschema. Dies bedeutet, dass der erwartete Wert in der folgenden Form vorliegt:

Basic Base64(Client-ID:Clientgeheimnis)

Wobei:

Parameter

Datentyp

Erforderlich

Beschreibung

Client-ID

String

Ja

Client-ID der Integration.

Clientgeheimnis

String

Ja

Clientgeheimnis für die Integration.

Sowohl die Client-ID als auch das Clientgeheimnis können mit der Funktion SYSTEM$SHOW_OAUTH_CLIENT_SECRETS abgerufen werden.

Beachten Sie das Zeichen : zwischen Client-ID und Clientgeheimnis.

post body

Ein JSON-Objekt mit folgenden Attributen wird zurückgegeben:

Parameter

Datentyp

Beschreibung

access_token

String

Zugriffstoken, das zum Einrichten einer Snowflake-Sitzung dient

refresh_token

String

Aktualisierungstoken. Wird nicht ausgestellt, wenn der Client so konfiguriert ist, dass keine Aktualisierungstoken ausgestellt werden, oder wenn der Benutzer dem Bereich refresh_token nicht zugestimmt hat.

expires_in

Ganzzahl (Integer)

Verbleibende Anzahl von Sekunden bis zum Ablauf des Tokens

token_type

String

Typ des Zugriffstokens. Derzeit immer Bearer

username

String

Benutzername, zu dem das Zugriffstoken gehört. Wird derzeit nur zurückgegeben, wenn ein Autorisierungscode gegen ein Zugriffstoken ausgetauscht wird.

Stellen Sie sicher, dass der Content-Type-Header in der POST-Nachricht wie folgt festgelegt ist:

Content-type: application/x-www-form-urlencoded

Beispiel für eine erfolgreiche Antwort

Das folgende Beispiel zeigt eine erfolgreiche Antwort, die beim Austausch eines Autorisierungscodes gegen ein Zugriffs- und Aktualisierungstoken ausgegeben wird:

{
  "access_token":  "ACCESS_TOKEN",
  "expires_in": 600,
  "refresh_token": "REFRESH_TOKEN",
  "token_type": "Bearer",
  "username": "user1",
}

Beispiel für eine erfolglose Antwort

Das folgende Beispiel zeigt eine erfolglose Antwort:

{
  "data" : null,
  "message" : "This is an invalid client.",
  "code" : null,
  "success" : false,
  "error" : "invalid_client"
}

Der Zeichenfolgenwert message ist eine Beschreibung des Fehlers, während error der Fehlertyp ist. Weitere Informationen zu den zurückgegebenen Fehlertypen finden Sie im Abschnitt Fehler (unter diesem Thema).

Proof Key for Code Exchange (PKCE)

Snowflake unterstützt Proof Key for Code Exchange (PKCE) zum Abrufen von Zugriffstoken mit dem Gewährungstyp authorization_code, wie in RFC 7636 beschrieben. PKCE kann verwendet werden, um die Möglichkeit von Abfangangriffen auf Autorisierungscodes zu verringern, und ist für Clients geeignet, die möglicherweise nicht in der Lage sind, das Clientgeheimnis vollständig zu wahren.

Standardmäßig ist PKCE optional und wird nur erzwungen, wenn die Parameter code_challenge und code_challenge_method beide in der URL des Autorisierungsendpunkts enthalten sind. Wir empfehlen jedoch dringend, dass Ihr Client für alle Autorisierungen PKCE benötigt, um den OAuth-Fluss sicherer zu gestalten.

Im Folgenden wird beschrieben, wie PKCE for Snowflake funktioniert:

  1. Der Client erstellt ein Geheimnis namens code verifier und führt eine Transformation damit durch, um die code challenge zu generieren. Der Client hat die Kontrolle über das Geheimnis.

    Wichtig

    Er generiert den Codeverifizierer aus den zulässigen ASCII-Zeichen gemäß Abschnitt 4.1 von RFC 7636.

  2. Beim Weiterleiten des Benutzer zur Autorisierungs-URL hängt der Client die folgenden zwei Abfrageparameter an:

    code_challenge

    Gibt die in Schritt 1 generierte Code-Challenge an.

    code_challenge_method

    Gibt die Transformationen an, die in Schritt 1 auf den Codeprüfer angewendet werden, um die Code-Challenge zu generieren. Derzeit unterstützt Snowflake nur SHA256, daher muss dieser Wert auf S256 gesetzt werden. Der Transformationsalgorithmus für SHA256 ist BASE64URL-ENCODE(SHA256(ASCII(code_verifier))).

  3. Nachdem der Benutzer den angeforderten Bereichen zugestimmt hat oder Snowflake feststellt, dass für diesen Benutzer eine Zustimmung vorliegt, wird der Autorisierungscode ausgegeben.

  4. Der Client erhält den Autorisierungscode vom Snowflake-Autorisierungsserver, den er dann zusammen mit dem code_verifier in der Anforderung an den Token-Endpunkt sendet.

  5. Snowflake transformiert den Wert code_verifier und prüft, ob der transformierte Wert mit dem Wert code_challenge übereinstimmt, der beim Generieren von Autorisierungen verwendet wird. Stimmen diese Werte überein, stellt der Autorisierungsserver die Zugriffs- und Aktualisierungstoken aus.

Verwenden der Schlüsselpaar-Authentifizierung

Snowflake unterstützt beim Aufrufen des OAuth-Token-Endpunkts die Verwendung der Schlüsselpaar-Authentifizierung anstelle der typischen Authentifizierung durch Benutzernamen und Kennwort. Dieses Authentifizierungsverfahren erfordert ein 2048-Bit-RSA-Schlüsselpaar (Minimum). Generieren Sie das öffentlich-private PEM (Privacy Enhanced Mail)-Schlüsselpaar unter Verwendung von OpenSSL. Der öffentliche Schlüssel wird dem Snowflake-Benutzer zugewiesen, der den Snowflake-Client verwendet.

So konfigurieren Sie das Public/Private-Schlüsselpaar:

  1. Generieren Sie von der Befehlszeile in einem Terminalfenster aus einen privaten Schlüssel:

    $ openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8
    

    OpenSSL fragt nach einer Passphrase, die zur Verschlüsselung der privaten Schlüsseldatei verwendet wird. Wir empfehlen, zum Schutz des privaten Schlüssels eine starke Passphrase zu verwenden. Notieren Sie sich diese Passphrase. Sie müssen sie beim Herstellen der Verbindung mit Snowflake eingeben. Beachten Sie, dass die Passphrase nur zum Schutz des privaten Schlüssels verwendet wird und niemals an Snowflake gesendet wird.

    Beispiel für einen privaten PEM-Schlüssel

    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIIE6TAbBgkqhkiG9w0BBQMwDgQILYPyCppzOwECAggABIIEyLiGSpeeGSe3xHP1
    wHLjfCYycUPennlX2bd8yX8xOxGSGfvB+99+PmSlex0FmY9ov1J8H1H9Y3lMWXbL
    ...
    -----END ENCRYPTED PRIVATE KEY-----
    
  2. Generieren Sie über die Befehlszeile den öffentlichen Schlüssel, indem Sie auf den privaten Schlüssel verweisen:

    $ openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub
    

    Beispiel für einen öffentlichen PEM-Schlüssel

    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy+Fw2qv4Roud3l6tjPH4
    zxybHjmZ5rhtCz9jppCV8UTWvEXxa88IGRIHbJ/PwKW/mR8LXdfI7l/9vCMXX4mk
    ...
    -----END PUBLIC KEY-----
    
  3. Kopieren Sie die Dateien der öffentlichen und privaten Schlüssel zur Speicherung in ein lokales Verzeichnis. Zeichnen Sie den Pfad zu den Dateien auf.

    Beachten Sie, dass der private Schlüssel im Format PKCS#8 (Public Key Cryptography Standards) gespeichert und mit der im vorherigen Schritt angegebenen Passphrase verschlüsselt wird; die Datei sollte jedoch weiterhin mit dem von Ihrem Betriebssystem bereitgestellten Dateiberechtigungsmechanismus vor unbefugtem Zugriff geschützt sein. Es liegt in Ihrer Verantwortung, die Datei zu sichern, wenn sie nicht verwendet wird.

  4. Weisen Sie den öffentlichen Schlüssel mit ALTER SECURITY INTEGRATION dem Integrationsobjekt zu. Beispiel:

    ALTER SECURITY INTEGRATION myint SET OAUTH_CLIENT_RSA_PUBLIC_KEY='MIIBIjANBgkqh...';
    

    Bemerkung

    • Nur Kontoadministratoren können den ALTERSECURITYINTEGRATION-Befehl ausführen.

    • Schließen Sie die Kopf- und Fußzeile des öffentlichen Schlüssels in dem Befehl aus.

    Überprüfen Sie den Fingerabdruck des öffentlichen Schlüssels mithilfe von DESCRIBE INTEGRATION:

    DESC SECURITY INTEGRATION myint;
    
    +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
    | property                         | property_type | property_value                                                       | property_default |
    |----------------------------------+---------------+----------------------------------------------------------------------+------------------|
    ...
    | OAUTH_CLIENT_RSA_PUBLIC_KEY_FP   | String        | SHA256:MRItnbO/123abc/abcdefghijklmn12345678901234=                  |                  |
    | OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP | String        |                                                                      |                  |
    ...
    +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
    

    Bemerkung

    Eine Beschreibung der Eigenschaft OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP finden Sie unter Schlüsselrotation (unter diesem Thema).

  5. Ändern Sie den unten stehenden Beispielcode, und führen Sie ihn aus. Der Code entschlüsselt die Datei, die den privaten Schlüssel enthält, und übergibt sie an den Snowflake-Autorisierungsserver:

  • Aktualisieren Sie die Sicherheitsparameter:

    • <Privater_Schlüssel>: Öffnen Sie die Datei rsa_key.p8 in einem Texteditor, und kopieren Sie die Zeilen zwischen:

    -----BEGIN RSA PRIVATE KEY-----
    ...
    -----END RSA PRIVATE KEY-----
    
  • Aktualisieren Sie die Sitzungsparameter:

    • <account_name>: Gibt den vollen Namen Ihres Kontos an (bereitgestellt von Snowflake).

  • Aktualisieren Sie die JWT-Felder (JSON Web Token):

    post body

    Ein JSON-Objekt mit den folgenden Standardfeldern („Ansprüche“):

    Attribut

    Datentyp

    Erforderlich

    Beschreibung

    iss

    String

    Ja

    Gibt den Prinzipal an, der das JWT im Format Client-ID.öffentlicher_Schlüssel_Fingerabdr ausgegeben hat, wobei Client-ID die Client-ID der OAuth-Clientintegration ist und öffentlicher_Schlüssel_Fingerabdr der Fingerabdruck des öffentlichen Schlüssels ist, der bei der Überprüfung verwendet wird.

    sub

    String

    Ja

    Subjekt des JWT im Format Kontoname.Client-ID, wobei Kontoname der Name des Snowflake-Kontos ist und Client-ID die Client-ID der OAuth-Clientintegration ist. Abhängig von der Cloudplattform (AWS oder Azure) und der Region, wo Ihr Konto gehostet wird, erfordert der vollständige Kontoname möglicherweise zusätzliche Segmente. Weitere Informationen dazu finden Sie in der Beschreibung der Konto-Variablen unter Token-Endpunkt.

    iat

    Zeitstempel

    Nein

    Zeitpunkt, zu dem das Token ausgestellt wurde.

    exp

    Zeitstempel

    Ja

    Zeitpunkt, zu dem das Token ablaufen soll. Dieser Zeitraum sollte relativ kurz sein (z. B. einige Minuten).

Beispielcode

import datetime
import json
import urllib

import jwt
import requests

private_key = """
-----BEGIN RSA PRIVATE KEY-----
<private_key>
-----END RSA PRIVATE KEY-----"""

public_key_fp = "SHA256:MR..."


def _make_request(payload, encoded_jwt_token):
    token_url = "https://<account_name>.snowflakecomputing.com/oauth/token-request"
    headers = {
            u'Authorization': "Bearer %s" % (encoded_jwt_token),
            u'content-type': u'application/x-www-form-urlencoded'
    }
    r = requests.post(
            token_url,
            headers=headers,
            data=urllib.urlencode(payload))
    return r.json()


def make_request_for_access_token(oauth_az_code, encoded_jwt_token):
    """ Given an Authorization Code, make a request for an Access Token
    and a Refresh Token."""
    payload = {
        'grant_type': 'authorization_code',
        'code': oauth_az_code
    }
    return _make_request(payload, encoded_jwt_token)


def make_request_for_refresh_token(refresh_token, encoded_jwt_token):
    """ Given a Refresh Token, make a request for another Access Token."""
    payload = {
        'grant_type': 'refresh_token',
        'refresh_token': refresh_token
    }
    return _make_request(payload, encoded_jwt_token)


def main():
    account_name = "<account_name>"
    client_id = "1234"  # found by running DESC SECURITY INTEGRATION
    issuer = "{}.{}".format(client_id, public_key_fp)
    subject = "{}.{}".format(account_name, client_id)
    payload = {
        'iss': issuer,
        'sub': subject,
        'iat': datetime.datetime.utcnow(),
        'exp': datetime.datetime.utcnow() + datetime.timedelta(seconds=30)
    }
    encoded_jwt_token = jwt.encode(
            payload,
            private_key,
            algorithm='RS256')

    data = make_request_for_access_token(oauth_az_code, encoded_jwt_token)
    refresh_token = data['refresh_token']
    data = make_request_for_refresh_token(refresh_token, encoded_jwt_token)
    access_token = data['access_token']


if __name__ == '__main__':
    main()

Nachdem das Token erstellt wurde, senden Sie es auf Anforderung an den Token-Endpunkt. Anforderungen erfordern das Bearer-Autorisierungsformat als Autorisierungsheader anstelle des Standardautorisierungsformats, das normalerweise für die Client-ID und das Clientgeheimnis verwendet wird, wie folgt:

"Authorization: Bearer JWT_TOKEN"

Schlüsselrotation

Snowflake unterstützt mehrere aktive Schlüssel, um eine ununterbrochene Rotation zu ermöglichen. Rotieren und ersetzen Sie Ihre öffentlichen und privaten Schlüssel basierend auf dem Ablaufzeitplan, den Sie intern befolgen.

Derzeit können Sie die Parameter OAUTH_CLIENT_RSA_PUBLIC_KEY und OAUTH_CLIENT_RSA_PUBLIC_KEY_2 für ALTER SECURITY INTEGRATION verwenden, um einem einzelnen Benutzer bis zu zwei öffentliche Schlüssel zuzuordnen.

So rotieren Sie Ihre Schlüssel:

  1. Führen Sie die unter Verwenden der Schlüsselpaar-Authentifizierung (unter diesem Thema) angegebenen Schritte aus:

    • Generieren eines neuen privaten und öffentlichen Schlüsselsatz.

    • Zuweisen des öffentlichen Schlüssels an die Integration Setzen des Werts des öffentlichen Schlüssels entweder auf OAUTH_CLIENT_RSA_PUBLIC_KEY oder OAUTH_CLIENT_RSA_PUBLIC_KEY_2 (je nachdem, welcher Schlüsselwert gerade nicht verwendet wird). Beispiel:

      alter integration myint set oauth_client_rsa_public_key_2='JERUEHtcve...';
      
  2. Aktualisieren Sie den Code, um eine Verbindung zu Snowflake herzustellen. Geben Sie den neuen privaten Schlüssel an.

    Snowflake überprüft den korrekten aktiven öffentlichen Schlüssel für die Authentifizierung basierend auf dem übermittelten privaten Schlüssel.

  3. Entfernen Sie den alten öffentlichen Schlüssel aus der Integration. Beispiel:

    alter integration myint unset rsa_public_key;
    

Fehler

Die folgenden Fehlercodes sind mit OAuth verknüpft und können während des Autorisierungsflusses, des Token-Austauschs oder der Erstellung einer Snowflake-Sitzung nach Abschluss des OAuth-Flusses zurückgegeben werden:

Fehlercode

Fehler

Beschreibung

390302

OAUTH_CONSENT_INVALID

Problem mit dem Generieren oder Validieren von Zustimmung für einen bestimmten Benutzer

390303

OAUTH_ACCESS_TOKEN_INVALID

Das Zugriffstoken, das beim Versuch, eine Snowflake-Sitzung herzustellen, angegeben wurde, ist abgelaufen oder ungültig.

390304

OAUTH_AUTHORIZE_INVALID_RESPONSE_TYPE

Es wurde ein ungültiger Antworttyp response_type als Parameter für den Autorisierungsendpunkt angegeben (er sollte höchstwahrscheinlich code lauten).

390305

OAUTH_AUTHORIZE_INVALID_STATE_LENGTH

Der Statusparameter, der als Parameter für den Autorisierungsendpunkt angegeben ist, überschreitet 2.048 Zeichen

390306

OAUTH_AUTHORIZE_INVALID_CLIENT_ID

Die mit einer angegebenen Client-ID verknüpfte Integration ist nicht vorhanden.

390307

OAUTH_AUTHORIZE_INVALID_REDIRECT_URI

Die redirect_uri, die als Parameter für den Autorisierungsendpunkt angegeben ist, stimmt nicht mit der redirect_uri der Integration überein, die mit der angegebenen client_id verknüpft ist, oder die redirect_uri ist nicht korrekt formatiert.

390308

OAUTH_AUTHORIZE_INVALID_SCOPE

Entweder ist der angeforderte Bereich kein gültiger Bereich, oder dem Benutzer kann kein vollständiger Zugriff auf die angeforderten Bereiche gewährt werden.

Darüber hinaus werden die folgenden Fehler aus dem RFC übernommen und im JSON-Blob zurückgegeben, das während einer nicht erfolgreichen Tokenanforderung oder eines fehlgeschlagenen Tokenaustauschs erstellt wurde:

Fehler

Beschreibung

invalid_client

In Bezug auf die Clientauthentifizierung ist ein Fehler aufgetreten, z. B. war der Client unbekannt, lag ein Konflikt des Clientgeheimnisses vor usw.

invalid_grant

Die angegebene Autorisierungsgewährung oder das Aktualisierungstoken sind ungültig, abgelaufen, widerrufen, stimmen nicht mit dem in der Autorisierungsanforderung verwendeten Weiterleitungs-URI überein oder wurden an einen anderen Client ausgestellt.

unsupported_grant_type

Es wurde ein Gewährungstyp bereitgestellt, den Snowflake derzeit nicht unterstützt („refresh_toke“ und „authorized_code“ sind derzeit die einzigen unterstützten Gewährungstypen).

invalid_request

Die Anforderung war falsch formatiert oder konnte nicht verarbeitet werden.