Utilisation de l'API d'authentification pour développer une page de connexion personnalisée

Étape 1 : Démarrer le flux d'authentification

Un utilisateur ouvre une fenêtre de navigateur pour accéder à une page protégée.

Exemple de formulaire HTML POST

Voici un exemple de formulaire HTML POST que les domaines d'identité retournent pour appeler la page de connexion personnalisée :

<form name="autosubmit" id="autosubmit" action="<custom_ui_signin_URL>" method="POST" onload="submitform();">
     <input name="loginCtx" value="<obfuscated_loginctx_value>" />
     <input name="signature" value="signature_data" />
</form>

Exemple de logique de déchiffrement pour loginCtx chiffré dans Java

Voici un exemple de logique de déchiffrement :

public static String decrypt(String tenantName, String attrName, String attrDecryptValue ) {
        String attrDecrypt = attrDecryptValue;
        final String SHA_256_ALG = "SHA-256";
        final String ENCRYPTION_ALG = "AES/CBC/PKCS5Padding";
        final String SECRET_KEY_ALG = "AES";
        String data = null;
        MessageDigest md = null;
        byte[] keyBytes = new byte[16];
        try {
            md = JCECryptoCache.getMessageDigestInstance(SHA_256_ALG);
            byte[] digest = md.digest(tenantName.toLowerCase().getBytes("UTF-8"));
            System.arraycopy(digest, 0, keyBytes, 0, 16);
        } catch (Exception ex) {
            ex.printStackTrace();
        } finally {
            JCECryptoCache.releaseMessageDigestInstance(md);
        }
 
        // encrypt the data
        Cipher decipher = null;
        try {
            decipher = JCECryptoCache.getCipherInstance(ENCRYPTION_ALG);
            SecretKey secretKey = new SecretKeySpec(keyBytes, SECRET_KEY_ALG);
            decipher.init(Cipher.DECRYPT_MODE,
                    secretKey, new IvParameterSpec(new byte[16]));
            byte[] decryptedData = decipher.doFinal(Base64.getDecoder().decode(attrDecrypt.getBytes("UTF-8")));
            data = new String(decryptedData);
            System.out.println("" + data);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
        return data;
    }

Exemple de réponse

La réponse doit être similaire à l'exemple suivant :

{
  "requestState": "TasNtIxDqWOfDKeTM",
  "nextOp": [
    "credSubmit",
    "chooseIDP"
  ],
  "nextAuthFactors": [
    "IDP",
    "USERNAME_PASSWORD"
  ],
  "status": "success",
  "ecId": "GmY95180000000000",
  "USERNAME_PASSWORD": {
    "credentials": [
      "username",
      "password"
    ]
  },
  "IDP": {
    "configuredIDPs": [
      {
        "iconUrl": "null",
        "idpName": "adc00peq",
        "idpType": "Saml"
      },
      {
        "idpId": "4bb89888feea4b00a0fab3a1a5627539",
        "idpName": "Google",
        "idpType": "Social"
      }
    ],
    "credentials": [
      "idpId",
      "idpType"
    ]
  }
}

Les valeurs de ces attributs définissent le facteur d'authentification, les fournisseurs d'identités et les fournisseurs sociaux qui sont présentés dans la page de connexion. La page de connexion s'affiche et contient les valeurs déchiffrées du paramètre loginCtx ainsi que le jeton d'accès. La page de connexion inclut JavaScript qui est utilisé pour effectuer des appels AJAX aux domaines d'identité.

Étape 2 : Sélectionner un fournisseur d'identités SAML

Exemple de code POST de formulaire HTML pour sélectionner un fichier SAML IdP

var addParamValues = function(myform, value, paramName) {
    if (value !== null && value !== 'undefined') {
        param = document.createElement("input");
        param.value = value;
        param.name = paramName;
        myform.appendChild(param);
    }
};
 
var chooseRemoteIDP = function(name, idpId, type) {
    var myform = document.createElement("form");
    myform.action = GlobalConfig.idcsBaseURL + "/sso/v1/sdk/secure/idp";
    myform.method = "post";
    <%
        Credentials creds = CredentialsList.getCredentials().get(attr);
        String clientId = creds.getId();
    %>
    var clientId = '<%=clientId%>';
    addParamValues(myform, name, "idpName");
    addParamValues(myform, type, "idpType");
    addParamValues(myform, idpId, "idpId");
    addParamValues(myform, clientId, "clientId");
    addParamValues(myform, authorization, "accesstoken")
    addParamValues(myform, GlobalConfig.requestState, "requestState");
    document.body.appendChild(myform);
    myform.submit();
};
 
var activateIdp = function(name, idpId) {
    chooseRemoteIDP(name, idpId, "SAML");
};
 
var activateSocialIdp = function(name, idpId) {         
    chooseRemoteIDP(name, idpId, "SOCIAL");
};

Exemple de demande

Voici un exemple du contenu de FORM POST vers le point d'extrémité /sso/v1/sdk/secure/idp :

requestState=value&idpName=value&idpType=SAML&idpId=value&appName=name&clientID=value&authorization=accesstoken

Exemple de réponse

L'exemple suivant présente le contenu de la réponse au format HTTP standard :

HTTP/1.1 302 See Other
Date: Tue, 30 Oct 2018 04:40:05 GMT
Content-Length: 0
Connection: keep-alive
Pragma: no-cache
Location: https://<domainURL>/idp/sso (Example URL)
Set-cookie: ORA_OCIS_REQ_1=+fxgW2P7bgQayiki5P;Version=1;Path=/;Secure;HttpOnly
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-xss-protection: 1; mode=block
X-content-type-options: nosniff

Les domaines d'identité traitent la demande et redirigent le navigateur vers le fichier IdP externe sélectionné pour authentification et autorisation. Lorsque la commande IdP externe est terminée, le navigateur est redirigé vers les domaines d'identité. Les domaines d'identité valident la réponse à l'assertion et vérifient si une authentification supplémentaire, telle que l'authentification multifacteur, est requise.

Si aucune authentification supplémentaire n'est requise, les domaines d'identité créent la session et redirigent le navigateur vers l'URL cible. Ou, les domaines d'identité créent une soumission automatique HTML FORM POST à la page de connexion personnalisée contenant authnToken. La page de connexion personnalisée crée ensuite la session. Voir Création d'une session.

Étape 1 : Démarrer le flux d'authentification

Un utilisateur ouvre une fenêtre de navigateur pour accéder à une page protégée.

Exemple de formulaire HTML POST

Voici un exemple de formulaire HTML POST que les domaines d'identité retournent pour appeler la page de connexion personnalisée :

<form name="autosubmit" id="autosubmit" action="<custom_ui_signin_URL>" method="POST" onload="submitform();">
     <input name="loginCtx" value="<obfuscated_loginctx_value>" />
     <input name="signature" value="signature_data" />
</form>

Exemple de logique de déchiffrement pour loginCtx chiffré dans Java

Voici un exemple de logique de déchiffrement :

public static String decrypt(String tenantName, String attrName, String attrDecryptValue ) {
        String attrDecrypt = attrDecryptValue;
        final String SHA_256_ALG = "SHA-256";
        final String ENCRYPTION_ALG = "AES/CBC/PKCS5Padding";
        final String SECRET_KEY_ALG = "AES";
        String data = null;
        MessageDigest md = null;
        byte[] keyBytes = new byte[16];
        try {
            md = JCECryptoCache.getMessageDigestInstance(SHA_256_ALG);
            byte[] digest = md.digest(tenantName.toLowerCase().getBytes("UTF-8"));
            System.arraycopy(digest, 0, keyBytes, 0, 16);
        } catch (Exception ex) {
            ex.printStackTrace();
        } finally {
            JCECryptoCache.releaseMessageDigestInstance(md);
        }
 
        // encrypt the data
        Cipher decipher = null;
        try {
            decipher = JCECryptoCache.getCipherInstance(ENCRYPTION_ALG);
            SecretKey secretKey = new SecretKeySpec(keyBytes, SECRET_KEY_ALG);
            decipher.init(Cipher.DECRYPT_MODE,
                    secretKey, new IvParameterSpec(new byte[16]));
            byte[] decryptedData = decipher.doFinal(Base64.getDecoder().decode(attrDecrypt.getBytes("UTF-8")));
            data = new String(decryptedData);
            System.out.println("" + data);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
        return data;
    }

Exemple de réponse

La réponse doit être similaire à l'exemple suivant :

{
  "requestState": "TasNtIxDqWOfDKeTM",
  "nextOp": [
    "credSubmit",
    "chooseIDP"
  ],
  "nextAuthFactors": [
    "IDP",
    "USERNAME_PASSWORD"
  ],
  "status": "success",
  "ecId": "GmY95180000000000",
  "USERNAME_PASSWORD": {
    "credentials": [
      "username",
      "password"
    ]
  },
  "IDP": {
    "configuredIDPs": [
      {
        "iconUrl": "null",
        "idpName": "adc00peq",
        "idpType": "Saml"
      },
      {
        "idpId": "4bb89888feea4b00a0fab3a1a5627539",
        "idpName": "Google",
        "idpType": "Social"
      }
    ],
    "credentials": [
      "idpId",
      "idpType"
    ]
  }
}

Les valeurs de ces attributs définissent le facteur d'authentification, les fournisseurs d'identités et les fournisseurs sociaux qui sont présentés dans la page de connexion. La page de connexion s'affiche et contient les valeurs déchiffrées du paramètre loginCtx ainsi que le jeton d'accès. La page de connexion inclut JavaScript qui est utilisé pour effectuer des appels AJAX aux domaines d'identité.

Étape 2 : Sélectionner un fournisseur d'identités sociales

Exemple de code POST de formulaire HTML pour sélectionner un IdP social

var addParamValues = function(myform, value, paramName) {
    if (value !== null && value !== 'undefined') {
        param = document.createElement("input");
        param.value = value;
        param.name = paramName;
        myform.appendChild(param);
    }
};
 
var chooseRemoteIDP = function(name, idpId, type) {
    var myform = document.createElement("form");
    myform.action = GlobalConfig.idcsBaseURL + "/sso/v1/sdk/secure/idp";
    myform.method = "post";
    <%
        Credentials creds = CredentialsList.getCredentials().get(attr);
        String clientId = creds.getId();
    %>
    var clientId = '<%=clientId%>';
    addParamValues(myform, name, "idpName");
    addParamValues(myform, type, "idpType");
    addParamValues(myform, idpId, "idpId");
    addParamValues(myform, clientId, "clientId");
    addParamValues(myform, authorization, "accesstoken")
    addParamValues(myform, GlobalConfig.requestState, "requestState");
    document.body.appendChild(myform);
    myform.submit();
};
 
var activateIdp = function(name, idpId) {
    chooseRemoteIDP(name, idpId, "SAML");
};
 
var activateSocialIdp = function(name, idpId) {         
    chooseRemoteIDP(name, idpId, "SOCIAL");
};

Exemple de demande

Voici un exemple du contenu de FORM POST vers le point d'extrémité /sso/v1/sdk/secure/idp :

requestState=value&idpName=value&idpType=Social&idpId=value&appName=name&clientID=value&authorization=accesstoken

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

HTTP/1.1 302 See Other
Date: Tue, 30 Oct 2018 04:40:05 GMT
Content-Length: 0
Connection: keep-alive
Pragma: no-cache
Location: https://<domainURL>/idp/sso (Example URL)
Set-cookie: ORA_OCIS_REQ_1=+fxgW2P7bgQayiki5P;Version=1;Path=/;Secure;HttpOnly
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-xss-protection: 1; mode=block
X-content-type-options: nosniff

Les domaines d'identité traitent la demande et redirigent le navigateur vers le IdP social sélectionné pour authentification et autorisation. Lorsque le IdP social est terminé, le navigateur est redirigé vers les domaines d'identité. Les domaines d'identité valident la réponse à l'assertion et vérifient si une authentification supplémentaire, telle que l'authentification multifacteur, est requise.

Si aucune authentification supplémentaire n'est requise, les domaines d'identité créent la session et redirigent le navigateur vers l'URL cible. Ou, les domaines d'identité créent une soumission automatique HTML FORM POST à la page de connexion personnalisée contenant authnToken. La page de connexion personnalisée crée ensuite la session. Voir Création d'une session.

Étape 1 : Démarrer le flux d'authentification

Un utilisateur ouvre une fenêtre de navigateur pour accéder à une page protégée.

Exemple de formulaire HTML POST

Voici un exemple de formulaire HTML POST que les domaines d'identité retournent pour appeler la page de connexion personnalisée :

<form name="autosubmit" id="autosubmit" action="<custom_ui_signin_URL>" method="POST" onload="submitform();">
     <input name="loginCtx" value="<obfuscated_loginctx_value>" />
     <input name="signature" value="signature_data" />
</form>

Exemple de logique de déchiffrement pour loginCtx chiffré dans Java

Voici un exemple de logique de déchiffrement :

public static String decrypt(String tenantName, String attrName, String attrDecryptValue)
        {       
            String attrDecrypt = attrDecryptValue;        
            final String SHA_256_ALG = "SHA-256";       
            final String ENCRYPTION_ALG = "AES/CBC/PKCS5Padding";        
            final String SECRET_KEY_ALG = "AES";       
            String data = null;       
            MessageDigest md = null;       
            byte[] keyBytes = new byte[16];       
            try {           
                md = MessageDigest.getInstance(SHA_256_ALG);           
                byte[] digest = md.digest(tenantName.toLowerCase().getBytes("UTF-8"));           
                System.arraycopy(digest, 0, keyBytes, 0, 16);      
            } catch (Exception ex) 
            {           
              ex.printStackTrace();       
            }          
        // encrypt the data       
        Cipher decipher = null;       
        try {           
        decipher = Cipher.getInstance(ENCRYPTION_ALG);           
        SecretKey secretKey = new SecretKeySpec(keyBytes, SECRET_KEY_ALG);           
        decipher.init(Cipher.DECRYPT_MODE,           
        secretKey, new IvParameterSpec(new byte[16]));           
        byte[] decryptedData = decipher.doFinal(Base64.getDecoder().decode(attrDecrypt.getBytes("UTF-8")));           
        data = new String(decryptedData);           
        System.out.println("" + data);        }
        catch (Exception ex)
        {           
        ex.printStackTrace();       
        }       
        return data;   
       }

Exemple de réponse

La réponse doit être similaire à l'exemple suivant :

{
  "requestState": "TasNtIxDqWOfDKeTM",
  "nextOp": [
    "credSubmit",
    "chooseIDP"
  ],
  "nextAuthFactors": [
    "IDP",
    "USERNAME_PASSWORD"
  ],
  "status": "success",
  "ecId": "GmY95180000000000",
  "USERNAME_PASSWORD": {
    "credentials": [
      "username",
      "password"
    ]
  },
  "IDP": {
    "configuredIDPs": [
      {
        "iconUrl": "null",
        "idpName": "adc00peq",
        "idpType": "Saml"
      },
      {
        "idpId": "4bb89888feea4b00a0fab3a1a5627539",
        "idpName": "Google",
        "idpType": "Social"
      }
    ],
    "credentials": [
      "idpId",
      "idpType"
    ]
  }
}

Les valeurs de ces attributs définissent le facteur d'authentification, les fournisseurs d'identités et les fournisseurs sociaux qui sont présentés dans la page de connexion. La page de connexion s'affiche et contient les valeurs déchiffrées du paramètre loginCtx ainsi que le jeton d'accès. La page de connexion inclut JavaScript qui est utilisé pour effectuer des appels AJAX aux domaines d'identité.

Étape 2 : Sélectionner un fournisseur d'identités externe

Exemple de code POST de formulaire HTML pour sélectionner une adresse IdP externe

var addParamValues = function(myform, value, paramName) {
    if (value !== null && value !== 'undefined') {
        param = document.createElement("input");
        param.value = value;
        param.name = paramName;
        myform.appendChild(param);
    }
};
 
var chooseRemoteIDP = function(name, idpId, type) {
    var myform = document.createElement("form");
    myform.action = GlobalConfig.idcsBaseURL + "/sso/v1/sdk/secure/idp";
    myform.method = "post";
    <%
        Credentials creds = CredentialsList.getCredentials().get(attr);
        String clientId = creds.getId();
    %>
    var clientId = '<%=clientId%>';
    addParamValues(myform, name, "idpName");
    addParamValues(myform, type, "idpType");
    addParamValues(myform, idpId, "idpId");
    addParamValues(myform, clientId, "clientId");
    addParamValues(myform, authorization, "accesstoken") 
    addParamValues(myform, GlobalConfig.requestState, "requestState");
    document.body.appendChild(myform);
    myform.submit();
};
 
var activateIdp = function(name, idpId) {
    chooseRemoteIDP(name, idpId, "SAML");
};
 
var activateSocialIdp = function(name, idpId) {         
    chooseRemoteIDP(name, idpId, "SOCIAL");
};

Exemple de demande

Voici un exemple du contenu de FORM POST vers le point d'extrémité /sso/v1/sdk/secure/idp :

requestState=value&idpName=value&idpType=SAML&idpId=value&appName=name&clientID=value&authorization=accesstoken

Exemple de réponse

L'exemple suivant présente le contenu de la réponse au format HTTP standard :

HTTP/1.1 302 See Other
Date: Tue, 30 Oct 2018 04:40:05 GMT
Content-Length: 0
Connection: keep-alive
Pragma: no-cache
Location: https://<domainURL>/idp/sso (Example URL)
Set-cookie: ORA_OCIS_REQ_1=+fxgW2P7bgQayiki5P;Version=1;Path=/;Secure;HttpOnly
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-xss-protection: 1; mode=block
X-content-type-options: nosniff

Les domaines d'identité traitent la demande et redirigent le navigateur vers le fichier IdP externe sélectionné pour authentification et autorisation. Lorsque le fichier IdP externe est terminé, il redirige le navigateur vers les domaines d'identité, qui redirige ensuite le navigateur pour lancer la vérification en 2 étapes.

Étape 3 : Authentifier à l'aide du facteur privilégié (SMS)

Les étapes initiales pour commencer la vérification en 2 étapes sont similaires à l'étape 1. Les domaines d'identité créent et soumettent un formulaire HTML qui contient les paramètres loginCtx et signature chiffrés. Voir l'étape 1 pour des informations détaillées sur le formulaire POST et la façon de déchiffrer.

Une fois le paramètre loginCtx déchiffré, la réponse doit être similaire à l'exemple suivant :

{
    "status": "success",
    "displayName": "Joe's iPhone",
    "nextAuthFactors": [
        "SMS"
    ],
    "SMS": {
        "credentials": [
            "otpCode"
        ]
    },
    "nextOp": [
        "credSubmit",
        "getBackupFactors",
        "resendCode"
    ],
    "requestState": "QjyV3ueFrGQCO.....84gQw2UUm2V7s",
    "trustedDeviceSettings": {
        "trustDurationInDays": 15
    }
}

Les valeurs de ces attributs définissent le facteur d'authentification (dans cet exemple, il s'agit de SMS) à présenter dans la page de connexion. L'utilisateur entre le code secret à usage unique qu'il reçoit sur son appareil.

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour terminer l'authentification à l'aide de la méthode préférée :

{  
   "op":"credSubmit",
     "credentials":{  
      "otpCode":"108685"
   },
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "authnToken": "eyJraWQiOiJT.....kLbxxL97U_0Q",
    "status": "success"
}

Une session doit ensuite être créée. Une fois la session créée, le navigateur est redirigé vers l'URL demandée à l'origine. Voir Création d'une session.

Étape 1 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "ecId",
 "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "example-password"
        ]
    },
    "requestState": "{{requestState}}"
}

