Uso de la API de autenticación para desarrollar una página de conexión personalizada

Paso 1: Inicio del flujo de autenticación

Un usuario abre una ventana del explorador para acceder a una página protegida.

Ejemplo de formulario HTML POST

A continuación se muestra un ejemplo de formulario HTML POST que los dominios de identidad devuelven para llamar a la página de conexión personalizada:

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

Ejemplo de lógica de descifrado para loginCtx cifrado en Java

A continuación, se muestra un ejemplo de lógica de descifrado:

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

Ejemplo de respuesta

La respuesta debe ser similar a la del siguiente ejemplo:

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

Los valores de estos atributos definen qué factor de autenticación, proveedores de identidad y proveedores sociales se presentan en la página de conexión. Aparece la página de conexión que contiene los valores descifrados del parámetro loginCtx junto con el token de acceso. La página de conexión incluye JavaScript que se utiliza para realizar llamadas AJAX a dominios de identidad.

Paso 2: Seleccionar un proveedor de identidad SAML

Ejemplo de código POST de formulario HTML para seleccionar 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");
};

Ejemplo de solicitud

A continuación, se muestra un ejemplo del contenido de la publicación de formularios en el punto final /sso/v1/sdk/secure/idp:

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

Ejemplo de respuesta

El siguiente ejemplo muestra el contenido de la respuesta en formato HTTP estándar:

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

Los dominios de identidad procesan la solicitud y redirigen el explorador al IdP externo seleccionado para la autenticación y autorización. Cuando finaliza el IdP externo, el explorador se redirige a los dominios de identidad. Los dominios de identidad validan la respuesta de afirmación y comprueban si se necesita autenticación adicional, como MFA.

Si no se requiere autenticación adicional, los dominios de identidad crean la sesión y redirigen el explorador a la URL de destino. O bien, los dominios de identidad crean una publicación de formulario de envío automático HTML en la página de conexión personalizada que contiene authnToken. A continuación, la página de conexión personalizada crea la sesión. Consulte Creación de Sesiones.

Paso 1: Inicio del flujo de autenticación

Un usuario abre una ventana del explorador para acceder a una página protegida.

Ejemplo de formulario HTML POST

A continuación se muestra un ejemplo de formulario HTML POST que los dominios de identidad devuelven para llamar a la página de conexión personalizada:

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

Ejemplo de lógica de descifrado para loginCtx cifrado en Java

A continuación, se muestra un ejemplo de lógica de descifrado:

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

Ejemplo de respuesta

La respuesta debe ser similar a la del siguiente ejemplo:

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

Los valores de estos atributos definen qué factor de autenticación, proveedores de identidad y proveedores sociales se presentan en la página de conexión. Aparece la página de conexión que contiene los valores descifrados del parámetro loginCtx junto con el token de acceso. La página de conexión incluye JavaScript que se utiliza para realizar llamadas AJAX a dominios de identidad.

Paso 2: Seleccionar Proveedor de Identidad Social

Ejemplo de código POST de formulario HTML para seleccionar un 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");
};

Ejemplo de solicitud

A continuación, se muestra un ejemplo del contenido de la publicación de formularios en el punto final /sso/v1/sdk/secure/idp:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato 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

Los dominios de identidad procesan la solicitud y redirigen el explorador al IdP social seleccionado para la autenticación y autorización. Cuando finaliza el IdP social, el explorador se redirige a los dominios de identidad. Los dominios de identidad validan la respuesta de afirmación y comprueban si se necesita autenticación adicional, como MFA.

Si no se requiere autenticación adicional, los dominios de identidad crean la sesión y redirigen el explorador a la URL de destino. O bien, los dominios de identidad crean una publicación de formulario de envío automático HTML en la página de conexión personalizada que contiene authnToken. A continuación, la página de conexión personalizada crea la sesión. Consulte Creación de Sesiones.

Paso 1: Inicio del flujo de autenticación

Un usuario abre una ventana del explorador para acceder a una página protegida.

Ejemplo de formulario HTML POST

