Auto-prise en charge de l'utilisateur basée sur une politique

Introduction

Bien que le site IBM Verify fournisse sa propre expérience d'autonomie de l'utilisateur (USC), il n'est pas rare ni déraisonnable que les adoptants fournissent leur propre expérience personnalisée de l'utilisateur USC et des inscriptions et enregistrements multifactoriels (MFA). L'enrôlement MFA est un moment critique pour permettre à vos utilisateurs de bénéficier de capacités d'authentification et d'assurance d'identité fortes et hautement fiables. Ainsi, les "cérémonies" d'inscription doivent être effectuées à l'aide de composants d'application hautement fiables qui respectent le principe du moindre privilège et conduisent les utilisateurs à un niveau élevé d'assurance d'identité fiable. Cet article fournit des conseils sur la manière d'y parvenir en utilisant les fonctionnalités de IBM Verify telles que les droits API restreints et l'authentification et l'autorisation basées sur la politique d'accès.

Cet article s'appuie sur les conseils et les orientations fournis dans les sites suivants :

Cet article ne fournit pas une application USC complète, mais plutôt des conseils, des recommandations et quelques exemples d'appels API qui pourraient aider à la conception et à la mise en œuvre d'une telle application

Approche générale

Le contexte de cet article est une application USC personnalisée qui peut permettre aux utilisateurs finaux de gérer eux-mêmes les facteurs MFA qu'ils ont enregistrés. Cependant, aucune capacité de l'USC n'existe sans une bonne composante d'accueil de l'utilisateur initial. Comme nous le verrons plus loin, le processus d'accueil initial devra s'assurer que les utilisateurs disposent d'un courrier électronique ou d'un facteur SMS enregistré. Ceci est nécessaire car une politique d'accès sera appliquée à notre application USC qui exigera de nos utilisateurs qu'ils satisfassent à une authentification MFA avant de gérer tout autre aspect de leur état MFA inscrit ou même d'inscrire des facteurs MFA supplémentaires. Les facteurs minimaux acceptables à cette fin seront email OTP ou sms OTP.

Étant donné qu'un processus d'intégration initiale des utilisateurs est en place, les principaux éléments d'une solution USC sécurisée permettant à l'utilisateur final de gérer lui-même ses inscriptions à l'AMF sont les suivants :

Une application OIDC personnalisée dans le locataire IBM Verify
Activation et configuration d'un ensemble minimal de droits API permettant aux utilisateurs de gérer leurs propres inscriptions à l'AMF
Définition d'une politique d'accès qui exige des utilisateurs qu'ils réussissent une authentification MFA avec un facteur disponible. Cette politique d'accès garantit que les jetons d'accès autorisés ne sont pas accordés à moins qu'une étape de l'AMF n'ait été franchie avec succès.
Appliquer la politique à l'application OIDC personnalisée
L'application personnalisée de l'USC est mise en œuvre de manière à ce que les éléments suivants soient pris en charge
- Octroi initial d'un jeton d'accès lorsque sa réponse indique qu'une AMF est requise. Cela dépend de la politique d'accès.
- Compléter un flux d'AMF en utilisant l'un des facteurs disponibles pour les utilisateurs. Le résultat de ce flux sera un JWT qui pourra être échangé contre un jeton d'accès autorisé et pleinement habilité
- Échanger le JWT renvoyé lors de l'exécution de l'AMF contre un jeton d'accès pleinement autorisé
- Exécuter les fonctions de gestion de l'inscription par l'AMF à l'aide d'un jeton d'accès à part entière.

Utilisateur à bord

L'embarquement des utilisateurs n'est pas un sujet traité en détail dans cet article, mais quelques points méritent d'être mentionnés et pris en considération.

IBM Verify propose quelques solutions et composants qui permettent de créer et de mettre à jour des enregistrements de comptes d'utilisateurs dans l'annuaire du nuage du locataire.
- Les API SCIM permettent aux applications personnalisées de gérer les enregistrements des comptes d'utilisateurs
- LDAP Directory Sync - permet de synchroniser les enregistrements entre l'annuaire en nuage et un magasin d'identité externe.
- Le provisionnement juste à temps peut être effectué pendant les flux de fédération SSO ou les flux de pont d'authentification On Prem.
L'application de l'USC décrite dans l'article exigera que les utilisateurs effectuent une certaine forme d'authentification MFA avant d'obtenir un jeton d'accès pleinement autorisé qui peut ensuite gérer d'autres facteurs MFA enregistrés. email OTP ou sms OTP seront les facteurs MFA minimaux acceptables.
- L'application d'embarquement devra enregistrer un OTP ou un autre facteur au nom de l'utilisateur après avoir vérifié et validé le nouvel utilisateur
- L'application d'embarquement utilisera probablement un flux d'informations d'identification du client pour obtenir un jeton d'accès avec les droits API suivants
  - Authentifier un utilisateur
  - Gérer les enregistrements d'authentificateur pour tous les utilisateurs
  - Gérer les inscriptions au deuxième facteur pour tous les utilisateurs
  - Gérer les utilisateurs et les groupes standard

