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

Introduction

Bien qu'IBM Security Verify fournisse sa propre expérience d'auto-service utilisateur (USC), il n'est pas rare ou déraisonnable que les utilisateurs fournissent leur propre expérience USC personnalisée et des inscriptions et enregistrements multi-facteurs (MFA). L'inscription MFA est un moment critique pour permettre des capacités d'authentification fortes et hautement fiables et d'assurance d'identité à vos utilisateurs. En tant que tel, les "cérémonies" d'inscription doivent être effectuées en utilisant des composants d'application hautement fiables qui adhèrent au moindre privilège et conduisent les utilisateurs à un niveau élevé d'assurance d'identité de confiance. Cet article fournira des conseils sur la façon dont cela peut être réalisé en utilisant les fonctionnalités d'IBM Security Verify telles que les droits d'API restreints et l'authentification et l'autorisation activées par la politique d'accès.

Cet article développe les conseils et orientations fournis aux emplacements suivants :

Cet article ne fournit pas une application USC entièrement fonctionnelle mais fournit plutôt des conseils, des recommandations et quelques exemples d'appels d'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 leurs facteurs MFA inscrits. Cependant, aucune capacité USC n'existe sans un composant d'intégration d'utilisateur initial solide. Comme on le verra plus tard, le processus d'intégration initial devra s'assurer que les utilisateurs ont un facteur d'email ou SMS inscrit. Ceci est nécessaire car une politique d'accès sera appliquée à notre application USC qui exigera que nos utilisateurs satisfassent une authentification MFA avant de gérer tout autre aspect de leur état MFA inscrit ou en effet 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 d'utilisateur initial est en place, les principaux composants d'une solution USC sécurisée pour permettre la gestion autonome des inscriptions MFA par l'utilisateur final comprendront :

Une application OIDC personnalisée dans le locataire IBM Security Verify
Activer et configurer un ensemble minimal de droits d'API qui permettent aux utilisateurs de gérer leurs propres inscriptions MFA
Définition d'une politique d'accès qui exige que les utilisateurs terminent avec succès une authentification MFA avec un facteur disponible. Cette politique d'accès garantira que des jetons d'accès autorisés ne sont pas accordés à moins qu'une montée en puissance MFA n'ait été réussie.
Appliquer la politique à l'application OIDC personnalisée
Implémenter l'application USC personnalisée de telle sorte que les éléments suivants soient pris en charge
- Octroi de jeton d'accès initial où sa réponse indique qu'une MFA est requise. Ceci est dirigé par la politique d'accès.
- Compléter un flux MFA en utilisant l'un des facteurs disponibles des utilisateurs. Le résultat de ce flux sera un JWT qui peut être échangé contre un jeton d'accès entièrement autorisé et autorisé
- Échanger le JWT retourné de l'achèvement MFA pour un jeton d'accès entièrement autorisé
- Effectuer des fonctions de gestion d'inscription MFA en utilisant un jeton d'accès entièrement autorisé.

Intégration des utilisateurs

L'intégration des utilisateurs n'est pas un sujet couvert en détail par cet article, cependant quelques points méritent d'être mentionnés et considérés.

IBM Security Verify offre quelques solutions et composants qui permettent de créer et mettre à jour des enregistrements de comptes d'utilisateurs dans le répertoire cloud du locataire.
- Les API SCIM permettent aux applications personnalisées de gérer les enregistrements de comptes d'utilisateurs
- LDAP Directory Sync - permet la synchronisation des enregistrements entre le répertoire cloud et un magasin d'identité externe.
- Le provisioning Just In Time peut être effectué pendant les flux de fédération SSO ou les flux de pont d'authentification sur site.
L'application USC décrite dans l'article exigera que les utilisateurs effectuent une sorte d'authentification MFA avant d'obtenir un jeton d'accès entièrement autorisé qui peut ensuite gérer d'autres facteurs MFA inscrits. email OTP ou sms OTP seront les facteurs MFA minimum acceptables.
- L'application d'intégration devra inscrire un OTP ou un autre facteur au nom des utilisateurs après avoir vérifié et validé le nouvel utilisateur
- L'application d'intégration utilisera probablement un flux d'informations d'identification client pour obtenir un jeton d'accès avec les droits d'API suivants
  - Authentifier n'importe quel utilisateur
  - Gérer les enregistrements d'authentificateur pour tous les utilisateurs
  - Gérer les inscriptions de second facteur pour tous les utilisateurs
  - Gérer les utilisateurs et les groupes standards