A continuación se muestra un ejemplo de formulario HTML POST que los dominios de identidad devuelven para llamar a la página de conexión personalizada:

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

Ejemplo de lógica de descifrado para loginCtx cifrado en Java

A continuación, se muestra un ejemplo de lógica de descifrado:

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

Ejemplo de respuesta

La respuesta debe ser similar a la del siguiente ejemplo:

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

Los valores de estos atributos definen qué factor de autenticación, proveedores de identidad y proveedores sociales se presentan en la página de conexión. Aparece la página de conexión que contiene los valores descifrados del parámetro loginCtx junto con el token de acceso. La página de conexión incluye JavaScript que se utiliza para realizar llamadas AJAX a dominios de identidad.

Paso 2: Seleccionar un proveedor de identidad externo

Ejemplo de código POST de formulario HTML para seleccionar un IdP externo

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

Ejemplo de solicitud

A continuación, se muestra un ejemplo del contenido de la publicación de formularios en el punto final /sso/v1/sdk/secure/idp:

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

Ejemplo de respuesta

El siguiente ejemplo muestra el contenido de la respuesta en formato HTTP estándar:

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

Los dominios de identidad procesan la solicitud y redirigen el explorador al IdP externo seleccionado para la autenticación y autorización. Cuando finaliza el IdP externo, redirige el explorador a los dominios de identidad, que, a continuación, redirige el explorador para iniciar la verificación en 2 pasos.

Paso 3: Autenticación mediante el factor preferido (SMS)

Los pasos iniciales para iniciar la verificación en 2 pasos son similares al paso 1. Los dominios de identidad crean y envían un formulario HTML que contiene los parámetros loginCtx y signature cifrados. Consulte el paso 1 para obtener información detallada sobre el formulario POST y cómo descifrar.

Después de descifrar el parámetro loginCtx, la respuesta debe ser similar al siguiente ejemplo:

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

Los valores de estos atributos definen qué factor de autenticación (en este ejemplo es SMS) presentar en la página de conexión. El usuario introduce el código de acceso de un solo uso que recibe en su dispositivo.

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para completar la autenticación mediante el método preferido:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

A continuación, se debe crear una sesión. Una vez creada la sesión, el explorador se redirige a la URL solicitada originalmente. Consulte Creación de Sesiones.

Paso 1: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor nextOp indica lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se debe enviar en el siguiente paso. requestState contiene datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

Ejemplo de Respuesta de Error

En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando el nombre de usuario o la contraseña proporcionados no son válidos:

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

Paso 1: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor nextOp indica lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se debe enviar en el siguiente paso. requestState contiene datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario sin MFA)

Si el nombre de usuario y las contraseñas son válidos, el servidor responde con la sentencia TOU en la configuración regional especificada en el perfil del usuario. El servidor también solicita al usuario que proporcione su credencial de consentimiento en la siguiente solicitud. Si la sentencia TOU no está presente en la configuración regional del usuario fr, se muestra la respuesta 401 con el mensaje de error AUTH-3036: Terms of Use Statement for locale fr not added.

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para el punto final /sso/v1/sdk/authenticate:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando se agrega la configuración regional del usuario:

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

Ejemplo de Respuesta de Error

En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando no se agrega el TOU para la configuración regional del usuario:

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

Paso 3: Proporcionar el consentimiento de discriminación horaria

En este caso, el usuario acepta o rechaza las condiciones de uso de la aplicación. Si el usuario acepta las Condiciones de uso, se le redirige a la página de la aplicación.

Si el usuario rechaza las condiciones de uso, se muestra la respuesta 401 con el mensaje de error AUTH-3035: Debe aceptar las condiciones de uso para acceder a esta aplicación.

Ejemplo de solicitud

El siguiente ejemplo muestra el contenido de la solicitud en formato JSON cuando el usuario acepta TOU.

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

Ejemplo de solicitud

El siguiente ejemplo muestra el contenido de la solicitud en formato JSON cuando el usuario rechaza el TOU.

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando el usuario acepta la sentencia TOU.

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

Ejemplo de Respuesta de Error