Dans la réponse, la valeur nextOp indique ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires pour traiter la demande.

Étape 2 : Soumettre les données d'identification de l'utilisateur

{
   "op": "credSubmit",
   "credentials": {
      "username": "{{username}}",
      "password": "{{password}}"
   },
   "requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "authnToken": "eyJraWQiOiJT.....UKofudtemmJE",
    "status": "success"
}

Exemple de réponse d'erreur

L'exemple suivant montre le contenu de la réponse au format JSON lorsque le nom d'utilisateur ou le mot de passe fourni n'est pas valide :

{
    "status": "failed",
    "cause": [
        {
            "message": "You entered an incorrect username or password.",
            "code": "AUTH-3001"
        }
    ],
    "requestState": "e5kwGYx57taQ.....jyg3nEDFya"
}

Étape 1 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "ecId",
 "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "example-password"
        ]
    },
    "requestState": "{{requestState}}"
}

Dans la réponse, la valeur nextOp indique ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires pour traiter la demande.

Étape 2 : Soumettre les données d'identification de l'utilisateur sans authentification multifacteur)

Si le nom d'utilisateur et les mots de passe sont valides, le serveur répond avec l'instruction TOU dans les paramètres régionaux spécifiés dans le profil de l'utilisateur. Le serveur invite également l'utilisateur à fournir ses données d'identification de consentement lors de la prochaine demande. Si l'énoncé TOU n'est pas présent dans les paramètres régionaux de l'utilisateur fr, la réponse 401 avec le message d'erreur AUTH-3036 : L'énoncé des conditions d'utilisation pour les paramètres régionaux fr n'est pas ajouté s'affiche.

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON vers le point d'extrémité /sso/v1/sdk/authenticate :