Un exemple de représentation API SCIM d'un utilisateur de notre application USC est montré 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"
    ]
}

Exemple de demande et réponse CURL pour inscrire le facteur SMS OTP du nouvel utilisateur est montré 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 MFA et de gestion des utilisateurs finaux d'un locataire IBM Security Verify, un jeton d'accès avec des permissions de droits d'API suffisantes est nécessaire. Une configuration d'application OIDC est nécessaire dans le locataire IBM Security Verify. Certains des éléments de configuration clés pour cette application USC personnalisée sont montrés dans les sections suivantes.

Types d'octroi et paramètres JWT

L'application USC personnalisée utilisera le flux Resource Owner Password Credential (ROPC) pour obtenir un jeton autorisé pour les appels d'API suivants aux points de terminaison de gestion d'inscription MFA. Cela servira également d'authentification de premier facteur. L'octroi jwt-bearer doit également être activé. Cet octroi est utilisé pour obtenir un jeton d'accès entièrement autorisé après qu'une authentification MFA ait été effectuée. La montée en puissance MFA est requise 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 politique d'accès qui seront appliqués aux demandes d'octroi de jeton 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. Ceci est décrit dans une section ultérieure. La politique d'accès sera évaluée et appliquée lors des demandes d'octroi ROPC et JWT Bearer.

Restreindre l'accès API pour le moindre privilège

Le but de cette application USC personnalisée est de fournir une expérience utilisateur spécifique aux utilisateurs finaux leur permettant de gérer leurs facteurs MFA inscrits. Par défaut, toutes les applications OIDC personnalisées reçoivent l'ensemble complet de User Permissions montré dans le diagramme Edit API client ci-dessous. Dans de nombreux cas, cela sur-privilégie les applications OIDC personnalisées. Il est de bonne pratique de limiter les permissions autant que possible. Ceci peut être réalisé en sélectionnant le sous-ensemble minimum de permissions d'API requises par l'application. Dans le cas de cette application USC, ce sous-ensemble est représenté par ces permissions montrées et sélectionnées dans les diagrammes ci-dessous.

Politique d'accès personnalisée

La politique d'accès pour cette application USC est relativement simple. Elle exige l'achèvement d'un premier facteur. Ceci sera réalisé via le flux ROPC au moment de l'exécution. Elle a ensuite une règle de politique, celle par défaut, qui exige l'achèvement réussi d'une MFA par session. Par session dans ce cas sera par octroi de jeton.

La règle de premier contact est montrée ci-dessous.

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

Jeton d'accès USC avec authentification de politique

Avec la configuration d'application OIDC définie dans le locataire IBM Security Verify, l'implémentation de l'application USC peut procéder. Cette section illustrera le type de flux et d'appels d'API nécessaires pour obtenir un jeton d'accès entièrement autorisé après l'achèvement d'une MFA réussie.

Les étapes de base incluent :

Initier un flux d'octroi ROPC
Utiliser le jeton d'accès restreint résultant pour terminer un flux de montée en puissance MFA
Échanger le JWT de la montée en puissance pour un jeton d'accès entièrement autorisé
Terminer une inscription TOTP avec le jeton d'accès entièrement autorisé

Octroi initial

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

L'exemple curl ci-dessous montre le flux ROPC initial. Les points remarquables ici incluent :

L'en-tête d'autorisation est l'autorisation HTTP Basic 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 de cet appel d'API est montrée ci-dessous. Il s'agit d'une réponse de jeton d'accès, cependant il y a des indicateurs que ce n'est pas un jeton entièrement autorisé et qu'une montée en puissance MFA est requise. Ceci est dû à l'évaluation et l'application de la politique d'accès. Le scope = mfa_challenge informe l'application que l'access_token n'est pas entièrement autorisé et que l'utilisateur doit terminer un flux MFA en utilisant l'un des allowedFactors. À ce stade, le jeton d'accès peut être utilisé pour lire les facteurs inscrits des utilisateurs. Ceci peut permettre à l'application d'afficher une liste de sélection à l'utilisateur incluant leurs facteurs MFA inscrits qu'ils pourraient aimer utiliser pour un défi d'authentification MFA.

