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

Etape 1 : lancement du 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é renvoient 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écryptage pour loginCtx crypté dans Java

Voici un exemple de logique de décryptage :

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 réseaux sociaux qui sont présentés sur la page de connexion. La page de connexion apparaît avec les valeurs décryptées du paramètre loginCtx et le jeton d'accès. La page de connexion inclut JavaScript utilisé pour effectuer des appels AJAX vers des domaines d'identité.

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

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

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 l'autotest FORM POST vers l'adresse /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 illustre 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 l'option IdP externe est terminée, le navigateur est redirigé vers les domaines d'identité. Les domaines d'identité valident la réponse d'assertion et vérifient si une authentification supplémentaire, telle que l'authentification à plusieurs facteurs, 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. Sinon, les domaines d'identité créent une soumission automatique HTML FORM POST vers la page de connexion personnalisée contenant authnToken. La page de connexion personnalisée crée ensuite la session. Reportez-vous à la section Creating a Session.

Etape 1 : lancement du 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é renvoient 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écryptage pour loginCtx crypté dans Java

Voici un exemple de logique de décryptage :

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 réseaux sociaux qui sont présentés sur la page de connexion. La page de connexion apparaît avec les valeurs décryptées du paramètre loginCtx et le jeton d'accès. La page de connexion inclut JavaScript utilisé pour effectuer des appels AJAX vers des domaines d'identité.

Etape 2 : sélection d'un fournisseur d'identités sociales

Exemple de code POST de formulaire HTML pour sélectionner un réseau 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 de l'autotest FORM POST vers l'adresse /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 illustre 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 réseau social IdP sélectionné pour authentification et autorisation. Lorsque le réseau social IdP est terminé, le navigateur est redirigé vers les domaines d'identité. Les domaines d'identité valident la réponse d'assertion et vérifient si une authentification supplémentaire, telle que l'authentification à plusieurs facteurs, 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. Sinon, les domaines d'identité créent une soumission automatique HTML FORM POST vers la page de connexion personnalisée contenant authnToken. La page de connexion personnalisée crée ensuite la session. Reportez-vous à la section Creating a Session.

Etape 1 : lancement du 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é renvoient 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écryptage pour loginCtx crypté dans Java

Voici un exemple de logique de décryptage :

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 réseaux sociaux qui sont présentés sur la page de connexion. La page de connexion apparaît avec les valeurs décryptées du paramètre loginCtx et le jeton d'accès. La page de connexion inclut JavaScript utilisé pour effectuer des appels AJAX vers des domaines d'identité.

Etape 2 : sélection d'un fournisseur d'identités externe

Exemple de code POST de formulaire HTML pour sélectionner un 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 l'autotest FORM POST vers l'adresse /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 illustre 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é, puis le redirige vers le navigateur pour commencer la vérification en 2 étapes.

Etape 3 : Authentification à l'aide du facteur préféré (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 cryptés. Reportez-vous à l'étape 1 pour obtenir des informations détaillées sur le formulaire POST et sur la façon de le déchiffrer.

Une fois le paramètre loginCtx décrypté, 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 sur la page de connexion. L'utilisateur saisit le code secret à usage unique qu'il reçoit sur son appareil.

Exemple de demande

L'exemple suivant présente 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 illustre 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 initialement demandée. Reportez-vous à la section Creating a Session.

Etape 1 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit doit être envoyé à l'étape suivante. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : Soumettre les informations d'identification de l'utilisateur

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

Exemple de réponse

L'exemple suivant illustre 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 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"
}

Etape 1 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit doit être envoyé à l'étape suivante. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : Soumettre les informations d'identification de l'utilisateur sans authentification à plusieurs facteurs

Si le nom utilisateur et les mots de passe sont valides, le serveur répond avec l'instruction PT dans l'environnement local spécifié dans le profil de l'utilisateur. Le serveur invite également l'utilisateur à fournir ses informations d'identification de consentement dans la demande suivante. Si l'instruction PT n'est pas présente dans l'environnement local de l'utilisateur fr, la réponse 401 avec le message d'erreur AUTH-3036 : Déclaration des conditions d'utilisation pour l'environnement local fr n'est pas ajoutée s'affiche.