{  
   "op":"credSubmit",
   "credentials":{  
      "username":"{{username}}",
      "password":"{{password}}"
   },
   "requestState":"{{requestState}}"
}
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON lors de l'ajout des paramètres régionaux de l'utilisateur :

{
  "nextOp": [
   "acceptTOU"
  ],
  "TOU": {
    "statement": "This is a placeholder text. Customers must provide the actual Terms of Use.",
    "credentials": [
    "consent"
    ],
    "locale": "en"
  },
 "requestState": "q/tRS4BFAdaimSBhq"
}
}

Exemple de réponse d'erreur

L'exemple suivant montre le contenu de la réponse au format JSON lorsque le TOU pour les paramètres régionaux de l'utilisateur n'est pas ajouté :

{
    "status": "failed",
    "ecId": "Q0ApB1Y1000000000",
    "cause": [
        {
            "message": "Terms of Use Statement for locale fr isn't added.",
            "code": "AUTH-3036"
        }
    ]
}
}

Étape 3 : Fournir le consentement aux conditions d'utilisation

Dans ce scénario, l'utilisateur accepte ou rejette les conditions d'utilisation de l'application. Si l'utilisateur accepte les conditions d'utilisation, il est redirigé vers la page de l'application.

Si l'utilisateur rejette les conditions d'utilisation, la réponse 401 avec un message d'erreur, AUTH-3035 : Vous devez accepter les conditions d'utilisation pour accéder à cette application s'affiche.

Exemple de demande

L'exemple suivant montre le contenu de la demande au format JSON lorsque l'utilisateur accepte TOU.