Un exemple de représentation SCIM API d'un utilisateur de notre application USC est présenté ci-dessous.

{
    "emails": [
        {
            "type": "work",
            "value": "[email protected]"
        }
    ],
    "name": {
        "formatted": "Jessica Breton",
        "familyName": "Breton",
        "givenName": "Jessica"
    },
    "active": true,
    "id": "6070004YSH",
    "externalId": "[email protected]",
    "password": "{{enduser_password}}",
    "userName": "jessica",
    "phoneNumbers": [
        {
            "type": "work",
            "value": "99999999"
        }
    ],
    "urn:ietf:params:scim:schemas:extension:ibm:2.0:Notification": {
        "notifyType": "EMAIL",
        "notifyPassword": false,
        "notifyManager": false
    },
    "urn:ietf:params:scim:schemas:extension:ibm:2.0:User": {
        "realm": "cloudIdentityRealm",
        "userCategory": "regular"
    },  
    "schemas": [
        "urn:ietf:params:scim:schemas:extension:ibm:2.0:Notification",
        "urn:ietf:params:scim:schemas:extension:ibm:2.0:User",
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ]
}

L'exemple de requête et de réponse CURL pour inscrire les nouveaux utilisateurs au facteur SMS OTP est illustré ci-dessous :

curl --location --request POST 'https://<tenant>/v2.0/factors/smsotp' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer yYWaV07kdJMnsHNgDdH0SfeTlbzROasQwZlwBYDm' \
--data-raw '{
  "enabled": true,
  "userId": "6070004YSH",
  "phoneNumber": "99999999"
}'

Réponse :

{
    "id": "59aeb30c-02b3-4602-bf70-c8005b9f8cde",
    "userId": "6070004YSH",
    "type": "smsotp",
    "created": "2021-06-11T08:13:34.732Z",
    "updated": "2021-06-11T08:13:34.732Z",
    "enabled": true,
    "validated": false,
    "attributes": {
        "phoneNumber": "99999999"
    }
}

Configuration de l'application USC personnalisée

Afin d'invoquer les fonctions d'inscription à l'AMF et de gestion des utilisateurs finaux d'un locataire IBM Verify, un jeton d'accès avec des autorisations d'accès à l'API suffisantes est nécessaire. Une configuration de l'application OIDC est nécessaire dans le locataire IBM Verify. Certains des éléments clés de la configuration de cette application USC personnalisée sont présentés dans les sections suivantes.

Types de subventions et paramètres JWT

L'application personnalisée de l'USC utilisera le flux Resource Owner Password Credential (ROPC) pour obtenir un jeton autorisé pour les appels API ultérieurs aux points finaux de gestion de l'inscription à l'AMF. Cela servira également de premier facteur d'authentification. La subvention jwt-bearer doit également être activée. Cet octroi est utilisé pour obtenir un jeton d'accès entièrement autorisé après une authentification AMF. L'AMF step up est nécessaire dans le cadre de la politique d'accès qui protégera cette application.

Protéger l'application OIDC avec une politique d'accès MFA

Le diagramme ci-dessous illustre les paramètres de configuration de la politique d'accès qui seront appliqués aux demandes d'octroi de jetons d'accès au moment de l'exécution. Une politique d'accès personnalisée nommée Custom USC Policy a été créée dans l'éditeur de politique. Ce point est décrit dans une section ultérieure. La politique d'accès sera évaluée et appliquée lors des demandes d'octroi de ROPC et de JWT Bearer.

Restreindre l'accès à l'API pour obtenir le moins de privilèges possible