Exemple de demande

L'exemple suivant présente le contenu de la demande POST au format JSON vers l'adresse /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 la PT pour les paramètres régionaux de l'utilisateur n'est pas ajoutée :

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

Etape 3 : Fournir le consentement PT

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 la PT.

{
 "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 la PT.

{
 "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'instruction PT.

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

Exemple de réponse d'erreur

La section suivante présente le contenu de la réponse au format JSON lorsque la PT est rejetée 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 (OTP) directement à un utilisateur pour authentification ou pour que le code secret soit crypté 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 de passe à usage unique basés sur le temps (OTP) à l'application Oracle Mobile Authenticator (OMA) ou envoyer les codes de passe à usage unique par courriel à l'adresse électronique principale de l'utilisateur. Dans les deux cas, les domaines d'identité génèrent le mot de passe à usage unique, l'envoient directement à l'utilisateur et celui-ci saisit le code pour l'authentification. Pour savoir comment définir ces options à l'aide de REST, reportez-vous à Inscription à un facteur d'authentification avec vérification de facteur - SMS et à Inscription à un facteur d'authentification avec vérification de facteur - Courriel.

Cryptage et décryptage

Cette implémentation utilise la spécification suivante pour crypter et décrypter le code de mot de passe à usage unique reçu. Reportez-vous à la section PKCS #1 : RSA Cryptography Specifications, Version 2.0, section 7.1 RSAES-OAEP.

Code de décryptage de 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();
            }
    }
    
}

Etape 1 : créer une application CustomUI

Pour plus d'informations sur les applications personnalisées, reportez-vous à Ajouter des applications.

Etape 2 : génération d'une paire de clés pour un certificat auto-signé

Etape 3 : configuration de l'application pour renvoyer le mot de passe à usage unique dans la réponse

Etape 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
    }
}

Etape 1 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit doit être envoyé à l'étape suivante. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : Soumettre les informations d'identification de l'utilisateur

AuthnToken est le fichier id_token au format JWT qui représente les informations utilisateur, la session et les données de demande en cours. Permet de créer un cookie de session SSO et de rediriger vers l'URL cible. Si le nom utilisateur et le mot de passe sont valides, AuthnToken est extrait.

Exemple de demande

L'exemple suivant présente le contenu de la demande POST au format JSON vers l'adresse /sso/v1/sdk/authenticate :

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

Exemple de réponse

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

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

Etape 3 : génération d'un jeton d'accès

Une fois que vous avez extrait un élément AuthnToken, il est utilisé pour obtenir le jeton d'accès à partir du serveur OAuth.

Exemple de demande

L'exemple suivant illustre 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 illustre le contenu de la réponse au format JSON :

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

Etape 4 : Obtenir les informations 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 d'e-mail, etc.

Exemple de demande

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

{{HOST}}/admin/v1/Me

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON avec des informations 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"
    ]
}

Etape 1 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit doit être envoyé à l'étape suivante. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : Soumettre les informations 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 préféré :

{
    "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 la notification PUSH sur son appareil. Les valeurs nextOp de la réponse indiquent ce qui peut être envoyé en tant que valeur op dans la demande suivante. Dans cet exemple de cas d'emploi, credSubmit est envoyé à l'étape suivante.

Etape 3 : Authentification à l'aide du facteur préféré

Authentifiez-vous à l'aide du facteur préféré, qui dans cet exemple de cas d'emploi est Notifications 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 présente 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 illustre le contenu de la réponse au format JSON :

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

Etape 1 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit doit être envoyé à l'étape suivante. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : Soumettre les informations d'identification de l'utilisateur

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

Exemple de réponse

L'exemple suivant illustre 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'emploi, étant donné que l'authentification à plusieurs facteurs est définie comme facultative dans la stratégie de connexion (indiquée par la valeur false pour l'attribut enrollmentRequired), l'utilisateur a le choix entre s'inscrire ou ignorer l'inscription. Si l'authentification à plusieurs facteurs est requise, la seule valeur nextOp serait enrollment.