{
 "op": "acceptTOU",
 "credentials": {
   "consent": true
 },
 "requestState": "{{requestState}}"
}

Exemple de demande

L'exemple suivant montre le contenu de la demande au format JSON lorsque l'utilisateur rejette les conditions d'utilisation.

{
 "op": "acceptTOU",
 "credentials": {
   "consent": false
 },
 "requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON lorsque l'utilisateur accepte l'énoncé TOU.

{
    "authnToken": "eyJ4NXQjUzI1NiI6Iks0R0hvZVdoUm...YUAvuEOrERXrQRnjybdOkA2Q",
    "status": "success",
    "ecId": "Q0ApB1Y1000000000"
}

Exemple de réponse d'erreur

Ce qui suit montre le contenu de la réponse au format JSON lorsque le TOU est rejeté par l'utilisateur.

{
    "status": "failed",
    "ecId": "Q0ApB1Y1000000000",
    "cause": [
        {
            "message": "You must accept the Terms of Use to access this application.",
            "code": "AUTH-3035"
        }
    ]
}

Les domaines d'identité peuvent être configurés pour envoyer un code secret à usage unique basé sur le temps directement à un utilisateur pour authentification ou pour que le code secret soit chiffré et envoyé au client consommateur qui peut ensuite l'envoyer à l'utilisateur pour authentification.

Par exemple, les administrateurs peuvent configurer des domaines d'identité pour envoyer des codes secrets ponctuels (OTP) basés sur le temps à l'application Oracle Mobile Authenticator (OMA) ou envoyer les codes secrets à usage unique par courriel à l'adresse de courriel principale de l'utilisateur. Dans les deux cas, les domaines d'identité génèrent le code secret à usage unique, l'envoient directement à l'utilisateur et celui-ci entre le code pour authentification. Pour comprendre comment définir ces options à l'aide de REST, voir Inscription au facteur d'authentification avec vérification de facteur-SMS et Inscription au facteur d'authentification avec vérification de facteur-Courriel.

Chiffrement et déchiffrement

Cette mise en oeuvre utilise la spécification suivante pour chiffrer et déchiffrer le code secret à usage unique reçu. Voir PKCS #1 : Spécifications de la cryptographie RSA, version 2.0, section 7.1 RSAES-OAEP.

Code de déchiffrement du mot de passe à usage unique

/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */
package decryption;

import java.security.Key;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.cert.CertificateFactory;
import java.security.spec.PKCS8EncodedKeySpec;
import java.util.Base64;
import javax.crypto.Cipher;

/**
 *
 * @author <author>
 */
public class DecryptOtpCode {
    
    private static Key getPrivateKey(String privateKeyPEM) throws Exception {
        byte[] encoded = Base64.getDecoder().decode(privateKeyPEM);
        KeyFactory kf = KeyFactory.getInstance("RSA");
        PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(encoded);
        return kf.generatePrivate(keySpec);
    }
    
    public static void main(String args[]) {
        String value = "<encrypted_value>";
        String privatekey = 
                            "<pem_privatekey_data>";
        try {
                Cipher cipherInstance =
                        Cipher.getInstance("RSA/ECB/OAEPwithSHA1andMGF1Padding");
                CertificateFactory factory = CertificateFactory.getInstance("X.509");
                byte [] decoded = Base64.getDecoder().decode(value);
                PrivateKey pKey = (PrivateKey)getPrivateKey(privatekey);
                cipherInstance.init(Cipher.DECRYPT_MODE, pKey);
                byte[] decrypted = cipherInstance.doFinal(decoded);
                System.out.println("Decrypted text is " + new String(decrypted));
            } catch (Exception e) {
                //Unable to encrypt the content. Default to send the otp to user
                //no error or exception thrown.
                e.printStackTrace();
            }
    }
    
}

Étape 1 : Créer une application CustomUI

Voir Ajouter des applications pour plus d'informations sur les applications personnalisées.

Étape 2 : Générer une paire de clés pour un certificat auto-signé

Étape 3 : Configurer l'application pour retourner le mot de passe à usage unique dans la réponse

Étape 4 : Demander le mot de passe à usage unique

true

{
   "op": "credSubmit",
   "credentials": {
      "username": "test.user",
      "password": "example-password"
   },
   "userFlowControlledByExternalClient": true,
   "x5t": "<certificate thumbprint>",
   "requestState": "{{requestState}}"
}

"otp": {
        "value": "IMCw==",
        "alg": "RSAES-OAEP",
        "x5t": "<certificate thumbprint>"
 }

Exemple de réponse

{
    "otp": {
        "value": "IMsNO+rqNCw==",
        "alg": "RSAES-OAEP",
        "x5t": "<certificate thumbprint>"
    },
    "status": "success",
    "ecId": "Ft^OD161000000000",
    "displayName": "+91XXXXXXXX013",
    "nextAuthFactors": [
        "SMS"
    ],
    "SMS": {
        "credentials": [
            "otpCode"
        ]
    },
    "nextOp": [
        "credSubmit",
        "getBackupFactors",
        "resendCode"
    ],
    "scenario": "AUTHENTICATION",
    "requestState": "FrrACc",
    "trustedDeviceSettings": {
        "trustDurationInDays": 15
    }
}

Étape 1 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "ecId",
 "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "example-password"
        ]
    },
    "requestState": "{{requestState}}"
}

Dans la réponse, la valeur nextOp indique ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires pour traiter la demande.

Étape 2 : Soumettre les données d'identification de l'utilisateur

AuthnToken est le id_token au format JWT qui représente les informations d'utilisateur, la session et les données de demande courantes. Ceci est utilisé pour créer un témoin de session d'authentification unique et rediriger vers l'URL cible. Si le nom d'utilisateur et le mot de passe sont valides, AuthnToken est extrait.

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON vers le point d'extrémité /sso/v1/sdk/authenticate :

{  
   "op":"credSubmit",
   "credentials":{  
      "username":"admin@oracle.com",
      "password":"example-password"
   },
   "requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON où AuthnToken est extrait :

{
    "authnToken": "eyJ4NXQjUzI1NiI6Iks0R0hvZ...ZLjOZmKAvORB8OaV1Xqt1GL3tx1kyWA",
    "status": "success",
    "ecId": "5fR1O171000000000"
}

Étape 3 : Générer le jeton d'accès

Après avoir extrait un AuthnToken, il est utilisé pour obtenir le jeton d'accès à partir du serveur OAuth.

Exemple de demande

L'exemple suivant montre le contenu de la demande au format JSON :

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&scope=urn:opc:idm:__myscopes__&assertion={{authnToken}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "access_token": "<redacted>",
    "token_type": "Bearer",
    "expires_in": 7600
}

Étape 4 : Obtenir des informations sur l'utilisateur

L'utilisateur soumet le jeton d'accès pour obtenir ses informations telles que le nom d'utilisateur, le nom d'affichage, l'ID courriel, etc.

Exemple de demande

L'exemple suivant montre le contenu de la demande au format JSON.

{{HOST}}/admin/v1/Me

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON avec des informations sur l'utilisateur.

{
    "idcsCreatedBy": {
        "type": "App",
        "display": "idcssm",
        "value": "4ba14c4be74d48d497da6ce651209a06",
        "$ref": "https://docteam.identity.internal.oracle.com:8943/admin/v1/Apps/4ba14c4be74d48d497da6ce651209a06"
    },
    "id": "de94e8399a0e4f23ac52fc681f5fb828",
    "meta": {
        "created": "2022-12-12T09:46:53.646Z",
        "lastModified": "2022-12-13T10:35:32.604Z",
        "resourceType": "Me",
        "location": "https://docteam.identity.internal.oracle.com:8943/admin/v1/Me/de94e8399a0e4f23ac52fc681f5fb828"
    },
    "active": true,
    "displayName": "admin opc",
    "idcsLastModifiedBy": {
        "value": "6567bac90beb4e65a2eb3b280b2f0d1f",
        "display": "idcssso",
        "type": "App",
        "$ref": "https://docteam.identity.internal.oracle.com:8943/admin/v1/Apps/6567bac90beb4e65a2eb3b280b2f0d1f"
    },
    "nickName": "TAS_TENANT_ADMIN_USER",
    "userName": "admin@oracle.com",
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
        "isFederatedUser": false
    },
    "emails": [
        {
            "verified": false,
            "primary": false,
            "secondary": false,
            "value": "admin@oracle.com",
            "type": "recovery"
        },
        {
            "verified": false,
            "primary": true,
            "secondary": false,
            "value": "admin@oracle.com",
            "type": "work"
        }
    ],
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User": {
        "locked": {
            "on": false
        }
    },
    "name": {
        "formatted": "admin opc",
        "familyName": "opc",
        "givenName": "admin"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User"
    ]
}