A continuación se muestra el contenido de la respuesta en formato JSON cuando el usuario rechaza la discriminación horaria.

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

Los dominios de identidad se pueden configurar para enviar un código de acceso de un solo uso (OTP) basado en tiempo directamente a un usuario para la autenticación o para que el código de acceso se cifre y se envíe al cliente consumidor, que podrá enviarlo al usuario para la autenticación.

Por ejemplo, los administradores pueden configurar dominios de identidad para enviar códigos de contraseña de un solo uso (OTP) basados en tiempo a la aplicación Oracle Mobile Authenticator (OMA) o enviar por correo electrónico las OTP a la dirección de correo electrónico principal del usuario. En ambos casos, los dominios de identidad generan la OTP, la envían directamente al usuario y el usuario introduce el código para la autenticación. Para comprender cómo definir estas opciones mediante REST, consulte Inscripción de factor de autenticación con verificación de factor - SMS y Inscripción de factor de autenticación con verificación de factor - Correo electrónico.

Cifrado y descifrado

Esta implementación utiliza la siguiente especificación para cifrar y descifrar el código OTP recibido. Consulte PKCS #1: RSA Cryptography Specifications, Version 2.0, section 7.1 RSAES-OAEP.

Código de descifrado de OTP

/*
 * 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();
            }
    }
    
}

Paso 1: Crear una aplicación CustomUI

Consulte Agregar aplicaciones para obtener más información sobre las aplicaciones personalizadas.

Paso 2: Generar un par de claves para un certificado autofirmado

Paso 3: Configuración de la aplicación para devolver la OTP en la respuesta

Paso 4: Solicitar la OTP

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

Ejemplo de respuesta

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

Paso 1: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor nextOp indica lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se debe enviar en el siguiente paso. requestState contiene datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario

AuthnToken es el id_token en formato JWT que representa la información de usuario actual, la sesión y los datos de solicitud. Se utiliza para crear una cookie de sesión SSO y redirigir a la URL de destino. Si el nombre de usuario y la contraseña son válidos, se recupera AuthnToken.

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para el punto final /sso/v1/sdk/authenticate:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON donde se recupera AuthnToken:

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

Paso 3: Generar el token de acceso

Después de recuperar un AuthnToken, se utiliza para obtener el token de acceso del servidor OAuth.

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

Paso 4: Obtener información del usuario

El usuario envía el token de acceso para obtener su información, como nombre de usuario, nombre mostrado, ID de correo electrónico, etc.

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON.

{{HOST}}/admin/v1/Me

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON con información de usuario.

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

Paso 1: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor nextOp indica lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se debe enviar en el siguiente paso. requestState contiene datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON, ya que las notificaciones PUSH son el factor preferido:

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

En la respuesta, el estado es pending, ya que el usuario debe permitir o denegar la notificación PUSH en su dispositivo. Los valores nextOp de la respuesta indican lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se envía en el siguiente paso.

Paso 3: Autenticación mediante el factor preferido

Autenticar mediante el factor preferido, que en este ejemplo de caso de uso es Notificaciones PUSH. El cliente debe incluir los siguientes atributos en esta solicitud:

• op: indica al servidor qué tipo de operación desea el cliente

• requestState: recibido en la respuesta del paso 2

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para completar la autenticación mediante el método preferido:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

Paso 1: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor nextOp indica lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se debe enviar en el siguiente paso. requestState contiene datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato 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"
}

En este ejemplo de caso de uso, dado que la MFA se define como opcional en la política de conexión (indicada por el valor false para el atributo enrollmentRequired), al usuario se le da la opción de inscribirse u omitir la inscripción. Si se necesita MFA, el único valor nextOp sería enrollment.

En este ejemplo de caso de uso, enrollment se envía en el siguiente paso para iniciar la inscripción de factor de MFA para el usuario. Tenga en cuenta que BYPASSCODE falta como valor nextAuthFactors, ya que el usuario no puede inscribirse mediante un código de bypass. El código de bypass debe ser generado por el usuario mediante Mi perfil o solicitando que un administrador genere uno para ellos.

Paso 3: Iniciar inscripción de autenticación de segundo factor

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato 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"
}

Paso 4: Enviar credenciales de factor

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para enviar las credenciales de factor:

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

Ejemplo de respuesta

El estado success aparece en la respuesta cuando se completa la comunicación de canal secundario de la aplicación OMA al servidor y la verificación optCode se realiza correctamente. En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, los valores nextOp indican lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, createToken se envía en el siguiente paso.

Ejemplo de respuesta pendiente

El estado pending aparece cuando no se completa la comunicación de canal secundario de la aplicación de OMA al servidor. El cliente sigue sondeando cada 10 segundos y sigue sondeando durante dos minutos. Después de dos minutos, el servidor envía el estado de fallo si la verificación otpCode no se realiza correctamente.

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

Paso 5: Creación del token de autenticación

Este paso indica que el cliente ha terminado con todo authnFactors y necesita una sesión creada. El servidor valida que no se necesita ninguna otra evaluación de factores (según lo definido para la política) y responde con el token o deniega el acceso. El cliente debe incluir los siguientes atributos:

• op: indica al servidor qué tipo de operación desea el cliente

• requestState: recibido en la respuesta del paso 4

Ejemplo de solicitud

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

Paso 1: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor nextOp indica lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se debe enviar en el siguiente paso. requestState contiene datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato 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"
}

En este ejemplo de caso de uso, el usuario debe inscribirse en la recuperación de cuentas (indicada por un valor true para el atributo accRecEnrollmentRequired:true). nextAuthFactors indica los factores en los que el usuario puede inscribirse para la recuperación de cuenta.

En este ejemplo de caso de uso, la inscripción se envía en el siguiente paso para iniciar la inscripción de recuperación de cuenta para el usuario.

Paso 3: Iniciar inscripción de recuperación de cuenta

Este paso inicia la inscripción por SMS. El cliente debe incluir los siguientes atributos:

• op: indica al servidor qué tipo de operación desea el cliente
• authFactor: define el factor de autenticación en el que el usuario desea inscribirse
• phoneNumber: define el número de teléfono al que se enviará el texto SMS
• countryCode: define el código de país del número de teléfono al que se enviará el texto SMS
• requestState: recibido en la respuesta del paso 2

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON:

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

En la respuesta, los valores nextOp indican lo que se puede enviar como valor de operación en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se envía en el siguiente paso. otpCode se envía mediante SMS al dispositivo del usuario.

Paso 4: Enviar credenciales de factor

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para enviar las credenciales de factor:

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

Ejemplo de respuesta

El estado correcto aparece en la respuesta cuando la verificación optCode se realiza correctamente. En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor accRecEnrollmentRequired se define en false porque la inscripción en la cuenta se ha realizado correctamente. Los valores nextOp indican lo que se puede enviar como valor op en la siguiente solicitud. El valor nextOp "enrollment" permite al usuario cambiar a otro factor para inscribirse en la recuperación de cuenta. En este ejemplo de caso de uso, createToken se envía en el siguiente paso.

Paso 5: Creación del token de autenticación

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

Paso 1: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor nextOp indica lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se debe enviar en el siguiente paso. requestState contiene datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato 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"
}

En este ejemplo de caso de uso, el usuario debe inscribirse en la recuperación de cuentas (indicada por un valor true para el atributo accRecEnrollmentRequired:true). nextAuthFactors indica los factores en los que el usuario puede inscribirse para la recuperación de cuenta.

En este ejemplo de caso de uso, la inscripción se envía en el siguiente paso para iniciar la inscripción de recuperación de cuenta para el usuario.

Paso 3: Iniciar inscripción de recuperación de cuenta

Este paso inicia la inscripción por SMS. El cliente debe incluir los siguientes atributos:

• op: indica al servidor qué tipo de operación desea el cliente
• authFactor: define el factor de autenticación en el que el usuario desea inscribirse
• phoneNumber: define el número de teléfono al que se enviará el texto SMS
• countryCode: define el código de país del número de teléfono al que se enviará el texto SMS
• requestState: recibido en la respuesta del paso 2

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON:

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

En la respuesta, los valores nextOp indican lo que se puede enviar como valor de operación en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit se envía en el siguiente paso. otpCode se envía mediante SMS al dispositivo del usuario. Las credenciales indican al usuario qué entrada se necesita transferir en la siguiente solicitud.

Paso 4: Enviar credenciales de factor

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para enviar las credenciales de factor:

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

Ejemplo de respuesta

El estado correcto aparece en la respuesta cuando la verificación optCode se realiza correctamente. En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:

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

En la respuesta, el valor accRecEnrollmentRequired se define en false porque la inscripción en la cuenta se ha realizado correctamente. Los valores nextOp indican lo que se puede enviar como valor op en la siguiente solicitud. El valor nextOp "enrollment" permite al usuario cambiar a otro factor para inscribirse en la recuperación de cuenta. En este ejemplo de caso de uso, createToken se envía en el siguiente paso.

Paso 5: Creación del token de autenticación

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta con formato 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"
}

En la respuesta, como se necesita MFA, enrollmentRequired tiene el valor true en mfaSettings. Como resultado, no se emite ningún token. EnrolledAccountRecoveryFactorsDetails muestra los factores de recuperación de cuenta en los que se ha inscrito el usuario. Los valores nextOp indican lo que se puede enviar como valor op en la siguiente solicitud. En este ejemplo, el valor nextOp "enrollment" indica que el usuario se debe inscribir en MFA.

Paso 6: Establecer SMS como factor de MFA predeterminado en solapamiento

Este paso indica que el cliente debe inscribirse en MFA.

El cliente debe incluir los siguientes atributos:

• authFactor: indica en qué factor inscribirse para MFA
• accountRecoveryFactor: si se define en true, indica que el usuario desea reutilizar el factor de recuperación de cuenta ya inscrito para MFA.

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:

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

Ejemplo de respuesta

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

En la respuesta, los valores nextOp indican lo que se puede enviar como valor de operación en la siguiente solicitud. El valor nextOp "enrollment" permite al usuario inscribir un factor adicional para MFA. En este ejemplo de caso de uso, createToken se envía en el siguiente paso.

Paso 7: Creación del token de autenticación

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:

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

Ejemplo de respuesta

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

Antes de empezar

Paso 1: Activar KMSI para un dominio de identidad

1. Obtenga el token de acceso de administrador del dominio de identidad para su cuenta.
2. Ejecute GET en el punto final /admin/v1/KmsiSettings/KmsiSettings. El sistema devuelve KmsiSettings.
3. Actualice los atributos necesarios y ejecute PUT en el punto final /admin/v1/KmsiSettings/KmsiSettings.

tokenValidityInDays

Introduzca el número de días que los usuarios pueden permanecer conectados antes de que se desconecten automáticamente.

kmsiEnabled

Indica si KMSI está activado para el dominio de identidad.

maxAllowedSessions

Introduzca el número máximo de sesiones conectadas que puede tener un usuario.

Solicitud de ejemplo

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

Paso 2: Inicio del flujo de autenticación

Obtenga el requestState inicial para iniciar el flujo de autenticación.

Ejemplo de solicitud

En el siguiente ejemplo se muestra la solicitud con formato cURL:

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

Ejemplo de respuesta

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

Observe el nuevo atributo keepMeSignedInEnabled incluido en la respuesta. Esto indica que este dominio de identidad y esta aplicación admiten KMSI. Si tiene una interfaz personalizada, utilice este atributo para mostrar la opción Mantenerme conectado en la página de conexión.

Paso 3: Enviar las credenciales del usuario con KMSI

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

Si tiene una interfaz personalizada, use este atributo para mostrar la opción KMSI, marque el estado de la casilla de control (activada o desactivada) y envíe este parámetro para crear la sesión KMSI.

Ejemplo de respuesta

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

En el ejemplo de respuesta, observe el atributo kmsiToken. Este token se puede utilizar para acceder a cualquier aplicación en el futuro sin necesidad de que un usuario vuelva a conectarse.

Paso 4: Vuelva a emitir authnToken después de la caducidad de la sesión

Ejemplo de solicitud

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

Ejemplo de respuesta

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

Observe la operación credSubmit con un nuevo authFactor, appName y kmsiToken que se envían en la solicitud. SSO evalúa la solicitud y devuelve authnToken y la última kmsiToken actualizada en la respuesta. Se trata de un kmsiToken refrescado y sustituye al token existente. Debe incluir este kmsiToken refrescado en la siguiente solicitud.

Paso 5: Enviar credenciales de usuario con flujo de KMSI y MFA

Inicie GET en /sso/v1/sdk/authenticate desde el Paso 2: Inicio del flujo de autenticación.

Ejemplo de respuesta

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

Ejemplo de respuesta

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

Después de obtener el código de acceso de un solo uso (OTP) en el dispositivo, agregue la OTP en la solicitud.

Ejemplo de solicitud

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

La respuesta incluye authToken y kmsiToken. Se trata de un kmsiToken refrescado.

Ejemplo de respuesta

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

Paso 6: Vuelva a emitir authnToken después de la caducidad de la sesión cuando se defina un factor de MFA

Cuando un usuario intenta conectarse mediante kmsiToken y hay un segundo factor configurado, siempre se le solicita al usuario la autenticación del segundo factor. Solo después de una autenticación correcta, se enviarán authnToken y kmsiToken en la respuesta.

Ejemplo de solicitud

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

La respuesta contiene un token de KMSI refrescado y una comprobación de MFA.

Ejemplo de respuesta

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

Repita el mismo proceso en el que se le pedirá de nuevo la OTP en el dispositivo. Proporcione la siguiente carga útil con la OTP. La respuesta debe incluir authnToken.

Ejemplo de solicitud

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

Ejemplo de respuesta

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

Flujo kmsiToken con requestState

Utilice este flujo para soportar el contexto del explorador cuando posea el token KMSI, pero no la cookie KMSI. Después de la caducidad de la sesión, la aplicación realiza una llamada de autorización al sistema de identidad con redirectUrl, state, nonce, etc. En la respuesta, el sistema de identidad devuelve requestState dentro de loginCtx. Este requestState junto con el token KMSI se transfiere para redirigir la aplicación necesaria después de ampliar la sesión.

Ejemplo de solicitud

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

Ejemplo de respuesta

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

Cambios en /sso/v1/sdk/secure/session

KMSI necesita que se agregue un nuevo atributo al punto final /sso/v1/sdk/secure/session. kmsiToken se debe enviar al punto final desde la aplicación de conexión personalizada.

Firma de carga útil para llamadas iniciadas de /authorize

1. Cuando un usuario accede a cualquier aplicación web protegida por dominios de identidad, introduce su URL de aplicación, por ejemplo, https://example.com/home/pages/profile.
2. El sistema redirige a la llamada /authorize del dominio de identidad.
3. El dominio de identidad redirige al usuario a la página de conexión personalizada desplegada por el cliente.
4. La aplicación de conexión alojada por el cliente recopila los parámetros de entrada y decodifica la entrada loginCtx.
5. El parámetro de entrada descifrado coincide con la llamada GET /sso/v1/sdk/authenticate.
6. La carga útil contiene keepMeSignedInEnabled para identificar si KMSI está activado.
7. La aplicación de conexión personalizada recopila las credenciales y las envía al dominio de identidad.
8. El dominio de identidad valida las credenciales y emite kmsiToken y authnToken.
9. La aplicación de conexión personalizada utiliza authnToken y kmsiToken al realizar la llamada al punto final /sso/v1/sdk/secure/session. La nueva sintaxis del punto final seguro se describe en Changes to /sso/v1/sdk/secure/session.
10. El dominio de identidad valida authnToken, kmsiToken y, a continuación, el sistema de identidad emite la cookie de sesión SSO y la cookie KMSI.
11. Durante la sesión, la cookie KMSI se valida para ampliar la sesión sin volver a introducir las credenciales.