Uso de la API de Autenticación para Desarrollar una Página de Conexión Personalizada

Paso 1: Iniciar el flujo de autenticación

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

Ejemplo de POST de formulario HTML

A continuación se muestra un ejemplo de POST de formulario HTML 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 al 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 de SAML

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

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

Ejemplo de solicitud

A continuación se muestra un ejemplo del contenido de FORM POST 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 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 un FORM POST de envío automático HTML a 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 una Sesión.

Paso 1: Iniciar el flujo de autenticación

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

Ejemplo de POST de formulario HTML

A continuación se muestra un ejemplo de POST de formulario HTML 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 al 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 social

Ejemplo de código POST de formulario HTML para seleccionar una red 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 FORM POST 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 en 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 a la red social IdP seleccionada para autenticación y autorización. Cuando finaliza la 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 un FORM POST de envío automático HTML a 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 una Sesión.

Paso 1: Iniciar el flujo de autenticación

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

Ejemplo de POST de formulario HTML

A continuación se muestra un ejemplo de POST de formulario HTML 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 al 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 FORM POST 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 autenticación y autorización. Cuando finaliza el IdP externo, redirige el explorador a dominios de identidad, que luego redirige al explorador para que comience la verificación en 2 pasos.

Paso 3: Autenticar 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 cifrados loginCtx y signature. 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) se debe 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 en formato JSON:

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

A continuación, se debe crear una sesión. Después de crear la sesión, el explorador se redirige a la URL solicitada originalmente. Consulte Creación de una Sesión.

Paso 1: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 en 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, se debe enviar credSubmit en el siguiente paso. requestState contiene los 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:

{
    "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: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 en 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, se debe enviar credSubmit en el siguiente paso. requestState contiene los 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 fr del usuario, se muestra la respuesta 401 con el mensaje de error AUTH-3036 : Terms of Use Statement for locale fr is 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

El siguiente ejemplo 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 la 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 TOU

En este escenario, el usuario acepta o rechaza las Condiciones de uso para la aplicación. Si el usuario acepta las Condiciones de uso, se redirige al usuario 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

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

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

Ejemplo de respuesta

El siguiente ejemplo 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 TOU.

{
    "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 basado en tiempo (OTP) directamente a un usuario para la autenticación o para que el código de acceso esté cifrado y se envíe al cliente consumidor, que luego puede enviarlo al usuario para la autenticación.

Por ejemplo, los administradores pueden configurar dominios de identidad para enviar códigos de acceso de un solo uso basados en tiempo (OTP) 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ía directamente al usuario y el usuario introduce el código para la autenticación. Para comprender cómo definir estas opciones mediante REST, consulte Autentication Factor Enrollment With Factor Verification-SMS y Authentication Factor Enrollment With Factor Verification-Email.

Cifrado y descifración

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: Generación de un par de claves para un certificado autofirmados

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: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 en 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, se debe enviar credSubmit en el siguiente paso. requestState contiene los datos contextuales necesarios para procesar la solicitud.

Paso 2: Enviar las credenciales del usuario

AuthnToken es el valor 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 de 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 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 en 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 en 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 el nombre de usuario, el nombre mostrado, el ID de correo electrónico, etc.

Ejemplo de solicitud

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

{{HOST}}/admin/v1/Me

Ejemplo de respuesta

En el siguiente ejemplo, se muestra el contenido de la respuesta en 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: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 en 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, se debe enviar credSubmit en el siguiente paso. requestState contiene los 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 de 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: Autenticar con el factor preferido

Autenticar utilizando 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 en formato JSON:

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

Paso 1: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 en 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, se debe enviar credSubmit en el siguiente paso. requestState contiene los 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:

{
    "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 un valor de false para el atributo enrollmentRequired), el usuario tiene 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 del 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 usuario debe generar el código de bypass mediante Mi perfil o solicitando que un administrador genere uno para ellos.

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

Ejemplo de solicitud

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

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta en 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 de optCode se realiza correctamente. En el siguiente ejemplo se muestra el contenido de la respuesta en 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 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: Crear el token de autenticación

Este paso indica que el cliente se ha realizado con todo authnFactors y necesita que se cree una sesión. 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 en formato JSON:

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

Paso 1: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 en 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, se debe enviar credSubmit en el siguiente paso. requestState contiene los 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:

{
    "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 (indicado por un valor de true para el atributo accRecEnrollmentRequired:true). nextAuthFactors indica los factores en los que el usuario puede inscribirse para la recuperación de cuentas.

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 cuentas 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 en qué factor de autenticación desea inscribirse el usuario
• 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 en 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 en 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. El 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 en 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 a medida que la inscripción en la cuenta se realiza 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 la cuenta. En este ejemplo de caso de uso, createToken se envía en el siguiente paso.

Paso 5: Crear el token de autenticación

Ejemplo de solicitud

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

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

Ejemplo de respuesta

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

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

Paso 1: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 en 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, se debe enviar credSubmit en el siguiente paso. requestState contiene los 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:

{
    "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 (indicado por un valor de true para el atributo accRecEnrollmentRequired:true). nextAuthFactors indica los factores en los que el usuario puede inscribirse para la recuperación de cuentas.

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 cuentas 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 en qué factor de autenticación desea inscribirse el usuario
• 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 en 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 en 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. El otpCode se envía mediante SMS al dispositivo del usuario. Las credenciales indican al usuario qué entrada se necesita para pasar 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 en 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 a medida que la inscripción en la cuenta se realiza 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 la cuenta. En este ejemplo de caso de uso, createToken se envía en el siguiente paso.

Paso 5: Crear el token de autenticación

Ejemplo de solicitud

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

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

Ejemplo de respuesta

En el siguiente ejemplo se muestra el contenido de la respuesta en 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 requiere MFA, enrollmentRequired tiene un valor de 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 inscribirá en MFA.

Paso 6: Definir SMS como factor de MFA por defecto 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: cuando 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 en 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 la MFA. En este ejemplo de caso de uso, createToken se envía en el siguiente paso.

Paso 7: Crear el token de autenticación

Ejemplo de solicitud

En el siguiente ejemplo se muestra el contenido de la solicitud POST en 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 cuántos días 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: Iniciar el flujo de autenticación

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

Ejemplo de solicitud

El siguiente ejemplo muestra la solicitud en 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 esta aplicación y dominio de identidad 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, utilice 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: Volver 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ía en la solicitud. SSO evalúa la solicitud y devuelve authnToken y la última actualización de kmsiToken en la respuesta. Se trata de un kmsiToken refrescado y sustituye el 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: Iniciar el 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 el 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: Volver a emitir authnToken después de la caducidad de la sesión cuando se define 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 la 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 KMSI actualizado 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 solicitará nuevamente la OTP en el dispositivo. Proporcione la siguiente carga útil con el 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 admitir 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 token 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 /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 descodifica 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 Cambios en /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.