Dans cet exemple de cas d'emploi, enrollment est envoyé à l'étape suivante pour lancer l'inscription du facteur d'authentification à plusieurs facteurs 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.

Etape 3 : Lancer l'inscription à l'authentification du deuxième facteur

Exemple de demande

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

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

Exemple de réponse

L'exemple suivant illustre 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"
}

Etape 4 : Soumettre les informations d'identification de facteur

Exemple de demande

L'exemple suivant présente le contenu de la demande POST au format JSON pour soumettre les informations d'identification de facteur :

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

Exemple de réponse

Le statut success apparaît dans la réponse lorsque l'application OMA vers le canal arrière du serveur est terminée et que la vérification optCode a réussi. L'exemple suivant illustre 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'emploi, createToken est envoyé à l'étape suivante.

Exemple de réponse en attente

Le statut pending apparaît lorsque la communication entre l'application OMA et le canal arrière du serveur n'est pas terminée. Le client continue à interroger toutes les 10 secondes et continue à interroger pendant deux minutes. Au bout de 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"
}

Etape 5 : création du 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 illustre le contenu de la réponse au format JSON :

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

Etape 1 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit doit être envoyé à l'étape suivante. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : Soumettre les informations d'identification de l'utilisateur

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

Exemple de réponse

L'exemple suivant illustre 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'emploi, 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'emploi, l'inscription est envoyée à l'étape suivante pour lancer l'inscription à la récupération de compte pour l'utilisateur.

Etape 3 : Lancer l'inscription à la récupération de compte

Cette étape lance l'inscription à 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 souhaite s'inscrire.
• phoneNumber : définit le numéro de téléphone où le texte SMS sera envoyé
• countryCode : définit le code pays du numéro de téléphone où le texte SMS sera envoyé
• requestState : reçu dans la réponse de l'étape 2

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit est envoyé à l'étape suivante. L'élément otpCode est envoyé via SMS à l'appareil de l'utilisateur.

Etape 4 : Soumettre les informations d'identification de facteur

Exemple de demande

L'exemple suivant présente le contenu de la demande POST au format JSON pour soumettre les informations 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 illustre 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 définie sur 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" (Inscription) permet à l'utilisateur de basculer vers un autre facteur pour s'inscrire à la récupération de compte. Dans cet exemple de cas d'emploi, createToken est envoyé à l'étape suivante.

Etape 5 : création du jeton d'authentification

Exemple de demande

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

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

Exemple de réponse

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

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

Etape 1 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit doit être envoyé à l'étape suivante. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : Soumettre les informations d'identification de l'utilisateur

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

Exemple de réponse

L'exemple suivant illustre 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'emploi, 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'emploi, l'inscription est envoyée à l'étape suivante pour lancer l'inscription à la récupération de compte pour l'utilisateur.

Etape 3 : Lancer l'inscription à la récupération de compte

Cette étape lance l'inscription à 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 souhaite s'inscrire.
• phoneNumber : définit le numéro de téléphone où le texte SMS sera envoyé
• countryCode : définit le code pays du numéro de téléphone où le texte SMS sera envoyé
• requestState : reçu dans la réponse de l'étape 2

Exemple de demande

L'exemple suivant illustre 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 illustre 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'emploi, credSubmit est envoyé à l'étape suivante. L'élément otpCode est envoyé via SMS à l'appareil de l'utilisateur. Les informations d'identification indiquent à l'utilisateur quelle entrée est nécessaire pour transmettre la demande suivante.

Etape 4 : Soumettre les informations d'identification de facteur

Exemple de demande

L'exemple suivant présente le contenu de la demande POST au format JSON pour soumettre les informations 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 illustre 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 définie sur 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" (Inscription) permet à l'utilisateur de basculer vers un autre facteur pour s'inscrire à la récupération de compte. Dans cet exemple de cas d'emploi, createToken est envoyé à l'étape suivante.

Etape 5 : création du jeton d'authentification

Exemple de demande

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

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

Exemple de réponse

L'exemple suivant illustre 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 à plusieurs facteurs 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 à plusieurs facteurs.

Etape 6 : Définir SMS comme facteur d'authentification à plusieurs facteurs par défaut dans le chevauchement

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