L'objectif de cette application USC personnalisée est de fournir une expérience utilisateur spécifique aux utilisateurs finaux en leur permettant de gérer leurs facteurs MFA enregistrés. Par défaut, toutes les applications OIDC personnalisées bénéficient de l'ensemble complet de User Permissions présenté dans le diagramme Edit API client ci-dessous. Dans de nombreux cas, cela permet de privilégier les applications personnalisées de l'OIDC. La meilleure pratique consiste à limiter autant que possible les autorisations. Ceci peut être réalisé en sélectionnant le sous-ensemble minimum d'autorisations API requises par l'application. Dans le cas de cette application de l'USC, ce sous-ensemble est représenté par les autorisations indiquées et sélectionnées dans les diagrammes ci-dessous.

Politique d'accès personnalisée

La politique d'accès à cette application de l'USC est relativement simple. Il requiert l'accomplissement d'un premier facteur. Cela se fera par le biais du flux ROPC au moment de l'exécution. Il comporte ensuite une règle de politique générale, la règle par défaut, qui exige la réussite d'une AMF per session. Dans ce cas, l'octroi d'un jeton se fera par session.

La règle du premier contact est illustrée ci-dessous.

La règle MFA per session est incarnée par la règle par défaut, comme le montrent les diagrammes ci-dessous.

710 — Mise à jour de la règle par défaut

Jeton d'accès USC avec authentification par politique

Une fois la configuration de l'application OIDC définie dans le locataire IBM Verify, la mise en œuvre de l'application USC peut commencer. Cette section illustre le type de flux et d'appels à l'API nécessaires pour obtenir un jeton d'accès à part entière après la réussite de l'AMF.

Les étapes de base sont les suivantes :

Lancer un flux de subventions ROPC
Utiliser le jeton d'accès restreint qui en résulte pour compléter un flux ascendant d'AMF
Échanger le JWT de l'étape précédente contre un jeton d'accès à part entière
Effectuer un enregistrement TOTP avec le jeton d'accès pleinement habilité

Subvention initiale

L'application USC devra présenter à l'utilisateur un écran de connexion avec nom d'utilisateur et mot de passe. Après avoir recueilli les informations d'identification de l'utilisateur, l'application USC peut tenter le flux ROPC initial afin de vérifier les informations d'identification de l'utilisateur et d'obtenir un jeton d'accès.

L'exemple curl ci-dessous montre le flux initial du ROPC. Les points suivants méritent d'être soulignés :

L'en-tête d'autorisation est HTTP Basic authorization où la valeur est le clientId et le secret de l'application OIDC personnalisée.

curl --location --request POST 'https://<tenant>/v1.0/endpoint/default/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Accept: application/json' \
--header 'Authorization: Basic N2ExZjA3NzQtOTgyNy00YjhiLWI4NTItNjRhNTJkNTFjMjhlOm9hcTFqa0JLU0c=' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=jessica' \
--data-urlencode 'password=<password value>' \
--data-urlencode 'scope=openid'

La réponse à cet appel API est présentée ci-dessous. Il s'agit d'une réponse de jeton d'accès, mais certains indicateurs montrent qu'il ne s'agit pas d'un jeton entièrement autorisé et qu'une étape MFA est nécessaire. Cela est dû à l'évaluation et à l'application de la politique d'accès. Le site scope = mfa_challenge informe l'application que le site access_token n'est pas entièrement autorisé et que l'utilisateur doit compléter un flux d'AMF à l'aide de l'un des sites allowedFactors. À ce stade, le jeton d'accès peut être utilisé pour lire les facteurs enregistrés de l'utilisateur. Cela peut permettre à l'application d'afficher une liste de sélection à l'intention de l'utilisateur, comprenant les facteurs d'AMF qu'il a enregistrés et qu'il pourrait souhaiter utiliser pour un défi d'authentification AMF.

{
    "access_token": "1d7xN3ADokjxYl5tlGkQrOWriAJZ7SDRjVn8DjkN",
    "allowedFactors": [
        "emailotp",
        "totp",
        "smsotp",
        "fido2",
        "signatures"
    ],
    "scope": "mfa_challenge",
    "grant_id": "50554ed4-2d69-44b7-a2d6-dc175fcbb6ec",
    "token_type": "Bearer",
    "expires_in": 1800
}

Bien qu'il ne soit pas essentiel au fonctionnement global de l'application USC, il est intéressant d'analyser ce jeton d'accès initial pour illustrer l'état de ses droits restreints. Comme le montre la réponse d'introspection ci-dessous, le jeton d'accès n'a que trois droits d'API IBM Verify:

authn - permet au porteur du jeton d'exécuter des fonctions d'AMF et de lire les données de l'annuaire en nuage de l'utilisateur par l'intermédiaire de /v2.0/Me
readEnrollMFAMethod- permet au porteur du jeton de lire les méthodes d'AMF enregistrées par l'utilisateur
readAuthenticators- permet au porteur du jeton de lire les utilisateurs inscrits sur IBM Verify authentificateurs mobiles

curl --location --request POST 'https://<tenant>/v1.0/endpoint/default/introspect' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Accept: application/json' \
--header 'Authorization: Basic N2ExZjA3NzQtOTgyNy00YjhiLWI4NTItNjRhNTJkNTFjMjhlOm9hcTFqa0JLU0c=' \
--data-urlencode 'token=1d7xN3ADokjxYl5tlGkQrOWriAJZ7SDRjVn8DjkN'

Réponse :

{
    "entitlements": [
        "authn",
        "readEnrollMFAMethod",
        "readAuthenticators"
    ],
    "at_hash": "c9LW3JYOnvjs-EfePXxAFw",
    "ext": {
        "tenantId": "<tenant>"
    },
    "sub": "6070004YSH",
    "policy_id": "529160",
    "amr": [
        "password"
    ],
    "uniqueSecurityName": "6070004YSH",
    "iss": "https://<tenant>/oidc/endpoint/default",
    "active": true,
    "token_type": "Bearer",
    "client_id": "7a1f0774-9827-4b8b-b852-64a52d51c28e",
    "aud": "7a1f0774-9827-4b8b-b852-64a52d51c28e",
    "grant_type": "resource_owner",
    "restrictEntitlements": true,
    "scope": "mfa_challenge",
    "grant_id": "50554ed4-2d69-44b7-a2d6-dc175fcbb6ec",
    "category": "application",
    "exp": 1623407672,
    "app_id": "4605379946084934998",
    "iat": 1623405872
}

Afficher un défi de sélection de l'AMF à l'utilisateur

À ce stade, l'application de l'USC doit conduire l'utilisateur à relever le défi de l'AMF. Une approche typique consisterait à utiliser le jeton d'accès actuel pour

Obtenir une liste des facteurs inscrits disponibles pour les utilisateurs. S'il y en a et qu'ils répondent aux exigences de la liste allowedFactors de la réponse précédente, l'USC peut les inclure dans une invite de sélection à l'intention de l'utilisateur.
Lire les données du compte de l'utilisateur à partir de /v2.0/Me pour obtenir son adresse électronique. Si l'adresse électronique est définie, la liste de sélection de l'AMF peut également inclure transient email OTP comme option dans l'invite de sélection de l'AMF.

Voici un exemple de demande et de réponse pour obtenir les facteurs inscrits des utilisateurs.

curl --location --request GET 'https://<tenant>.com/v2.0/factors' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer 1d7xN3ADokjxYl5tlGkQrOWriAJZ7SDRjVn8DjkN'

Réponse :

{
    "factors": [
        {
            "id": "59aeb30c-02b3-4602-bf70-c8005b9f8cde",
            "userId": "6070004YSH",
            "type": "smsotp",
            "created": "2021-06-11T08:13:34.732Z",
            "updated": "2021-06-11T08:13:58.405Z",
            "attempted": "2021-06-11T08:18:37.246Z",
            "enabled": true,
            "validated": true,
            "attributes": {
                "phoneNumber": "+610419673026"
            }
        }
    ],
    "count": 200,
    "limit": 200,
    "page": 1,
    "total": 1
}

Voici un exemple de demande et de réponse pour obtenir l'adresse électronique d'un utilisateur à partir des données de son compte dans l'annuaire en nuage :

curl --location --request GET 'https://<tenant>/v2.0/Me' \
--header 'Accept: application/scim+json' \
--header 'Authorization: Bearer 1d7xN3ADokjxYl5tlGkQrOWriAJZ7SDRjVn8DjkN'

Réponse :

