Oracle Cloud Infrastructure - Dokumentation

JWT_AUTHENTICATION-Authentifizierungsanforderungs-Policy verwenden (nicht mehr empfohlen)

Wenn ein Endbenutzer eine Authentifizierungsanforderungs-Policy vom Typ JWT_AUTHENTICATION verwendet, muss er ein JWT von einem Identitätsprovider abrufen, bevor er auf ein API-Deployment zugreifen kann, das JSON-Web-Token (JWTs) zur Authentifizierung und Autorisierung nutzt.

Hinweis

In früheren Releases haben Sie möglicherweise Authentifizierungsanforderungs-Policys vom Typ JWT_AUTHENTICATION erstellt, um JWTs für die Authentifizierung zu verwenden.

Wenn Sie neue Authentifizierungsanforderungs-Policys zur Verwendung von JWTs erstellen, wird jetzt empfohlen, stattdessen Authentifizierungsanforderungs-Policys vom Typ TOKEN_AUTHENTICATION zu erstellen (siehe Tokenauthentifizierungs- und Autorisierungsanforderungs-Policys mit der Konsole hinzufügen und JSON-Datei zum Hinzufügen von Tokenauthentifizierungs- und Autorisierungsanforderungs-Policys bearbeiten). Außerdem wird empfohlen, vorhandene JWT_AUTHENTICATION-Anforderungs-Policys in TOKEN_AUTHENTICATION-Policys zu migrieren.

Beachten Sie, dass vorhandene JWT_AUTHENTICATION-Anforderungs-Policys derzeit noch unterstützt werden. Beachten Sie außerdem, dass Sie zwar neue JWT_AUTHENTICATION-Anforderungs-Policys erstellen können, indem Sie die API-Deployment-Spezifikation in einer JSON-Datei definieren (wie in den ursprünglichen Anweisungen in diesem Abschnitt beschrieben), dass Sie jedoch stattdessen Authentifizierungsanforderungs-Policys vom Typ TOKEN_AUTHENTICATION erstellen sollten.

Beim Aufrufen einer API, die in einem API-Gateway bereitgestellt ist, stellt der API-Client das JWT als Abfrageparameter oder im Header der Anforderung bereit. Das API-Gateway validiert das JWT mit einem entsprechenden öffentlichen Prüfschlüssel, der vom ausstellenden Identitätsprovider bereitgestellt wird. Mit der JWT_AUTHENTICATION-Authentifizierungsanforderungs-Policy des API-Deployments können Sie konfigurieren, wie das API-Gateway JWTs validiert:

  • Sie können das API-Gateway so konfigurieren, dass öffentliche Prüfschlüssel zur Laufzeit vom Identitätsprovider abgerufen werden. In diesem Fall fungiert der Identitätsprovider als Autorisierungsserver.
  • Sie können das API-Gateway im Voraus mit öffentlichen Prüfschlüsseln konfigurieren, die bereits von einem Identitätsprovider ausgestellt wurden (sogenannte "statische Schlüssel"). So kann das API-Gateway JWTs zur Laufzeit lokal verifizieren, ohne den Identitätsprovider kontaktieren zu müssen. Das Ergebnis ist eine schnellere Tokenvalidierung.