Le client doit inclure les attributs suivants :

• authFactor : indique le facteur auquel s'inscrire pour l'authentification à plusieurs facteurs
• accountRecoveryFactor : lorsque la valeur est définie sur Vrai, indique que l'utilisateur souhaite réutiliser le facteur de récupération de compte déjà inscrit pour l'authentification à plusieurs facteurs.

Exemple de demande

L'exemple suivant illustre 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" (Inscription) permet à l'utilisateur d'inscrire un facteur supplémentaire pour l'authentification à plusieurs facteurs. Dans cet exemple de cas d'emploi, createToken est envoyé à l'étape suivante.

Etape 7 : création du jeton d'authentification

Exemple de demande

L'exemple suivant illustre 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

Etape 1 : activation du KMSI pour un domaine d'identité

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

tokenValidityInDays

Saisissez le nombre de jours pendant lesquels les utilisateurs peuvent rester connectés avant de se déconnecter automatiquement.

kmsiEnabled

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

maxAllowedSessions

Saisissez le nombre maximal de sessions de connexion 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"
}

Etape 2 : lancement du flux d'authentification

Obtenez le requestState initial pour démarrer le flux d'authentification.

Exemple de demande

L'exemple suivant illustre 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 KMSI. Si vous disposez d'une interface personnalisée, utilisez cet attribut pour afficher l'option Garder ma connexion sur la page de connexion.

Etape 3 : Soumettre les informations 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 le statut de la case à cocher (allumé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 à n'importe quelle application à l'avenir sans nécessiter qu'un utilisateur se reconnecte.

Etape 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 de nouveaux éléments authFactor, appName et kmsiToken envoyés dans la demande. SSO évalue la demande et renvoie authnToken et la dernière mise à jour kmsiToken dans la réponse. Il s'agit d'un élément kmsiToken actualisé qui remplace le jeton existant. Vous devez inclure cette version actualisée de kmsiToken dans la demande suivante.

Etape 5 : Soumettre les informations d'identification de l'utilisateur avec le flux KMSI et MFA

Lancez GET sur /sso/v1/sdk/authenticate à partir de l'Step 2 : Begin the Authentication Flow.

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 le périphérique, 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 élément kmsiToken actualisé.

Exemple de réponse

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

Etape 6 : Réémettre authnToken après l'expiration de la session lorsqu'un facteur d'authentification à plusieurs facteurs 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é à s'authentifier. 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 question de vérification d'authentification à plusieurs facteurs.

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é à saisir le mot de passe à usage unique sur le périphérique. Fournissez la charge utile ci-dessous avec le mot de passe à 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 cookie KMSI. Après l'expiration de la session, l'application envoie un appel d'autorisation au système d'identités avec les éléments redirectUrl, state, nonce, etc. Dans la réponse, le système d'identité renvoie la valeur requestState dans loginCtx. Ce requestState avec le jeton KMSI est 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

KMSI requiert l'ajout d'un nouvel attribut à l'adresse /sso/v1/sdk/secure/session. kmsiToken doit être envoyé à l'adresse à partir de l'application de connexion personnalisée.

Signature de charge utile 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 saisit son URL d'application, par exemple https://example.com/home/pages/profile.
2. Le système redirige vers l'appel de domaine d'identité /authorize.
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écrypté correspond à l'appel GET /sso/v1/sdk/authenticate.
6. La charge utile contient keepMeSignedInEnabled pour déterminer si KMSI est activé.
7. L'application de connexion personnalisée collecte les informations d'identification et les soumet au domaine d'identité.
8. Le domaine d'identité valide les informations d'identification et émet kmsiToken et authnToken.
9. L'application de connexion personnalisée utilise authnToken et kmsiToken lors de l'appel de l'adresse /sso/v1/sdk/secure/session. La nouvelle syntaxe de l'adresse sécurisée est décrite à la section Changes to /sso/v1/sdk/secure/session.
10. Le domaine d'identité valide authnToken, kmsiToken, puis le système d'identité émet le cookie de session SSO et le cookie KMSI.
11. Pendant la session, le cookie KMSI est validé pour étendre la session sans ressaisir les informations d'identification.