{
    "emails": [
        {
            "type": "work",
            "value": "[email protected]"
        }
    ],
    "meta": {
        "created": "2021-05-10T12:06:57Z",
        "location": "https://<tenant>/v2.0/Users/6070004YSH",
        "lastModified": "2021-05-12T09:45:02Z",
        "resourceType": "User"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:ibm:2.0:User"
    ],
    "name": {
        "formatted": "Jessica Breton",
        "familyName": "Breton",
        "givenName": "Jessica"
    },
    "urn:ietf:params:scim:schemas:extension:ibm:2.0:User": {
        "lastLogin": "2021-05-12T09:45:02Z",
        "lastLoginRealm": "cloudIdentityRealm",
        "userCategory": "regular",
        "twoFactorAuthentication": false,
        "realm": "cloudIdentityRealm",
        "pwdChangedTime": "2021-05-10T12:06:57Z",
        "lastLoginType": "user_password"
    },
    "externalId": "[email protected]",
    "active": true,
    "id": "6070004YSH",
    "userName": "jessica",
    "phoneNumbers": [
        {
            "type": "work",
            "value": "9999999"
        }
    ]
}

Effectuer un SMS OTP enregistré pour MFA

Pour les besoins de la démonstration, nous ferons comme si l'application sélectionnait automatiquement le facteur sms OTP inscrit par l'utilisateur afin de satisfaire aux exigences de l'AMF pour la politique d'accès de l'USC. La sélection est automatique car l'utilisateur n'a qu'un seul facteur inscrit lors de l'embarquement et cette application de l'USC préfère les facteurs inscrits. Un exemple de demande et de réponse est présenté ci-dessous pour lancer l'envoi d'un SMS OTP. Notez que la valeur 59aeb30c-02b3-4602-bf70-c8005b9f8cde dans l' URL de l'exemple est la valeur id du facteur SMS OTP de l'utilisateur inscrit.

curl --location --request POST 'https://<tenant>/v2.0/factors/smsotp/59aeb30c-02b3-4602-bf70-c8005b9f8cde/verifications' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer 1d7xN3ADokjxYl5tlGkQrOWriAJZ7SDRjVn8DjkN'
--data-raw '{
  "correlation": "4445"
}'

Réponse

{
    "id": "673ce1f9-0b0a-473d-b5e5-3bd4ddbe1cb0",
    "userId": "6070004YSH",
    "type": "smsotp",
    "created": "2021-06-11T10:25:30.539Z",
    "updated": "2021-06-11T10:25:30.539Z",
    "expiry": "2021-06-11T10:30:30.539Z",
    "state": "PENDING",
    "correlation": "4445",
    "phoneNumber": "999999",
    "attempts": 0,
    "retries": 4
}

La transaction par SMS OTP a été lancée. Peu après, l'utilisateur final recevra un SMS similaire à celui illustré ci-dessous. Le SMS contient l'OTP. L'application USC doit maintenant afficher une invite de saisie de l'OTP pour permettre à l'utilisateur final de saisir l'OTP contenu dans le SMS.

L'OTP peut être validé par IBM Verify comme le montre l'exemple curl ci-dessous. Quelques aspects méritent d'être soulignés :

L'adresse id de la réponse précédente est ajoutée à l' URL vérification de l'OTP par SMS.
returnJwt=true Le paramètre URL est défini. Cela indique que l'application de l'USC souhaite recevoir un JWT signé qui peut ensuite être présenté et échangé contre un jeton d'accès pleinement autorisé.

curl --location --request POST 'https://<tenant>/v2.0/factors/smsotp/59aeb30c-02b3-4602-bf70-c8005b9f8cde/verifications/673ce1f9-0b0a-473d-b5e5-3bd4ddbe1cb0?returnJwt=true' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer 1d7xN3ADokjxYl5tlGkQrOWriAJZ7SDRjVn8DjkN'
--data-raw '{
  "otp": "858676"
}'

Réponse

{
    "assertion": "eyJhbGciOiJSUzI1NiIsImtpZCI6InNlcnZlciJ9.eyJzdWIiOiI..."
}

La réponse ci-dessus contient un JWT signé. Le JWT décodé est présenté ci-dessous. Ce JWT atteste qu'un SMS OTP MFA a été exécuté avec succès par la réclamation sub indiquée dans le JWT. Le site amr affirme que l'utilisateur a réussi à s'authentifier par mot de passe et par SMS OTP dans le cadre de l'octroi du jeton indiqué par le site grant_id. Cela répond essentiellement à la règle MFA per session de la politique d'accès en vigueur.

{
  "sub": "6070004YSH",
  "jti": "7007c7f8-4fd5-45ff-a89f-1e92bb8b1105",
  "iat": 1623407800,
  "exp": 1623408100,
  "tenantId": "<tenant>",
  "iss": "https://<tenant>/v2.0/factors",
  "aud": [
    "7a1f0774-9827-4b8b-b852-64a52d51c28e",
    "https://<tenant>/v1.0/endpoint/default/token"
  ],
  "factor": "smsotp",
  "amr": [
    "smsotp",
    "password"
  ],
  "grant_id": "1cc2fa7e-7643-4b6f-bc08-0c8713d7de0b",
  "sub_type": "uid"
}

