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 de médias sociaux qui sont présentés dans la page de connexion. La page de connexion apparaît contenant les valeurs déchiffrées du paramètre loginCtx avec le jeton d'accès. La page de connexion comprend 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 du 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 montre le contenu de la réponse dans le 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 l'adresse IdP externe sélectionnée pour authentification et autorisation. Lorsque IdP externe 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 = 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 de médias sociaux qui sont présentés dans la page de connexion. La page de connexion apparaît contenant les valeurs déchiffrées du paramètre loginCtx avec le jeton d'accès. La page de connexion comprend 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 fichier social 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 du 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 les médias sociaux IdP sélectionnés pour authentification et autorisation. Lorsque les médias sociaux IdP sont terminés, 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 de médias sociaux qui sont présentés dans la page de connexion. La page de connexion apparaît contenant les valeurs déchiffrées du paramètre loginCtx avec le jeton d'accès. La page de connexion comprend 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 un fichier 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 du 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 montre le contenu de la réponse dans le 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 l'adresse IdP externe sélectionnée pour authentification et autorisation. Lorsque IdP externe est terminé, il redirige le navigateur vers des domaines d'identité, qui redirige ensuite le navigateur pour commencer 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 contenant les paramètres loginCtx et signature chiffrés. Voir l'étape 1 pour des informations détaillées sur le formulaire POST et comment le 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 privilégié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 la valeur requestState initiale pour démarrer 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 au traitement de 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 la valeur requestState initiale pour démarrer 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 au traitement de la demande.

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

Si le nom 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 dans la demande suivante. 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 pour 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 TOU

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 refuse les conditions d'utilisation, le message d'erreur 401, 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 le TOU.

{
 "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 affiche le contenu de la réponse au format JSON lorsque l'utilisateur refuse l'utilisation.

{
    "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 (OTP) 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.

Cryptage et déchiffrement

Cette mise en oeuvre utilise les spécifications suivantes pour chiffrer et déchiffrer le code OTP reçu. Voir PKCS #1 : Spécifications de 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 code secret à 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 la valeur requestState initiale pour démarrer 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 au traitement de la demande.

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

AuthnToken est le fichier id_token au format JWT qui représente les informations sur l'utilisateur courant, la session et les données de demande. Sert à créer un témoin de session d'authentification unique et à le 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 pour 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

Une fois que vous avez extrait 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 la valeur requestState initiale pour démarrer 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 au traitement de 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 les avis PUSH sont 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é

Authentifiez-vous à l'aide du facteur préféré, qui dans cet exemple de cas d'utilisation est PUSH Notifications. 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 privilégié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 la valeur requestState initiale pour démarrer 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 au traitement de 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 est 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'inscription à l'authentification au 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 du facteur

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour soumettre les données d'identification du 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. Après deux minutes, le serveur envoie le statut d'é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 est terminé avec tous les éléments 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 stratégie) 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 la valeur requestState initiale pour démarrer 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 au traitement de 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 auxquels 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 auquel l'utilisateur veut s'inscrire
• phoneNumber : Définit le numéro de téléphone où le texte du SMS sera envoyé.
• countryCode : Définit le code de pays du numéro de téléphone où le texte du 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 du facteur

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour soumettre les données d'identification du 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 est réussie. 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 "adhésion" 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 la valeur requestState initiale pour démarrer 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 au traitement de 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 auxquels 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 auquel l'utilisateur veut s'inscrire
• phoneNumber : Définit le numéro de téléphone où le texte du SMS sera envoyé.
• countryCode : Définit le code de pays du numéro de téléphone où le texte du 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 quelle entrée est nécessaire pour transmettre la demande suivante.

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

Exemple de demande

L'exemple suivant montre le contenu de la demande POST au format JSON pour soumettre les données d'identification du 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 est réussie. 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 "adhésion" 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 la valeur 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 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 auquel s'inscrire pour l'authentification multifacteur
• accountRecoveryFactor : Lorsque cette option est réglée à 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 "adhésion" permet à l'utilisateur d'inscrire un facteur supplémentaire pour 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 KMSI 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 leur déconnexion automatique.

kmsiEnabled

Indique si KMSI 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 la valeur requestState initiale pour démarrer 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. Indique que ce domaine d'identité et cette application prennent en charge KMSI. Si vous disposez d'une interface personnalisée, utilisez cet attribut pour afficher l'option Garder ma session active 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 (activée ou désactivée) 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 à toutes les applications à l'avenir sans nécessiter qu'un utilisateur se reconnecte.

É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 un nouveau authFactor, appName et kmsiToken en cours d'envoi 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'un kmsiToken actualisé et remplace le jeton existant. Vous devez inclure cette kmsiToken actualisée 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 : Démarrer 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
    }
}

Après avoir 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 comprend 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é, il est toujours invité à authentifier le deuxième facteur. Ce n'est qu'après une authentification réussie que 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 à l'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 mot de passe à 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é 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 avoir prolongé 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

KMSI 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 /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 identifier si KMSI 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 dans 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. Pendant la session, le témoin KMSI est validé pour prolonger la session sans entrer de nouveau les données d'identification.