So fügen Sie einer API-Deployment-Spezifikation in einer JSON-Datei eine neue JWT_AUTHENTICATION-Authentifizierungs- und Autorisierungsanforderungs-Policy hinzu:

  1. Fügen Sie eine authentication-Anforderungs-Policy hinzu, die für alle Routen in der API-Deployment-Spezifikation gilt:

    1. Fügen Sie, falls noch nicht vorhanden, einen requestPolicies-Abschnitt vor dem routes-Abschnitt ein. Beispiel:

      
{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}

    2. Fügen Sie die folgende authentication-Policy zum neuen requestPolicies-Abschnitt hinzu. 

      {
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": <true|false>,
      "issuers": ["<issuer-url>", "<issuer-url>"],
      <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">,
      "tokenAuthScheme": "<authentication-scheme>",
      "audiences": ["<intended-audience>"],
      "publicKeys": {
        "type": <"REMOTE_JWKS"|"STATIC_KEYS">,
        <public-key-config>
      },
      "verifyClaims": [
        {"key": "<claim-name>",
         "values": ["<acceptable-value>", "<acceptable-value>"],
         "isRequired": <true|false>
        }
      ],
      "maxClockSkewInSeconds": <seconds-difference>
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}

      Dabei gilt:

      • "isAnonymousAccessAllowed": <true|false> gibt optional an, ob nicht authentifizierte (d.h. anonyme) Endbenutzer auf Routen in der API-Deployment-Spezifikation zugreifen können. Wenn Sie den Zugriff anonymer Endbenutzer auf Routen nie zulassen möchten, setzen Sie diese Eigenschaft auf false. Wenn Sie diese Eigenschaft nicht in die authentication-Policy aufnehmen, wird standardmäßig false verwendet. Hinweis: Wenn Sie diese Eigenschaft aufnehmen und auf true setzen, müssen Sie auch explizit jede Route angeben, auf die anonym zugegriffen werden kann. Setzen Sie dazu in der authorization-Policy jeder einzelnen Route die type-Eigenschaft auf "ANONYMOUS".
      • <issuer-url> ist die URL (oder eine Textzeichenfolge) für einen Identitätsprovider, die im Ausstellerclaim (iss) eines JWT für den Zugriff auf das API-Deployment zulässig ist. Beispiel: Um ein von OCI IAM ausgestelltes JWT mit Identitätsdomains für den Zugriff auf die API-Bereitstellung zu aktivieren, geben Sie https://identity.oraclecloud.com/ ein. Sie können einen oder mehrere Identitätsprovider angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
      • <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> gibt an, ob dies ein Anforderungsheader ist, der das JWT enthält (wenn ja, wird der Name des Headers angegebenen), oder ob ein Abfrageparameter, der das JWT enthält (wenn ja, wird der Name des Abfrageparametersangegeben). Beachten Sie, dass Sie entweder "tokenHeader": "<token-header-name>" oder "tokenQueryParam": "<token-query-param-name>"> angeben können, aber nicht beides.
      • <tokenAuthScheme> ist der Name des Authentifizierungsschemas, das verwendet werden soll, wenn das JWT in einem Anforderungsheader enthalten ist. Beispiel: "Bearer".
      • <intended-audience> ist ein Wert, der im Zielgruppenclaim (aud) eines JWT zur Identifikation des beabsichtigten Empfängers des Tokens zulässig ist. Beispiel: Die Zielgruppe kann (muss aber nicht) dem Hostnamen des API-Gateways entsprechen. Sie können eine oder mehrere Zielgruppen angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
      • "type": <"REMOTE_JWKS"|"STATIC_KEYS"> gibt an, wie das API-Gateway JWTs mit öffentlichen Prüfschlüsseln validieren soll. Geben Sie REMOTE_JWKS an, um das API-Gateway so zu konfigurieren, das bis zu zehn öffentliche Prüfschlüssel zur Laufzeit vom Identitätsprovider abgerufen werden. Geben Sie STATIC_KEYS an, um das API-Gateway mit bis zu zehn öffentlichen Prüfschlüsseln zu konfigurieren, welche bereits von einem Identitätsprovider ausgestellt wurden (sodass das API-Gateway JWTs lokal verifizieren kann, ohne dass der Identitätsprovider kontaktiert werden müssen).

      • <public-key-config> stellt die Details der JWT-Validierung je nachdem, ob Sie "REMOTE_JWKS" oder "STATIC_KEYS" als Wert von "type": angegeben haben, wie folgt bereit:

        • Wenn Sie "type": "REMOTE_JWKS" angegeben haben, um das API-Gateway für die Validierung von JWTs durch das Abrufen öffentlicher Prüfschlüssel vom Identitätsprovider zur Laufzeit zu konfigurieren, geben Sie folgende Details an:

                "publicKeys": {
        "type": "REMOTE_JWKS",
        "uri": "<uri-for-jwks>",
        "maxCacheDurationInHours": <cache-time>,
        "isSslVerifyDisabled": <true|false>
      }

          Dabei gilt:

          • "uri": "<uri-for-jwks>" gibt die URI an, von der das JSON Web Key Set (JWKS) abgerufen werden soll, mit dem die Signatur der JWTs verifiziert werden soll. Weitere Informationen über die anzugebende URI finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI. Beachten Sie dabei Folgendes:
            • Die URI muss aus dem Subnetz mit dem API-Gateway routbar sein, in dem die API bereitgestellt wird.
            • Wenn das API-Gateway das JWKS nicht abrufen kann, geben alle Anforderungen an das API-Deployment einen HTTP 500-Antwortcode zurück. Weitere Informationen zum Fehler finden Sie im Ausführungslog des API-Gateways (siehe Logging zu API-Deployments hinzufügen).
            • Bestimmte Schlüsselparameter müssen im JWKS vorhanden sein, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen).
            • Der JWKS kann bis zu zehn Schlüssel enthalten.
          • "maxCacheDurationInHours": <cache-time> gibt an, wieviele Stunden (zwischen 1 und 24) lang das API-Gateway das JWKS nach den Abruf cachen soll.
          • "isSslVerifyDisabled": <true|false> gibt an, ob die SSL-Überprüfung bei der Kommunikation mit dem Identitätsprovider deaktiviert werden soll. Oracle empfiehlt, diese Option nicht auf true zu setzen, weil sie die JWT-Validierung kompromittieren kann. API Gateway vertraut Zertifikaten von mehreren Certificate Authoritys, die für OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0 und Okta ausgestellt werden.

          Beispiel:

                "publicKeys": {
        "type": "REMOTE_JWKS",
        "uri": "https://www.somejwksprovider.com/oauth2/v3/certs",
        "maxCacheDurationInHours": 3,
        "isSslVerifyDisabled": false
      }

        • Wenn Sie "type": "STATIC_KEYS" angegeben haben, hängen die anzugebenden Details davon ab, welches Format der Schlüssel bereits vom Identitätsprovider ausgestellt wurde (unabhängig vom Format können Sie bis zu zehn Schlüssel angeben):

          • Wenn es sich bei dem statischen Schlüssel um einen JSON Web Key handelt, geben Sie "format": "JSON_WEB_KEY" an, geben Sie die ID des statischen Schlüssels zum Signieren des JWT als Wert des "kid"-Parameters an, und geben Sie Werte für weitere Parameter zur Überprüfung der JWT-Signatur an.

            Beispiel:

                            
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]

            Beachten Sie, dass bestimmte Parameter im statischen Schlüssel vorhanden sein müssen, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen). Beachten Sie auch, dass RSA derzeit der einzige unterstützte Schlüsseltyp (kty) ist.

          • Wenn es sich bei dem statischen Schlüssel um einen PEM-codierten Public Key handelt, geben Sie "format": "PEM" an, geben Sie die ID des statischen Schlüssels zum Signieren des JWT als Wert von "kid" an, und geben Sie den Schlüssel als Wert von "key" an.

            Beispiel:

                            
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "PEM",
            "kid": "master_key"
            "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY-----
          }
        ]

            Beachten Sie, dass die Marker -----BEGIN PUBLIC KEY----- und -----END PUBLIC KEY----- erforderlich sind.

      • verifyClaims gibt optional zusätzliche Claimnamen und -werte für einen oder mehrere zusätzliche Claims zur Überprüfung in einem JWT an (maximal zehn).
        • "key": "<claim-name>" ist der Name eines Claims, der in einem JWT enthalten sein kann oder muss. Der angegebene Claimname kann ein reservierter Claimname sein, wie der Subject-Claim (sub), oder ein benutzerdefinierter Claimname, der von einem bestimmten Identitätsprovider ausgestellt wird.
        • "values": ["<acceptable-value>", "<acceptable-value>"] (optional) gibt einen oder mehrere zulässige Werte für den Claim an.
        • "isRequired": <true|false> gibt an, ob der Claim im JWT enthalten sein muss.

        Beachten Sie, dass alle eingegebenen Schlüsselnamen und -werte einfach wie Zeichenfolgen behandelt werden und exakt mit den Namen und Werten im JWT übereinstimmen müssen. Das Abgleichen von Mustern und andere Datentypen werden nicht unterstützt.

      • maxClockSkewInSeconds: <seconds-difference> gibt optional den maximalen Zeitunterschied zwischen den Systemuhren des Identitätsproviders, der ein JWT ausgestellt hat, und dem API-Gateway an. Der angegebene Wert wird berücksichtigt, wenn das API-Gateway das JWT validiert, um zu bestimmen, ob es noch gültig ist. Verwenden Sie dazu den Claim "nicht vor" (nbf, falls vorhanden) und den Ablaufclaim (exp) im JWT. Der Mindestwert (und Standardwert) ist 0, der Höchstwert ist 120.

      Beispiel: Die folgende authentication-Policy konfiguriert das API-Gateway mit einem öffentlichen Verifizierungsschlüssel, der bereits von einem Identitätsprovider ausgegeben wurde, um das JWT im Autorisierungsanforderungsheader zu validieren:

      {
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}

  2. Fügen Sie eine authorization-Anforderungs-Policy für jede Route in der API-Deployment-Spezifikation hinzu:

    1. Fügen Sie, falls noch nicht vorhanden, einen requestPolicies-Abschnitt nach dem backend-Abschnitt der ersten Route ein. Beispiel:

      {
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}

    2. Fügen Sie die folgende authorization-Policy zum requestPolicies-Abschnitt hinzu: 

      {
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
    }
  ]
}

      Dabei gilt:

      • "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> gibt an, wie Zugriff auf die Route erteilt werden soll:

        • "AUTHENTICATION_ONLY": Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden. In diesem Fall zeigt die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation keine Wirkung.
        • "ANY_OF": Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden, sofern der scope-Claim des JWT einen der Zugriffsgeltungsbereiche enthält, die Sie in der Eigenschaft allowedScope angeben. In diesem Fall zeigt die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation keine Wirkung.
        • "ANONYMOUS": Zugriff wird allen Endbenutzern erteilt, selbst wenn diese nicht erfolgreich authentifiziert wurden. In diesem Fall müssen Sie die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation explizit auf true setzen.
      • "allowedScope": [ "<scope>" ] ist eine kommagetrennte Liste mit mindestens einer Zeichenfolge, die einem im scope-Claim des JWT enthaltenen Zugriffsgeltungsbereich entspricht. In diesem Fall müssen Sie die type-Eigenschaft auf "ANY_OF" setzen (die "allowedScope"-Eigenschaft wird ignoriert, wenn die type-Eigenschaft auf "AUTHENTICATION_ONLY" oder "ANONYMOUS" gesetzt wurde). Wenn Sie mehr als einen Geltungsbereich angeben, wird der Zugriff auf die Route erteilt, sobald einer der angegebenen Geltungsbereiche im scope-Claim des JWT enthalten ist.

      Beispiel: Die folgende Anforderungs-Policy definiert eine /hello-Route, die nur authentifizierten Endbenutzern mit dem Geltungsbereich read:hello Zugriff gewährt:

      {
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}
    3. Fügen Sie eine authorization-Anforderungs-Policy für alle restlichen Routen in der API-Deployment-Spezifikation hinzu.
    Hinweis

    Wenn Sie keine authorization-Policy für eine bestimmte Route angeben, wird der Zugriff basierend auf der Annahme erteilt, dass eine solche Policy vorhanden ist, und die type-Eigenschaft wird auf "AUTHENTICATION_ONLY" gesetzt. Anders ausgedrückt: Ungeachtet der Einstellung der isAnonymousAccessAllowed-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation können:

    • nur authentifizierte Endbenutzer auf die Route zugreifen
    • alle authentifizierten Endbenutzer unabhängig von den Zugriffsgeltungsbereichen im scope-Claim des JWT auf die Route zugreifen
    • anonyme Endbenutzer nicht auf die Route zugreifen
  3. Speichern Sie die JSON-Datei, die die API-Deployment-Spezifikation enthält.

  4. Verwenden Sie die API-Deployment-Spezifikation, wenn Sie ein API-Deployment wie folgt erstellen oder aktualisieren:

    • Durch Angabe der JSON-Datei in der Konsole bei Auswahl der Option Vorhandene API hochladen
    • Durch Angabe der JSON-Datei in einer Anforderung an die REST-API von API-Gateway

    Weitere Informationen finden Sie unter API durch das Erstellen eines API-Deployments in einem API-Gateway implementieren und API-Gateways aktualisieren.

  5. (Optional) Bestätigen Sie, dass die API erfolgreich bereitgestellt wurde, indem Sie sie aufrufen (siehe In einem API-Gateway bereitgestellte API aufrufen).