Étape 1 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "ecId",
 "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "example-password"
        ]
    },
    "requestState": "{{requestState}}"
}

Dans la réponse, la valeur nextOp indique ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires pour traiter la demande.

Étape 2 : Soumettre les données d'identification de l'utilisateur

{
   "op": "credSubmit",
   "credentials": {
      "username": "{{username}}",
      "password": "{{password}}"
   },
   "requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON, car PUSH Notifications est le facteur privilégié :

{
    "status": "pending",
    "displayName": "Joe's iPhone",
    "nextAuthFactors": [
        "PUSH"
    ],
    "cause": [
        {
            "code": "AUTH-1108",
            "message": "Push Notification approval is pending."
        }
    ],
    "nextOp": [
        "credSubmit",
        "getBackupFactors"
    ],
    "requestState": "rATagRibc//b.....xrKh7fJtIuWo",
    "trustedDeviceSettings": {
        "trustDurationInDays": 15
    }
}

"trustedDeviceSettings": {
       "trustDurationInDays": 0
 }

Dans la réponse, le statut est pending car l'utilisateur doit autoriser ou refuser l'avis PUSH sur son appareil. Les valeurs nextOp dans la réponse indiquent ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit est envoyé à l'étape suivante.

Étape 3 : Authentifier à l'aide du facteur privilégié

Authentifier à l'aide du facteur privilégié, qui, dans cet exemple de cas d'utilisation, est le service d'avis PUSH. Le client doit inclure les attributs suivants dans cette demande :

• op: indique au serveur le type d'opération souhaité par le client

• requestState: reçu dans la réponse de l'étape 2

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour terminer l'authentification à l'aide de la méthode préférée :

{  
   "op":"credSubmit",
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "authnToken": "eyJraWQiOiJT.....kLbxxL97U_0Q",
    "status": "success"
}

Étape 1 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "ecId",
 "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "example-password"
        ]
    },
    "requestState": "{{requestState}}"
}

Dans la réponse, la valeur nextOp indique ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires pour traiter la demande.

Étape 2 : Soumettre les données d'identification de l'utilisateur

{
   "op": "credSubmit",
   "credentials": {
      "username": "{{username}}",
      "password": "{{password}}"
   },
   "requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "nextAuthFactors": [
        "TOTP",
        "SMS",
        "EMAIL",
        "SECURITY_QUESTIONS"
    ],
    "TOTP": {
        "credentials": [
            "offlineTotp"
        ]
    },
    "SMS": {
        "credentials": [
            "phoneNumber"
        ]
    },
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "mfaSettings": {
        "enrollmentRequired": false
    },
    "requestState": "m3oIaGVOlHwA...../Fi+1RpmKmd4"
}

Dans cet exemple de cas d'utilisation, comme l'authentification multifacteur est définie comme facultative dans la politique d'authentification (indiquée par la valeur false pour l'attribut enrollmentRequired), l'utilisateur peut s'inscrire ou ignorer l'inscription. Si l'authentification multifacteur est requise, la seule valeur nextOp serait enrollment.

Dans cet exemple de cas d'utilisation, enrollment est envoyé à l'étape suivante pour lancer l'inscription au facteur d'authentification multifacteur pour l'utilisateur. Notez que BYPASSCODE est manquant en tant que valeur nextAuthFactors, car l'utilisateur ne peut pas s'inscrire à l'aide d'un code de contournement. Le code de contournement doit être généré par l'utilisateur à l'aide de Mon profil ou en demandant à un administrateur d'en générer un pour lui.

Étape 3 : Lancer l'adhésion à l'authentification avec deuxième facteur

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON :

{  
   "op":"enrollment",
   "authFactor":"TOTP",
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "displayName": "Joe's Phone",
    "TOTP": {
        "credentials": [
            "otpCode"
        ],
        "qrCode": {
            "content": "oraclemobileauthenticator://totp/user?issuer=example1&Period=30&algorithm=SHA1&digits=6&RSA=SHA256withRSA&Deviceid=22f38324e67f4e2bb8e9e24583924a31&RequestId=9b428c1a-abb3-40ee-bd24-5064a87b638e&LoginURL=https%3A%2F%2Fexampletenant.com%3A8943%2Fsso%2Fv1%2F&OTP=eyJraWQiOiJTSUdOSU5HX0tFWSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0.eyJkZXZpY2VfaWQiOiIyMmYzODMyNGU2N2Y0ZTJiYjhlOWUyNDU4MzkyNGEzMSIsImlzcyI6IkF1dGhTcnYiLCJleHAiOjE1MjcxODEwODEsImlhdCI6MTUyNzE4MDc4MSwidGVuYW50IjoidGVuYW50MSJ9.Of0Hv5H3aRpDqdsiFLO0YkK2gbzq78k3jaJFwoWwR5LKOEH-9qTt1zjSiXujPD1T__8fEZDi8iKDyxXtL5zjAlEKd5wI026JjekG58ROPjW8gADWcMrTGQ4Lgw4Q0UPjk8Fm8AloQ1vS6xpDre6S-Vv620z28EKWZK_yGhUVSfAJVzSUxaypLtQhOQJBCNAzCElUgqyav7Vpi2z5eVQBQRtXv-Z_sTgrFXaVmVU3uSNVcg6zVX2x0fMQFgeO5lyC3U2Yy9JgA7iMfAMpuNvBzW0GjyByPAYRVnHSLPuHL1qiNx9ygpoVEcFLQJcOPuDLW2bW9ZwbUcVdS0F4L_2NfA&ServiceType=TOTP&KeyPairLength=2048&SSE=Base32",
            "imageType": "image/png",
            "imageData": "iVBORw0KG.......5ErkJggg=="
        }
    },
    "nextOp": [
        "credSubmit",
        "createToken",
        "createSession",
        "enrollment"
    ],
    "mfaSettings": {
        "enrollmentRequired": false
    },
    "requestState": "8A317/A1JiQe.....ce5/paoVOWw"
}

Étape 4 : Soumettre les données d'identification de facteur

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour soumettre les données d'identification de facteur :

{  
   "op":"credSubmit",
   "requestState":"{{requestState}}"
}

Exemple de réponse

Le statut success apparaît dans la réponse lorsque la communication entre l'application OMA et le canal dorsal du serveur est terminée et que la vérification optCode a réussi. L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "displayName": "Joe's iPhone",
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "eyZa+10USFR7.....6I2vnfK82hnQ"
}

Dans la réponse, les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, createToken est envoyé à l'étape suivante.

Exemple de réponse en attente

