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 POST de formulaire HTML 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 devrait ê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 qui apparaît contient les valeurs décryptées du paramètre loginCtx ainsi que le jeton d'accès. La page de connexion inclut JavaScript qui est utilisé pour effectuer des appels AJAX vers des domaines d'identité.

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

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

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

Exemple de demande

Voici un exemple du contenu de 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 l'élément IdP externe sélectionné pour authentification et autorisation. Une fois le fichier IdP externe 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 un POST FORMULAIRE de soumission automatique HTML vers la page de connexion personnalisée qui contient authnToken. La page de connexion personnalisée crée ensuite la session. Reportez-vous à Création d'une 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 POST de formulaire HTML 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 devrait ê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 qui apparaît contient les valeurs décryptées du paramètre loginCtx ainsi que le jeton d'accès. La page de connexion inclut JavaScript qui est utilisé pour effectuer des appels AJAX vers des domaines d'identité.

Etape 2 : sélectionnez 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 montre le contenu de la réponse au format JSON :

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

Les domaines d'identité traitent la demande et redirigent le navigateur vers le réseau social IdP sélectionné pour authentification et autorisation. Une fois l'élément de réseau social IdP 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 un POST FORMULAIRE de soumission automatique HTML vers la page de connexion personnalisée qui contient authnToken. La page de connexion personnalisée crée ensuite la session. Reportez-vous à Création d'une 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 POST de formulaire HTML 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 devrait ê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 qui apparaît contient les valeurs décryptées du paramètre loginCtx ainsi que le jeton d'accès. La page de connexion inclut JavaScript qui est utilisé pour effectuer des appels AJAX 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 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 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 l'élément IdP externe sélectionné pour authentification et autorisation. Une fois l'élément IdP externe terminé, il redirige le navigateur vers des domaines d'identité, qui redirige ensuite le navigateur vers le début de la vérification en 2 étapes.

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

Les étapes initiales de début de la vérification en 2 étapes sont similaires à l'étape 1. Les domaines d'identité créent et soumettent un formulaire HTML qui contient les paramètres cryptés loginCtx et signature. Reportez-vous à l'étape 1 pour obtenir des informations détaillées sur le formulaire POST et sur la façon de 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 montre le contenu de la demande POST au format JSON pour terminer l'authentification à l'aide de la méthode préférée :

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

Exemple de réponse

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

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

Une session doit alors être créée. Une fois la session créée, le navigateur est redirigé vers l'URL initialement demandée. Reportez-vous à Création d'une 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 montre 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'emploi, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : soumission des 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 :

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

Etape 1 : lancement du flux d'authentification

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

Exemple de demande

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

Etape 2 : soumission des 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 linguistique 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 les paramètres régionaux de l'utilisateur fr, la réponse 401 avec le message d'erreur AUTH-3036 : L'instruction Conditions d'utilisation pour les paramètres régionaux 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 lorsque les paramètres régionaux de l'utilisateur sont ajoutés :

{
  "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 des 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 le 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 illustre 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

Les éléments suivants indiquent 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 (OTP) basé sur le temps 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 ponctuels basés sur le temps à l'application Oracle Mobile Authenticator (OMA) ou envoyer les mots de passe à l'adresse électronique principale de l'utilisateur par courriel. 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 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 implémentation utilise la spécification suivante pour chiffrer et déchiffrer le code OTP reçu. Reportez-vous à PKCS n° 1 : spécifications de cryptographie RSA, 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 : demande du 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 montre 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'emploi, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : soumission des 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 montre le contenu de la réponse au format JSON dans lequel l'élément 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 un 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
}

Etape 4 : Obtention des informations utilisateur

L'utilisateur soumet le jeton d'accès pour obtenir des informations telles que le nom d'utilisateur, le nom d'affichage, l'ID d'adresse électronique, 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 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 montre 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'emploi, credSubmit doit être envoyé à l'étape suivante. requestState contient les données contextuelles nécessaires au traitement de la demande.

Etape 2 : soumission des 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 les notifications PUSH sont 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 périphérique. 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'emploi, credSubmit est envoyé à l'étape suivante.

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