Beispiel: JWT_AUTHENTICATION-Anforderungs-Policy in eine TOKEN_AUTHENTICATION-Anforderungs-Policy migrieren

In diesem Abschnitt wird ein Beispiel einer vorhandenen JWT_AUTHENTICATION-Anforderungs-Policy gezeigt, die zu einer TOKEN_AUTHENTICATION-Policy migriert wurde.

Eine Möglichkeit, die Migration anzugehen, besteht darin, eine leere TOKEN_AUTHENTICATION-Anforderungs-Policy zu erstellen und diese dann mit Werten aus der JWT_AUTHENTICATION-Anforderungs-Policy aufzufüllen

Vor Migration:

Die ursprüngliche JWT_AUTHENTICATION-Anforderungs-Policy vor der Migration:

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}

Nach der Migration:

Die neue Anforderungs-Policy TOKEN_AUTHENTICATION wird mit Werten aus der ursprünglichen Anforderungs-Policy JWT_AUTHENTICATION aufgefüllt:

{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "maxClockSkewInSeconds": 10,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "additionalValidationPolicy": {
          "audiences": [
            "api.dev.io"
          ],
          "verifyClaims": [
            {
              "key": "is_admin",
              "values": [
                "service:app",
                "read:hello"
              ],
              "isRequired": true
            }
          ],
          "issuers": [
            "https://identity.oraclecloud.com/"
          ]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": [
        "GET"
      ],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [
            "read:hello"
          ]
        }
      }
    }
  ]
}