Le statut pending s'affiche lorsque la communication entre l'application OMA et le canal dorsal du serveur n'est pas terminée. Le client continue de scruter toutes les 10 secondes et continue de scruter pendant deux minutes. Au bout de deux minutes, le serveur envoie le statut Échec si la vérification otpCode échoue.

{
    "status": "pending",
    "cause": [
        {
            "code": "AUTH-1109",
            "message": "Enrollment in the One-Time Passcode authentication method is pending verification."
        }
    ],
    "nextOp": [
        "credSubmit",
        "createToken",
        "createSession",
        "enrollment"
    ],
    "mfaSettings": {
        "enrollmentRequired": false
    },
    "requestState": "1bYZJeyi6bcp..........74RXYKmbdiZfVW8y7tNc"
}

Étape 5 : Créer le jeton d'authentification

Cette étape indique que le client a terminé toutes les opérations authnFactors et qu'une session doit être créée. Le serveur vérifie qu'aucune autre évaluation de facteur (selon ce qui est défini pour la politique) n'est nécessaire et répond avec le jeton ou refuse l'accès. Le client doit inclure les attributs suivants :

• op: indique au serveur le type d'opération souhaité par le client

• requestState: reçu dans la réponse de l'étape 4

Exemple de demande

{  
   "op":"createToken",
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "authnToken": "{{authnToken}}",
    "status": "success"
}

Étape 1 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "ecId",
 "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "example-password"
        ]
    },
    "requestState": "{{requestState}}"
}

Dans la réponse, la valeur nextOp indique ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires pour traiter la demande.

Étape 2 : Soumettre les données d'identification de l'utilisateur

{
   "op": "credSubmit",
   "credentials": {
      "username": "{{username}}",
      "password": "{{password}}"
   },
   "requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "R^iCq18G000000000",
    "accRecEnrollmentRequired": true,
    "nextAuthFactors": [
        "SMS",
        "SECURITY_QUESTIONS",
        "EMAIL"
    ],
    "SMS": {
        "credentials": [
            "phoneNumber",
            "countryCode"
        ]
    },
    "EMAIL": {
        "userAllowedToSetRecoveryEmail": "true",
        "primaryEmailVerified": "true",
        "primaryEmail": "clarence.saladna@example.com",
        "credentials": [
            "recoveryEmail"
        ]
    },
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "IjhvZPILfadhlnih+4uTJ83CHf....0SDELTO0mTRqC+nNU"
}

Dans cet exemple de cas d'utilisation, l'utilisateur doit s'inscrire à la récupération de compte (indiquée par la valeur true pour l'attribut accRecEnrollmentRequired:true). nextAuthFactors indique les facteurs dans lesquels l'utilisateur peut s'inscrire pour la récupération de compte.

Dans cet exemple de cas d'utilisation, l'inscription est envoyée à l'étape suivante pour lancer l'inscription au recouvrement de compte pour l'utilisateur.

Étape 3 : Lancer l'inscription au recouvrement de compte

Cette étape lance l'inscription par SMS. Le client doit inclure les attributs suivants :

• op : Indique au serveur le type d'opération souhaité par le client
• authFactor : Définit le facteur d'authentification dans lequel l'utilisateur souhaite s'inscrire
• phoneNumber : Définit le numéro de téléphone où le texte SMS sera envoyé
• countryCode : Définit le code de pays du numéro de téléphone où le texte SMS sera envoyé.
• requestState : Réception dans la réponse de l'étape 2

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON :

{  
   "op":"enrollment",
   "authFactor":"SMS",
   "credentials":{  
      "phoneNumber":"1122334455",
      "countryCode":"+44"
   },
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la demande au format JSON :

{
    "status": "success",
    "ecId": "R^iCq19G000000000",
    "displayName": "+44XXXXXXXX455",
    "SMS": {
        "credentials": [
            "otpCode"
        ]
    },
    "nextOp": [
        "credSubmit",
        "resendCode",
        "enrollment"
    ],
    "requestState": "Y4sMHf7izgxcspF6zr...Y3GXLjjudeRMM2ZNty4E"
}

Dans la réponse, les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur d'opération dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit est envoyé à l'étape suivante. otpCode est envoyé par SMS à l'appareil de l'utilisateur.

Étape 4 : Soumettre les données d'identification de facteur

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour soumettre les données d'identification de facteur :

{  
   "op":"credSubmit",
   "credentials":{  
      "otpCode":"974311"
   },
   "requestState":"{{requestState}}"
}

Exemple de réponse

Le statut de réussite apparaît dans la réponse lorsque la vérification optCode réussit. L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "R^iCq1BG000000000",
    "accRecEnrollmentRequired": false,
    "displayName": "+44XXXXXXXX455",
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "BKbGp43pwZad3zMSePWu7R47Va6myZdNY...vRVFN2FFQKIoDto"
}

Dans la réponse, la valeur accRecEnrollmentRequired est réglée à false car l'inscription au compte a réussi. Les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur op dans la demande suivante. La valeur nextOp "enrollment" permet à l'utilisateur de passer à un autre facteur pour s'inscrire à la récupération de compte. Dans cet exemple de cas d'utilisation, createToken est envoyé à l'étape suivante.

Étape 5 : Créer le jeton d'authentification

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON :

{  
   "op":"createToken",
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "authnToken": "{{authnToken}}",
    "status": "success",
    "ecId": "R^iCq1FG000000000"
}

Étape 1 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "ecId",
 "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "example-password"
        ]
    },
    "requestState": "{{requestState}}"
}

Dans la réponse, la valeur nextOp indique ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires pour traiter la demande.

Étape 2 : Soumettre les données d'identification de l'utilisateur

{
   "op": "credSubmit",
   "credentials": {
      "username": "{{username}}",
      "password": "{{password}}"
   },
   "requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "HI^kd1M0000000000",
    "accRecEnrollmentRequired": true,
    "nextAuthFactors": [
        "SMS",
        "SECURITY_QUESTIONS",
        "EMAIL"
    ],
    "SMS": {
        "credentials": [
            "phoneNumber",
            "countryCode"
        ]
    },
    "EMAIL": {
        "userAllowedToSetRecoveryEmail": "true",
        "primaryEmailVerified": "true",
        "primaryEmail": "clarence.saladna@example.com",
        "credentials": [
            "recoveryEmail"
        ]
    },
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "wtyRQpBzFZnuGMQvLNRotKfRIlgliWNc8sxipU....41zjKQcvdzk2bmvWs"
}

Dans cet exemple de cas d'utilisation, l'utilisateur doit s'inscrire à la récupération de compte (indiquée par la valeur true pour l'attribut accRecEnrollmentRequired:true). nextAuthFactors indique les facteurs dans lesquels l'utilisateur peut s'inscrire pour la récupération de compte.

Dans cet exemple de cas d'utilisation, l'inscription est envoyée à l'étape suivante pour lancer l'inscription au recouvrement de compte pour l'utilisateur.

Étape 3 : Lancer l'inscription au recouvrement de compte

Cette étape lance l'inscription par SMS. Le client doit inclure les attributs suivants :

• op : Indique au serveur le type d'opération souhaité par le client
• authFactor : Définit le facteur d'authentification dans lequel l'utilisateur souhaite s'inscrire
• phoneNumber : Définit le numéro de téléphone où le texte SMS sera envoyé
• countryCode : Définit le code de pays du numéro de téléphone où le texte SMS sera envoyé.
• requestState : Réception dans la réponse de l'étape 2

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON :

{  
   "op":"enrollment",
   "authFactor":"SMS",
   "credentials":{  
      "phoneNumber":"1122334455",
      "countryCode":"+44"
   },
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la demande au format JSON :

{
    "status": "success",
    "ecId": "HI^kd1N0000000000",
    "displayName": "+44XXXXXXXX213",
    "SMS": {
        "credentials": [
            "otpCode"
        ]
    },
    "nextOp": [
        "credSubmit",
        "resendCode",
        "enrollment"
    ],
    "requestState": "FnwYT23S0qo+RHXN3Sx80D3....8CsoT3QezVbynT3LfZY3+sXN5E8OtEdM"
}

Dans la réponse, les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur d'opération dans la demande suivante. Dans cet exemple de cas d'utilisation, credSubmit est envoyé à l'étape suivante. otpCode est envoyé par SMS à l'appareil de l'utilisateur. Les données d'identification indiquent à l'utilisateur l'entrée à transmettre dans la demande suivante.

Étape 4 : Soumettre les données d'identification de facteur

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour soumettre les données d'identification de facteur :

{  
   "op":"credSubmit",
   "credentials":{  
      "otpCode":"974311"
   },
   "requestState":"{{requestState}}"
}

Exemple de réponse

Le statut de réussite apparaît dans la réponse lorsque la vérification optCode réussit. L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "HI^kd1P0000000000",
    "accRecEnrollmentRequired": false,
    "displayName": "+44XXXXXXXX455",
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "Z+ysro8gFyPPT5bI9C/RykLfRrq5rBXCOO68/wZcgkllw765qd7SNvhRN6ZHp0Xiw2FIN9nOeio7SpsEAlYxO2xQ/1fF5lAjo0jwJEzIgSRt8xj/vAQeSLhX+PRm2a1rRYHwSa9uFcUBkNA.....KP7CPh2/yrdZF4WpbI"
}

Dans la réponse, la valeur accRecEnrollmentRequired est réglée à false car l'inscription au compte a réussi. Les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur op dans la demande suivante. La valeur nextOp "enrollment" permet à l'utilisateur de passer à un autre facteur pour s'inscrire à la récupération de compte. Dans cet exemple de cas d'utilisation, createToken est envoyé à l'étape suivante.

Étape 5 : Créer le jeton d'authentification

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON :

{  
   "op":"createToken",
   "requestState":"{{requestState}}"
}

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON :

{
    "status": "success",
    "ecId": "HI^kd1Q0000000000",
    "nextAuthFactors": [
        "TOTP",
        "SECURITY_QUESTIONS",
        "SMS",
        "EMAIL",
        "PUSH"
    ],
    "EnrolledAccountRecoveryFactorsDetails": {
        "SMS": {
            "credentials": [
                "accountRecoveryFactor"
            ],
            "enrolledDevices": [
                {
                    "deviceId": "3ed9b2ed366441fb91c9277abd694348",
                    "displayName": "+44XXXXXXXX455"
                }
            ]
        },
        "EMAIL": {
            "credentials": [
                "accountRecoveryFactor"
            ],
            "enrolledDevices": [
                {
                    "displayName": "clarence.saladna@example.com"
                }
            ]
        },
        "enrolledAccRecFactorsList": [
            "SMS",
            "EMAIL"
        ]
    },
    "nextOp": [
        "enrollment"
    ],
    "mfaSettings": {
        "enrollmentRequired": true
    },
    "requestState": "YN9sdSJiNtD5lOEKt33paDa9Ezs5ZZhZhF3C1BsDCuMdVVNqt1RmA3d3SppmnVOIP3uYrErQNYADHCIQLrXgmxpxReUzdcFDArlejaaph3qWctYvLQiIsBwixsHgTOfQiDkzyjN8JZiX/gqbkTEmHi1S3EtjYXuw7qCcwi...G8ZnyfTrcZtKEpaDDj7CtWF/+LIwAEQLvFaXvkOK4P4"
}

Dans la réponse, comme l'authentification multifacteur est requise, enrollmentRequired a une valeur de true sous mfaSettings. Par conséquent, aucun jeton n'est émis. EnrolledAccountRecoveryFactorsDetails affiche les facteurs de récupération de compte auxquels l'utilisateur s'est inscrit. Les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple, la valeur nextOp "enrollment" indique que l'utilisateur doit s'inscrire à l'authentification multifacteur.

Étape 6 : Définir le SMS comme facteur d'authentification multifacteur par défaut dans le chevauchement

Cette étape indique que le client doit s'inscrire à l'authentification multifacteur.

Le client doit inclure les attributs suivants :

• authFactor : Indique le facteur d'inscription à l'authentification multifacteur
• accountRecoveryFactor : Lorsqu'il est réglé à Vrai, indique que l'utilisateur souhaite réutiliser le facteur de récupération de compte déjà inscrit pour l'authentification multifacteur.

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON :

{ 
 "op":"enrollment",
 "authFactor": "SMS",
 "credentials":{ 
  "accountRecoveryFactor" : true 
 },
 "requestState": "{{requestState}}"
}

Exemple de réponse

{
    "status": "success",
    "ecId": "HI^kd1R0000000000",
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "7J6m/Z1PxXQZp4pigzt1F0CXp0kotX.....WXP2knQa16MNj5E8"
}

Dans la réponse, les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur d'opération dans la demande suivante. La valeur nextOp "enrollment" permet à l'utilisateur d'inscrire un facteur supplémentaire à l'authentification multifacteur. Dans cet exemple de cas d'utilisation, createToken est envoyé à l'étape suivante.

Étape 7 : Créer le jeton d'authentification

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON :

{  
   "op":"createToken",
   "requestState":"{{requestState}}"
}

Exemple de réponse

{
    "authnToken": "{{authnToken}}",
    "status": "success",
    "ecId": "HI^kd1W0000000000"
}

Avant de commencer

Étape 1 : Activer l'ICM pour un domaine d'identité

1. Obtenez le jeton d'accès de l'administrateur du domaine d'identité pour votre compte.
2. Exécutez GET sur le point d'extrémité /admin/v1/KmsiSettings/KmsiSettings. Le système retourne KmsiSettings.
3. Mettez à jour les attributs nécessaires et exécutez PUT sur le point d'extrémité /admin/v1/KmsiSettings/KmsiSettings.

tokenValidityInDays

Entrez le nombre de jours pendant lesquels les utilisateurs peuvent rester connectés avant d'être automatiquement déconnectés.

kmsiEnabled

Indique si l'ICM est activé pour le domaine d'identité.

maxAllowedSessions

Entrez le nombre maximal de sessions connectées qu'un utilisateur peut avoir.

Exemple de demande

{
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:KmsiSettings"
    ],
    "tokenValidityInDays": 2160,
    "kmsiEnabled": true,
    "maxAllowedSessions": 5,
    "id": "KmsiSettings"
}

Étape 2 : Démarrer le flux d'authentification

Obtenez le requestState initial pour commencer le flux d'authentification.

Exemple de demande

L'exemple suivant présente la demande au format cURL :

   curl  -X GET
   -H "Content-Type: application/json" 
   -H "Authorization: Bearer {{access_token_value}}"
   https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}

Exemple de réponse

{
    "status": "success",
    "ecId": "ZzK2c1^0000000000",
    "nextOp": [
        "credSubmit"
    ],
    "nextAuthFactors": [
        "USERNAME_PASSWORD"
    ],
    "USERNAME_PASSWORD": {
        "credentials": [
            "username",
            "password"
        ]
    },
    "keepMeSignedInEnabled": false,
    "requestState": "FT7qI"
}

Notez le nouvel attribut keepMeSignedInEnabled inclus dans la réponse. Cela indique que ce domaine d'identité et cette application prennent en charge l'ICM. Si vous disposez d'une interface personnalisée, utilisez cet attribut pour afficher l'option Garder ma session connectée dans la page de connexion.

Étape 3 : Soumettre les données d'identification de l'utilisateur avec KMSI