Échange d'un JWT MFA contre un jeton d'accès à part entière

Le JWT de la précédente réponse de vérification SMS OTP peut maintenant être échangé contre un jeton d'accès à part entière à l'aide du flux d'octroi jwt-bearer. Le serveur d'autorisation OIDC de IBM Verify ne traitera cependant pas cela comme un nouvel octroi de jeton. Cette question sera traitée dans le cadre du présent site grant_id.

curl --location --request POST 'https://<tenant>/v1.0/endpoint/default/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Accept: application/json' \
--header 'Authorization: Basic N2ExZjA3NzQtOTgyNy00YjhiLWI4NTItNjRhNTJkNTFjMjhlOm9hcTFqa0JLU0c=' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer' \
--data-urlencode 'assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6InNlcnZlciJ9.eyJzdWIiOiI...' \
--data-urlencode 'scope=openid'

La réponse à l'échange de jetons jwt-bearer est présentée ci-dessous. Cette réponse comprend une nouvelle valeur de jeton d'accès et ce jeton est maintenant pleinement autorisé. Les attributs de cette charge utile sont typiques de la réponse au jeton OIDC et l'application USC et son utilisateur ont maintenant satisfait aux exigences d'AMF de la politique d'accès qui les régit.

{
    "access_token": "cw1jugH8WlwjHPQZBIYwnH4hap3UtOFHHFFKcG99",
    "scope": "openid",
    "grant_id": "1cc2fa7e-7643-4b6f-bc08-0c8713d7de0b",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJnaXZlbl9uYW1...",
    "token_type": "Bearer",
    "expires_in": 7200
}

Les données d'introspection de ce jeton d'accès sont présentées ci-dessous :

{
    "entitlements": [
        "authn",
        "manageAuthenticators",
        "manageEnrollMFAMethod"
    ],
    "at_hash": "SXEdcqh1IjQJQvIt7_r6TA",
    "ext": {
        "tenantId": "<tenant>"
    },
    "sub": "6070004YSH",
    "realmName": "cloudIdentityRealm",
    "amr": [
        "smsotp",
        "password"
    ],
    "uniqueSecurityName": "6070004YSH",
    "iss": "https://<tenant>/oidc/endpoint/default",
    "active": true,
    "preferred_username": "jessica",
    "token_type": "Bearer",
    "client_id": "7a1f0774-9827-4b8b-b852-64a52d51c28e",
    "aud": "7a1f0774-9827-4b8b-b852-64a52d51c28e",
    "acr": "urn:ibm:security:policy:id:529160 urn:ibm:security:acr:2fa",
    "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
    "restrictEntitlements": true,
    "scope": "openid",
    "grant_id": "1cc2fa7e-7643-4b6f-bc08-0c8713d7de0b",
    "userType": "regular",
    "category": "application",
    "exp": 1623415081,
    "app_id": "4605379946084934998",
    "iat": 1623407881
}

Assurer les fonctions d'inscription à l'AMF de l'USC

L'application USC peut désormais permettre aux utilisateurs d'exécuter des fonctions d'inscription MFA. Un exemple de demande d'inscription au TOTP est présenté ci-dessous.

curl --location --request POST 'https://<tenant>/v2.0/factors/totp' \
--header 'Content-Type: application/json' \
--header 'Accept: image/png' \
--header 'Authorization: Bearer cw1jugH8WlwjHPQZBIYwnH4hap3UtOFHHFFKcG99' \
--data-raw '{
  "enabled": true,
  "accountName": "jessica"
}'

La réponse est un code QR qui peut être scanné par l'authentificateur mobile IBM Verify.

CONCLUSION

Cet article a décrit comment certaines des principales caractéristiques de IBM Verify peuvent être utilisées pour fournir une application USC personnalisée sécurisée et à autorisation minimale. L'article décrit comment configurer les applications OIDC avec des droits de sécurité API restreints. La politique d'accès a permis à l'application de faire passer l'utilisateur par un flux ascendant de MFA, de sorte qu'un niveau élevé d'assurance de l'identité de l'utilisateur final a été atteint avant de permettre à l'utilisateur de modifier l'état de ses inscriptions MFA.