Protection des applications de front end

Si vous utilisez une application basée sur un navigateur, vous pouvez utiliser le flux Open ID Connect(OIDC ) / OAuth 2.0 authorization_grant pour authentifier vos utilisateurs. Lorsqu'un utilisateur non authentifié est détecté, il est automatiquement redirigé vers la page d'authentification. Lorsque l'authentification aboutit, le navigateur est redirigé sur un noeud final /oidc/callback implicite où l'adaptateur intercepte la demande. A ce stade, l'adaptateur obtient des jetons du fournisseur d'identité, puis redirige l'utilisateur sur l'URL que celui-ci demandait au départ.

Pour afficher les informations de session utilisateur, notamment les jetons de session, vous pouvez regarder dans l'en-tête Authorization.

Authorization: Bearer <accessToken> <IDToken>

Vous pouvez également déconnecter des utilisateurs authentifiés. Lorsqu'un utilisateur authentifié accède à un noeud final protégé avec oidc/logout ajouté comme illustré dans l'exemple suivant, il est déconnecté.

https://myhost/path/oidc/logout

Si nécessaire, un jeton d'actualisation peut être utilisé pour obtenir automatiquement de nouveaux jetons d'accès et d'identité sans que l'utilisateur ait besoin de s'authentifier à nouveau. Si le fournisseur d'identité configuré renvoie un jeton d'actualisation, ce jeton est conservé dans la session et utilisé pour récupérer de nouveaux jetons lorsque le jeton d'identité arrive à expiration.

Protection des applications de back end

L'adaptateur peut être utilisé en collaboration avec OAuth 2.0 Flux du porteur JWT pour protéger les API des services en validant les jetons JWT Bearer. Le flux d'autorisation Bearer s'attend à ce qu'une demande contienne un en-tête Authorization avec un jeton d'accès valide et un jeton d'identité facultatif. La structure de l'en-tête attendue se présente comme suit : Authorization=Bearer {access_token} [{id_token}]. Un statut de réponse HTTP 401 est renvoyé aux clients non authentifiés avec la liste des portées qui leur sont nécessaires pour obtenir l'autorisation. Si les jetons ne sont pas valides ou ont expiré, la stratégie de l'API renvoie une réponse HTTP 401 avec un composant d'erreur facultatif indiquant Www-Authenticate=Bearer scope="{scope}" error="{error}".

Pour plus d'informations sur les jetons et leur mode d'utilisation, voir Connaissance des jetons.

Définition d'une configuration

En fonction de la protection que vous envisagez sur les applications de front end ou de back end, créez une configuration de règle avec l'une des options suivantes.

• Pour les applications de front end : des applications reposant sur un navigateur qui nécessitent l'authentification des utilisateurs peuvent être configurées pour utiliser le flux d'authentification OIDC / OAuth 2.0. Pour créer une définition CRD OidcConfig contenant le client utilisé pour faciliter le flux d'authentification avec le fournisseur d'identité, servez-vous de l'exemple suivant pour vous guider.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: OidcConfig
  metadata:
     name:      oidc-provider-config
     namespace: sample-namespace
  spec:
     discoveryUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/.well-known/openid-configuration
     clientId:     <clientID>
     clientSecret: <randomlyGeneratedClientSecret>
     clientSecretRef:
           name: <nameOfKubeSecret>
           key: <keyInKubeSecret>
  

  Explication des composants du fichier de configuration YAML

  Zone	Type	Obligatoire	Description
  discoveryUrl	chaîne	Oui	Noeud final courant qui fournit un document JSON contenant les informations de configuration pour OIDC/OAuth 2.0.
  clientId	chaîne	Oui	Identificateur du client utilisé pour l'authentification.
  clientSecret	chaîne	*Non	Valeur confidentielle (secret) en texte brut utilisée pour authentifier le client. Si elle n'est pas fournie, il doit exister une référence clientSecretRef.
  clientSecretRef	objet	Non	Valeur confidentielle (secret) de référence utilisée pour authentifier le client. Cette référence peut être utilisée à la place de clientSecret.
  clientSecretRef.name	chaîne	Oui	Nom de la valeur confidentielle (secret) Kubernetes contenant la valeur de clientSecret.
  clientSecretRef.key	chaîne	Oui	Zone au sein de la valeur confidentielle (secret) Kubernetes renfermant la valeur de clientSecret.

• Pour les applications dorsales : La spécification OAuth 2.0 Bearer token définit un modèle de protection des API à l'aide de JSON Web Tokens(JWT). En utilisant la configuration suivante à titre d'exemple, créez une définition CRD JwtConfig contenant la ressource de la clé publique, qui est utilisée pour valider les signatures de jeton.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: JwtConfig
  metadata:
     name:      jwt-config
     namespace: sample-app
  spec:
     jwksUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/publickeys
  

Enregistrements des noeuds finaux d'application

Enregistrez les noeuds finaux d'application au sein d'une définition CRD Policy pour valider les demandes entrantes et appliquer des règles d'authentification. Chaque règle (Policy) s'applique exclusivement à l'espace de nom Kubernetes dans lequel réside l'objet et peut spécifier les services, les chemins et les méthodes que vous souhaitez protéger.

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
  name:      samplepolicy
  namespace: sample-app
spec:
  targets:
    -
      serviceName: <svcSampleApp>
      paths:
        - exact: /web/home
          method: ALL
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              rules:
                - claim: scope
                  match: ALL
                  source: access_token
                  values:
                    - appid_default
                    - openid
                - claim: amr
                  match: ANY
                  source: id_token
                  values:
                    - cloud_directory
                    - google

        - exact: /web/user
          method: GET
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              redirectUri: https://github.com/ibm-cloud-security/app-identity-and-access-Adapter
        - prefix: /
          method: ALL
          policies:
            -
              policyType: jwt
              config: <jwtConfig>

Adaptateur

Pour voir les journaux de l'adaptateur, vous pouvez utiliser kubectl ou accéder au pod à partir du pod appidentityandaccessAdapter dans la console Kubernetes.

alias Adapter_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=appidentityandaccessAdapter -o jsonpath='{.items[0].metadata.name}')"
Adapter_logs | jq

Mixer

Si l'adaptateur ne semble pas recevoir de demandes, vérifiez les journaux Mixer pour vous assurer qu'il a été correctement connecté à l'adaptateur.

alias mixer_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=telemetry -o jsonpath='{.items[0].metadata.name}') -c mixer"
mixer_logs | jq