{
    "op": "credSubmit",
    "credentials": {
        "username": "username",
        "password": "Password"
    },
    "keepMeSignedIn": true,
    "kmsiDeviceDisplayName": "Postman KeepMeSigned In",
    "requestState": "requestState"
}

Si vous disposez d'une interface personnalisée, utilisez cet attribut pour afficher l'option KMSI, cochez la case Statut (Activé ou Désactivé) et envoyez ce paramètre pour créer la session KMSI.

Exemple de réponse

{
    "authnToken": "QpfQIQ",
    "kmsiToken": "ZJM",
    "status": "success",
    "ecId": "PR8Yf160000000000"
}

Dans l'exemple de réponse, notez l'attribut kmsiToken. Ce jeton peut être utilisé pour accéder à n'importe quelle application à l'avenir sans qu'un utilisateur soit obligé de se reconnecter.

Étape 4 : Réémettre authnToken après l'expiration de la session

Exemple de demande

{
    "op": "credSubmit",
    "authFactor": "KMSI",
    "appName": "AppName",
    "kmsiToken": "{{kmsiToken}}"
}

Exemple de réponse

{
    "authnToken": "QpfQIQ",
    "kmsiToken": "ZJM",
    "status": "success",
    "ecId": "PR8Yf160000000000"
}

Notez l'opération credSubmit avec les nouveaux authFactor, appName et kmsiToken envoyés dans la demande. L'authentification unique évalue la demande et retourne authnToken et la dernière mise à jour kmsiToken dans la réponse. Il s'agit d'une valeur kmsiToken actualisée et remplace le jeton existant. Vous devez inclure cette valeur actualisée kmsiToken dans la demande suivante.

Étape 5 : Soumettre les données d'identification de l'utilisateur avec le flux KMSI et MFA

Lancez GET sur /sso/v1/sdk/authenticate à partir de l'étape 2 : Commencer le flux d'authentification.

Exemple de réponse

{
    "op": "credSubmit",
    "credentials": {
        "username": "username",
        "password": "Password"
    },
    "keepMeSignedIn": true,
    "kmsiDeviceDisplayName": "Postman KeepMeSigned In",
    "requestState": "requestState"
}

Exemple de réponse

{
    "status": "success",
    "ecId": "L371Y0xD000000000",
    "displayName": "sswXXXXX@oracle.com",
    "nextAuthFactors": [
        "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE"
    ],
    "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE": {
        "credentials": [
            "otpCode"
        ]
    },
    "nextOp": [
        "credSubmit",
        "getBackupFactors",
        "resendCode"
    ],
    "scenario": "AUTHENTICATION",
    "requestState": "QQwppp+-",
    "trustedDeviceSettings": {
        "trustDurationInDays": 15
    }
}

Une fois que vous avez obtenu le code secret à usage unique (OTP) sur l'appareil, ajoutez le code secret à usage unique dans la demande.

Exemple de demande

{
    "op": "credSubmit",
    "authFactor": "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE",
    "credentials": {
        "otpCode": "XXXX"
    },
    "requestState": "6tnX6Q4RGqe4Lq73WD0pQ"
}

La réponse inclut authToken et kmsiToken. Il s'agit d'un kmsiToken actualisé.

Exemple de réponse

{
    "authnToken": "QpfQIQ",
    "kmsiToken": "ZJM",
    "status": "success",
    "ecId": "PR8Yf160000000000"
}

Étape 6 : Réémettre authnToken après l'expiration de la session lorsqu'un facteur d'authentification multifacteur est défini

Lorsqu'un utilisateur tente de se connecter à l'aide de kmsiToken et qu'un deuxième facteur est configuré, l'utilisateur est toujours invité à authentifier le deuxième facteur. Une fois l'authentification réussie, authnToken et kmsiToken seront envoyés dans la réponse.

Exemple de demande

{
    "op": "credSubmit",
    "authFactor": "KMSI",
    "appName": "AppName",
    "kmsiToken": "{{kmsiToken}}"
}

La réponse contient un jeton KMSI actualisé et une identification d'authentification multifacteur.

Exemple de réponse

{
    "status": "success",
    "ecId": "pccFR1eG000000000",
    "displayName": "XXXXX@oracle.com",
    "nextAuthFactors": [
        "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE"
    ],
    "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE": {
        "credentials": [
            "otpCode"
        ]
    },
    "nextOp": [
        "credSubmit",
        "getBackupFactors",
        "resendCode"
    ],
    "scenario": "AUTHENTICATION",
    "requestState": "+Dj6hQQ7id5V2gSGHGtCROb5n",
    "trustedDeviceSettings": {
        "trustDurationInDays": 15
    },
    "kmsiToken": "fxkLne3RtKI1c"
}

Répétez le même processus où vous serez à nouveau invité à entrer le code secret à usage unique sur l'appareil. Fournissez les données utiles ci-dessous avec le code secret à usage unique. La réponse doit inclure authnToken.

Exemple de demande

{
    "op": "credSubmit",
    "authFactor": "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE",
    "credentials": {
        "otpCode": "XXXX"
    },
    "requestState": "6tnX6Q4RGqe4Lq73WD0pQ"
}

Exemple de réponse

{
    "authnToken": "QpfQIQ",
    "status": "success",
    "ecId": "PR8Yf160000000000"
}

Flux kmsiToken avec requestState

Utilisez ce flux pour prendre en charge le contexte du navigateur lorsque vous possédez le jeton KMSI, mais pas le témoin KMSI. Après l'expiration de la session, l'application effectue un appel d'autorisation au système d'identités avec redirectUrl, state, nonce, etc. Dans la réponse, le système d'identité retourne requestState dans loginCtx. Cette requestState ainsi que le jeton KMSI sont transmis pour rediriger l'application requise après l'extension de la session.

Exemple de demande

{
    "op": "credSubmit",
    "authFactor": "KMSI",
    "appName": "KMSIAdmin",
    "kmsiToken": "{{kmsiToken}}",
    "requestState": "{{requestState}}"
}

Exemple de réponse

{
    "authnToken": "QpfQIQ",
    "kmsiToken": "ZJM",
    "status": "success",
    "ecId": "PR8Yf160000000000"
}

Modifications apportées à /sso/v1/sdk/secure/session

L'ICM nécessite l'ajout d'un nouvel attribut au point d'extrémité /sso/v1/sdk/secure/session. kmsiToken doit être envoyé au point d'extrémité à partir de l'application de connexion personnalisée.

Signature des données utiles pour les appels lancés par /authorize

1. Lorsqu'un utilisateur accède à une application Web protégée par des domaines d'identité, il entre son URL d'application, par exemple https://example.com/home/pages/profile.
2. Le système redirige vers l'appel /authorize du domaine d'identité.
3. Le domaine d'identité redirige l'utilisateur vers la page de connexion personnalisée déployée par le client.
4. L'application de connexion hébergée par le client collecte les paramètres d'entrée et décode l'entrée loginCtx.
5. Le paramètre d'entrée déchiffré correspond à l'appel GET /sso/v1/sdk/authenticate.
6. Les données utiles contiennent keepMeSignedInEnabled pour déterminer si l'ICM est activé.
7. L'application de connexion personnalisée collecte les données d'identification et les soumet au domaine d'identité.
8. Le domaine d'identité valide les données d'identification et émet kmsiToken et authnToken.
9. L'application de connexion personnalisée utilise authnToken et kmsiToken lors de l'appel au point d'extrémité /sso/v1/sdk/secure/session. La nouvelle syntaxe du point d'extrémité sécurisé est décrite sous Modifications à /sso/v1/sdk/secure/session.
10. Le domaine d'identité valide authnToken, kmsiToken, puis le système d'identité émet le témoin de session d'authentification unique et le témoin KMSI.
11. Au cours de la session, le témoin KMSI est validé pour étendre la session sans entrer de nouveau les données d'identification.