Exemple - utilisation de plusieurs stratégies OAuth dans un assemblage de fournisseurs OAuth

Modifier en ligne

Cet exemple illustre l'utilisation de plusieurs stratégies OAuth dans le flux d'assemblage pour un fournisseur OAuth natif.

Cet exemple s'appuie sur l'assembly par défaut généré lors de la création d'un fournisseur natif d' OAuth, et a été personnalisé par l'ajout de gatewayscript politiques qui utilisent les variables de contexte d' OAuth pour manipuler le flux d' OAuth.

Le processus d'assemblage se déroule comme suit :Capture d'écran du flux d'assemblage des fournisseurs d' OAuth

Les sections suivantes décrivent le code source OpenAPI qui sous-tend chacune des stratégies de l'assemblage. Pour le code d'assemblage complet, téléchargez le fichier multiple_oauth_policies.txt.

Exemple de stratégie pour ajouter une portée personnalisée

La stratégie add_scope est une stratégie gatewayscript qui ajoute une portée personnalisée à la demande.

Le code YAML source OpenAPI sous-jacent se présente comme suit :
- gatewayscript:
     version: 2.0.0
     title: add_scope
     source: |-
       // Add another custom scope to the request
       let scope = context.get("request.parameters.scope.values[0]);
       if (scope)
         context.set("oauth.processing.scope", scope + " custom");

Validation de la demande OAuth initiale

La première stratégie process_request est une stratégie oauth qui traite la demande initiale et vérifie qu'elle est valide. Le résultat du traitement est automatiquement enregistré dans les variables de contexte de l' oauth.processing, afin d'être utilisé, si nécessaire, par la politique d' OAuth suivante dans le flux d'assemblage.

Le code YAML source OpenAPI sous-jacent se présente comme suit :
- oauth:
    title: process_request
    version: 2.0.0
    description: >-
      This oauth policy performs all OAuth/OpenID Connect protocol steps
      that are needed for OAuth Validation by default. The inputs and
      outputs of each of the steps are driven by documented context
      variables. Add or remove the Supported OAuth Components as required.
    oauth-provider-settings-ref:
      default: custom-form
    supported-oauth-components:
      - OAuthValidateRequest

Exemple de stratégie pour modifier la portée

La stratégie modify_scope est une stratégie gatewayscript qui modifie la portée en fonction de l'application appelante.

Le code YAML source OpenAPI sous-jacent se présente comme suit :
- gatewayscript:
    version: 2.0.0
    title: modify_scope
    source: |-
      let admin_id = '1f1a2aa4-db9f-4423-b2f1-e2572b12123a';

      // Check application and modify the scope
      let app = context.get("oauth.processing.client_id");
      let scope = context.get("oauth.processing.scope");
      if (app === admin_id) {
        context.set("oauth.processing.scope", scope + " admin");
      } else {
        context.set("oauth.processing.scope", scope + " customer");
      }

Branchement conditionnel en fonction du chemin d'accès OAuth

La stratégie path_branch est une stratégie switch qui se branche en fonction des différents chemins d'accès OAuth pour traiter le propriétaire de la ressource.

Le code YAML source OpenAPI sous-jacent se présente comme suit :
- switch:
    version: 2.0.0
    title: path_branch
    case:
      - condition: ($operationPath() = '/oauth2/token')
        execute:
            .
            .
            .
          definition of the user_security and other_grants policies
           .
           .
           .
      - condition: ($operationPath() = '/oauth2/authorize')
        execute:
           .
           .
           .
          definition of the user_password and implicit_authcode policies
           .
           .
           .
      - otherwise:
           .
           .
           .
          definition of the other_endpoints policy
           .
           .
           .

Traitement du nom d'utilisateur et du mot de passe, et activation du composant de type d'octroi

Les deux stratégies suivantes fonctionnent sur le noeud final de jeton.

  • La stratégie user_password pour le type d'octroi de mot de passe traite le nom d'utilisateur et le mot de passe provenant du corps x-www-form-urlencoded.
  • La stratégie other_grants est une stratégie oauth qui permet aux composants OAuthGenerateAccessToken, OAuthVerifyAZCode, OAuthVerifyRefreshToken et OAuthCollectMetadata d'effectuer les opérations pour les données d'identification client, le code d'autorisation, le jeton d'actualisation et les types d'octroi de mot de passe.
Le code YAML source OpenAPI sous-jacent se présente comme suit :
- user-security:
    title: user_password
    version: 2.0.0
    description: ''
    factor-id: default
    extract-identity-method: context-var
    user-context-var: request.parameters.username.values
    pass-context-var: request.parameters.password.values
    ei-stop-on-error: false
    user-auth-method: auth-url
    au-stop-on-error: false
    auth-url: 'http://httpbin.org/basic-auth/user/pass'
    user-az-method: authenticated
    az-stop-on-error: true
    auth-response-headers-pattern: (?)x-api*
    auth-response-header-credential: X-API-Authenticated-Credential
- oauth:
    title: other_grants
    version: 2.0.0
    description: >-
      This oauth policy performs all OAuth/OpenID Connect
      protocol steps that are needed for token path by default.
      The inputs and outputs of each of the steps are driven by
      documented context variables. Add or remove the Supported
      OAuth Components as required.
    oauth-provider-settings-ref:
      default: custom-form
    supported-oauth-components:
      - OAuthGenerateAccessToken
      - OAuthVerifyAZCode
      - OAuthVerifyRefreshToken
      - OAuthCollectMetadata

Vérifications d'autorisation et activation de composants de type d'octroi

Les deux stratégies suivantes fonctionnent sur le noeud final d'autorisation.

  • La configuration de user_security la stratégie est dérivée des paramètres de sécurité utilisateur du fournisseur « OAuth ».
  • La stratégie implicit_authcode est une stratégie oauth qui permet aux composants OAuthGenerateAZCode, OAuthGenerateAccessToken et OAuthCollectMetadata d'effectuer les opérations pour les types d'octroi de code d'autorisation et implicite.
Le code YAML source OpenAPI sous-jacent se présente comme suit :

- user-security:
    title: user_security
    version: 2.0.0
    description: >-
      This user security policy performs EI(basic) and AU(auth
      url) check for oauth assembly. Change the security check
      method as required
    factor-id: default
    extract-identity-method: basic
    ei-stop-on-error: true
    user-auth-method: auth-url
    au-stop-on-error: true
    user-az-method: authenticated
    az-stop-on-error: true
    auth-response-headers-pattern: (?)x-api*
    auth-response-header-credential: X-API-Authenticated-Credential
    auth-url: 'http://httpbin.org/basic-auth/user/pass'
- oauth:
    title: implicit_authcode
    version: 2.0.0
    description: >-
      This oauth policy performs all OAuth/OpenID Connect
      protocol steps that are needed for az code path by
      default. The inputs and outputs of each of the steps are
      driven by documented context variables. Add or remove the
      Supported OAuth Components as required.
    oauth-provider-settings-ref:
      default: custom-form
    supported-oauth-components:
      - OAuthGenerateAZCode
      - OAuthGenerateAccessToken
      - OAuthCollectMetadata

Traitement de tous les autres noeuds finaux

La condition otherwise intercepte tous les autres noeuds finaux tels que les noeuds finaux d'introspection et de révocation. La stratégie other_endpoints dans la condition otherwise est une stratégie oauth qui permet aux composants OAuthIntrospectToken et OAuthRevokeTokencomponents d'effectuer les opérations pour l'introspection et la révocation.

Le code YAML source OpenAPI sous-jacent se présente comme suit :
- oauth:
    title: other_endpoints
    version: 2.0.0
    description: >-
      This oauth policy performs all OAuth/OpenID Connect
      protocol steps that are needed for all other paths by
      default. The inputs and outputs of each of the steps are
      driven by documented context variables. Add or remove the
      Supported OAuth Components as required.
    oauth-provider-settings-ref:
      default: custom-form
    supported-oauth-components:
      - OAuthIntrospectToken
      - OAuthRevokeToken