Authentifiez-vous en utilisant le facteur préféré, qui dans cet exemple d'utilisation 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 d'étape 2

Exemple de demande

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

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

Exemple de réponse

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

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

Etape 1 : lancement du flux d'authentification

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

Exemple de demande

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

Etape 2 : soumission des 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 :

{
    "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, é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 peut choisir de s'inscrire ou d'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 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"
}

Etape 4 : Soumettre les informations d'identification du facteur

Exemple de demande

L'exemple suivant montre 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 à la communication du canal arrière du serveur est terminée et que la vérification optCode réussit. 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'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 a 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 d'é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"
}

Etape 1 : lancement du flux d'authentification

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

Exemple de demande

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

Etape 2 : soumission des 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 :

{
    "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 de récupération de compte pour l'utilisateur.

Etape 3 : Lancer l'inscription à la récupération du 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 souhaite s'inscrire.
• phoneNumber : définit le numéro de téléphone où le texte du SMS sera envoyé
• countryCode : définit l'indicatif du pays du numéro de téléphone où le SMS sera envoyé
• 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 :

{  
   "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'emploi, credSubmit est envoyé à l'étape suivante. Le message otpCode est envoyé par SMS à l'appareil de l'utilisateur.

Etape 4 : Soumettre les informations d'identification du facteur

Exemple de demande

L'exemple suivant montre 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 a réussi. 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 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 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"
}

Etape 1 : lancement du flux d'authentification

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

Exemple de demande

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

Etape 2 : soumission des 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 :

{
    "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 de récupération de compte pour l'utilisateur.

Etape 3 : Lancer l'inscription à la récupération du 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 souhaite s'inscrire.
• phoneNumber : définit le numéro de téléphone où le texte du SMS sera envoyé
• countryCode : définit l'indicatif du pays du numéro de téléphone où le SMS sera envoyé
• 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 :

{  
   "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'emploi, credSubmit est envoyé à l'étape suivante. Le message otpCode est envoyé par 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 du facteur

Exemple de demande

L'exemple suivant montre 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 a réussi. 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 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 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 à plusieurs facteurs est requise, enrollmentRequired a la valeur true sous mfaSettings. Par conséquent, aucun jeton n'est émis. EnrolledAccountRecoveryFactorsDetails indique 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 le facteur d'authentification à plusieurs facteurs par défaut pour SMS 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 : lorsqu'elle est définie sur True, indique que l'utilisateur veut réutiliser le facteur de récupération de compte déjà inscrit pour l'authentification à plusieurs facteurs.

Exemple de demande

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

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

Exemple de réponse

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

Dans la réponse, les valeurs nextOp indiquent ce qui peut être envoyé en tant que valeur d'opération dans la demande suivante. La valeur nextOp "enrollment" (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 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

Etape 1 : activation de 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 la valeur 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

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

Exemple de requête

{
    "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 montre 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 Conserver ma connexion sur la page de connexion.

Etape 3 : soumission des 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 (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 qu'un utilisateur ne 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 les 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 valeur kmsiToken actualisée dans la demande suivante.

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

Lancez GET sur /sso/v1/sdk/authenticate à l'étape 2 : lancement du 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 mot de passe à 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é à authentifier le deuxième facteur. Ce n'est qu'après l'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 MFA.

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

kmsiToken Flux 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 effectue un appel d'autorisation vers le système d'identité avec les éléments redirectUrl, state, nonce, etc. Dans la réponse, le système d'identité renvoie requestState à l'intérieur de loginCtx. Ce jeton requestState et le jeton KMSI sont transmis pour rediriger l'application requise après l'extension de la session.

Exemple de demande

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

Exemple de réponse

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

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

KMSI exige qu'un nouvel attribut soit ajouté à 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échiffré correspond à l'appel GET /sso/v1/sdk/authenticate.
6. La charge utile contient keepMeSignedInEnabled pour identifier 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 les messages 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 dans Modifications apportées à /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 prolonger la session sans ressaisir les informations d'identification.