{
    "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 que non essentiel au fonctionnement global de l'application USC, il est intéressant d'examiner ce jeton d'accès initial pour illustrer son état de droit restreint. Comme on peut le voir dans la réponse d'introspection ci-dessous, le jeton d'accès n'a que trois droits d'API IBM Security Verify :

authn - permet au porteur du jeton d'effectuer des fonctions MFA et de lire les données du répertoire cloud des utilisateurs via /v2.0/Me
readEnrollMFAMethod - permet au porteur du jeton de lire les méthodes MFA inscrites des utilisateurs
readAuthenticators - permet au porteur du jeton de lire les authentificateurs mobiles IBM Verify inscrits des utilisateurs

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 MFA à l'utilisateur

À ce stade, l'application USC doit conduire l'utilisateur à travers un défi MFA. Une approche typique ici pourrait utiliser le jeton d'accès présent pour :

Obtenir une liste des facteurs inscrits disponibles des utilisateurs. S'il y en a et qu'ils satisfont les exigences de la liste allowedFactors de la réponse précédente, l'USC pourrait les inclure dans une invite de sélection pour que l'utilisateur sélectionne.
Lire les données de compte des utilisateurs de /v2.0/Me pour obtenir leur adresse e-mail. Si l'adresse e-mail est définie, alors la liste de sélection MFA pourrait également inclure transient email OTP comme option sur l'invite de sélection MFA.

Voici un exemple de demande et 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 réponse pour obtenir l'adresse e-mail des utilisateurs à partir de leurs données de compte de répertoire cloud :

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 inscrit pour MFA

Pour des raisons de démonstration, cet article procédera ici comme si l'application sélectionnait automatiquement le facteur sms OTP inscrit des utilisateurs afin de satisfaire les exigences MFA pour la politique d'accès USC. La sélection est automatique car l'utilisateur n'a qu'un seul facteur inscrit de l'intégration et cette application USC préfère les facteurs inscrits. Un exemple de demande et réponse est montré ci-dessous qui initie la livraison SMS OTP. Notez la valeur 59aeb30c-02b3-4602-bf70-c8005b9f8cde dans l'URL de l'exemple est l'id du facteur SMS OTP inscrit des utilisateurs.

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 SMS OTP a maintenant été initiée. Peu après, l'utilisateur final recevra un SMS similaire à celui montré ci-dessous. Le SMS contient l'OTP. L'application USC devrait maintenant afficher une invite d'entrée OTP pour permettre à l'utilisateur final d'entrer l'OTP contenu dans le SMS.

L'OTP peut être validé par IBM Security Verify comme montré dans l'exemple curl ci-dessous. Quelques aspects remarquables ici :

L'id de la charge utile de réponse précédente est ajouté à l'URL de vérification SMS OTP.
Le paramètre URL returnJwt=true est défini. Ceci indique que l'application USC souhaite recevoir un JWT signé qui peut ensuite être présenté et échangé contre un jeton d'accès entièrement 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 charge utile de réponse ci-dessus inclut un JWT signé. Le JWT décodé est montré ci-dessous. Ce JWT affirme qu'un SMS OTP MFA a été complété avec succès par la revendication sub indiquée dans le JWT. L'amr affirme que l'utilisateur a complété avec succès les authentifications par mot de passe et SMS OTP dans le contexte de l'octroi de jeton indiqué par grant_id. Ceci satisfait essentiellement la règle MFA per session de la politique d'accès gouvernante.

{
  "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"
}

Échanger JWT MFA pour un jeton d'accès entièrement autorisé

Le JWT de la charge utile de réponse de vérification SMS OTP précédente peut maintenant être échangé contre un jeton d'accès entièrement autorisé en utilisant le flux d'octroi jwt-bearer. Le serveur d'autorisation OIDC IBM Security Verify cependant ne traitera pas ceci comme un nouvel octroi de jeton. Ceci sera traité dans le contexte du grant_id présent.

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 jeton jwt-bearer est montrée ci-dessous. Cette réponse inclut une nouvelle valeur de jeton d'accès et ce jeton est maintenant entièrement autorisé. Les attributs dans cette charge utile sont typiques pour la réponse de jeton OIDC et l'application USC et son utilisateur ont maintenant terminé les exigences MFA de la politique d'accès gouvernante.

{
    "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 montré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
}

Effectuer des fonctions d'inscription MFA USC

L'application USC peut maintenant permettre aux utilisateurs d'effectuer des fonctions d'inscription MFA. Un exemple de demande d'inscription TOTP est montré 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 Security Verify.

Conclusion

Cet article a décrit comment certaines des fonctionnalités clés d'IBM Security Verify peuvent être utilisées pour fournir une application USC personnalisée sécurisée et à autorisation minimale. L'article a 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 de montée en puissance 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.