Benutzerdefinierte Anmeldeseite mit der Authentifizierungs-API entwickeln

Schritt 1: Authentifizierungsablauf starten

Ein Benutzer öffnet ein Browserfenster, um auf eine geschützte Seite zuzugreifen.

Beispiel-HTML-Formular POST

Im Folgenden finden Sie ein Beispiel-HTML-Formular POST, das Identitätsdomains zurückgibt, um die benutzerdefinierte Anmeldeseite aufzurufen:

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

Beispiel für Entschlüsselungslogik für verschlüsselte loginCtx in Java

Im Folgenden finden Sie Beispielentschlüsselungslogik:

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

Antwortbeispiel

Die Antwort sollte dem folgenden Beispiel ähneln:

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

Die Werte dieser Attribute definieren, welcher Authentifizierungsfaktor, welche Identitätsprovider und welche Social-Provider auf der Anmeldeseite angezeigt werden. Die Anmeldeseite wird angezeigt, die entschlüsselte Werte des Parameters loginCtx zusammen mit dem Zugriffstoken enthält. Die Anmeldeseite enthält JavaScript, mit dem AJAX-Aufrufe an Identitätsdomains ausgeführt werden.

Schritt 2: SAML-Identitätsprovider auswählen

Beispiel-HTML-Formular-POST-Code zum Auswählen einer 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");
};

Anforderungsbeispiel

Im Folgenden finden Sie ein Beispiel für den Inhalt des FORM POST für den Endpunkt /sso/v1/sdk/secure/idp:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im HTTP-Standardformat:

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

Identitätsdomains verarbeiten die Anforderung und leiten den Browser zur Authentifizierung und Autorisierung an die ausgewählte externe IdP weiter. Wenn die externe IdP abgeschlossen ist, wird der Browser zu Identitätsdomains umgeleitet. Identitätsdomains validieren die Assertion-Antwort und prüfen, ob zusätzliche Authentifizierung wie MFA erforderlich ist.

Wenn keine zusätzliche Authentifizierung erforderlich ist, erstellt Identitätsdomains die Session und leitet den Browser zur Ziel-URL um. Identitätsdomains erstellen auch einen HTML-Code zur automatischen Weiterleitung von FORM POST an die benutzerdefinierte Anmeldeseite, die authnToken enthält. Die benutzerdefinierte Anmeldeseite erstellt dann die Session. Siehe Session erstellen.

Schritt 1: Authentifizierungsablauf starten

Ein Benutzer öffnet ein Browserfenster, um auf eine geschützte Seite zuzugreifen.

Beispiel-HTML-Formular POST

Im Folgenden finden Sie ein Beispiel-HTML-Formular POST, das Identitätsdomains zurückgibt, um die benutzerdefinierte Anmeldeseite aufzurufen:

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

Beispiel für Entschlüsselungslogik für verschlüsselte loginCtx in Java

Im Folgenden finden Sie Beispielentschlüsselungslogik:

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

Antwortbeispiel

Die Antwort sollte dem folgenden Beispiel ähneln:

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

Die Werte dieser Attribute definieren, welcher Authentifizierungsfaktor, welche Identitätsprovider und welche Social-Provider auf der Anmeldeseite angezeigt werden. Die Anmeldeseite wird angezeigt, die entschlüsselte Werte des Parameters loginCtx zusammen mit dem Zugriffstoken enthält. Die Anmeldeseite enthält JavaScript, mit dem AJAX-Aufrufe an Identitätsdomains ausgeführt werden.

Schritt 2: Sozialen Identitätsprovider auswählen

Beispiel-HTML-Formular-POST-Code zum Auswählen einer 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");
};

Anforderungsbeispiel

Im Folgenden finden Sie ein Beispiel für den Inhalt des FORM POST für den Endpunkt /sso/v1/sdk/secure/idp:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Identitätsdomains verarbeiten die Anforderung und leiten den Browser zur Authentifizierung und Autorisierung an die ausgewählte soziale IdP weiter. Wenn die soziale IdP abgeschlossen ist, wird der Browser zu Identitätsdomains umgeleitet. Identitätsdomains validieren die Assertion-Antwort und prüfen, ob zusätzliche Authentifizierung wie MFA erforderlich ist.

Wenn keine zusätzliche Authentifizierung erforderlich ist, erstellt Identitätsdomains die Session und leitet den Browser zur Ziel-URL um. Identitätsdomains erstellen auch einen HTML-Code zur automatischen Weiterleitung von FORM POST an die benutzerdefinierte Anmeldeseite, die authnToken enthält. Die benutzerdefinierte Anmeldeseite erstellt dann die Session. Siehe Session erstellen.

Schritt 1: Authentifizierungsablauf starten

Ein Benutzer öffnet ein Browserfenster, um auf eine geschützte Seite zuzugreifen.

Beispiel-HTML-Formular POST

Im Folgenden finden Sie ein Beispiel-HTML-Formular POST, das Identitätsdomains zurückgibt, um die benutzerdefinierte Anmeldeseite aufzurufen:

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

Beispiel für Entschlüsselungslogik für verschlüsselte loginCtx in Java

Im Folgenden finden Sie Beispielentschlüsselungslogik:

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

Antwortbeispiel

Die Antwort sollte dem folgenden Beispiel ähneln:

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

Die Werte dieser Attribute definieren, welcher Authentifizierungsfaktor, welche Identitätsprovider und welche Social-Provider auf der Anmeldeseite angezeigt werden. Die Anmeldeseite wird angezeigt, die entschlüsselte Werte des Parameters loginCtx zusammen mit dem Zugriffstoken enthält. Die Anmeldeseite enthält JavaScript, mit dem AJAX-Aufrufe an Identitätsdomains ausgeführt werden.

Schritt 2: Externen Identitätsprovider auswählen

Beispiel-HTML-Formular-POST-Code zum Auswählen einer externen 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");
};

Anforderungsbeispiel

Im Folgenden finden Sie ein Beispiel für den Inhalt des FORM POST für den Endpunkt /sso/v1/sdk/secure/idp:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im HTTP-Standardformat:

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

Identitätsdomains verarbeiten die Anforderung und leiten den Browser zur Authentifizierung und Autorisierung an die ausgewählte externe IdP weiter. Wenn die externe IdP fertig ist, leitet sie den Browser zu Identitätsdomains um. Anschließend leitet sie den Browser um, um mit der 2-Schritt-Verifizierung zu beginnen.

Schritt 3: Authentifizierung mit dem bevorzugten Faktor (SMS)

Die ersten Schritte zum Starten der 2-Schritt-Verifizierung ähneln Schritt 1. Identitätsdomains erstellen und übermitteln ein HTML-Formular, das die verschlüsselten Parameter loginCtx und signature enthält. Siehe Schritt 1 für detaillierte Informationen über das Formular POST und wie man entschlüsselt.

Nachdem der Parameter loginCtx entschlüsselt wurde, sollte die Antwort dem folgenden Beispiel ähneln:

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

Die Werte dieser Attribute definieren, welcher Authentifizierungsfaktor (in diesem Beispiel SMS) auf der Anmeldeseite angezeigt werden soll. Der Benutzer gibt den Einmal-Passcode ein, den er auf seinem Gerät erhält.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format, um die Authentifizierung mit der bevorzugten Methode abzuschließen:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Anschließend muss eine Session erstellt werden. Nachdem die Session erstellt wurde, wird der Browser auf die ursprünglich angeforderte URL umgeleitet. Siehe Session erstellen.

Schritt 1: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort gibt der Wert nextOp an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsfallbeispiel sollte credSubmit im nächsten Schritt gesendet werden. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Schritt 2: Zugangsdaten des Benutzers weiterleiten

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Beispiel für eine Fehlerantwort

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format, wenn der angegebene Benutzername oder das angegebene Kennwort ungültig ist:

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

Schritt 1: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort gibt der Wert nextOp an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsfallbeispiel sollte credSubmit im nächsten Schritt gesendet werden. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Schritt 2: Zugangsdaten des Benutzers ohne MFA weiterleiten)

Wenn der Benutzername und die Kennwörter gültig sind, antwortet der Server mit der TOU-Anweisung in dem im Benutzerprofil angegebenen Gebietsschema. Der Server fordert den Benutzer außerdem auf, seine Einwilligungsnachweise in der nächsten Anforderung anzugeben. Wenn die TOU-Anweisung nicht im Gebietsschema fr des Benutzers vorhanden ist, wird die 401-Antwort mit der Fehlermeldung AUTH-3036: Nutzungsbedingungen - Anweisung für Gebietsschema fr nicht hinzugefügt angezeigt.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format für den Endpunkt /sso/v1/sdk/authenticate:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format, wenn das Gebietsschema des Benutzers hinzugefügt wird:

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

Beispiel für eine Fehlerantwort

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format, wenn die TOU für das Gebietsschema des Benutzers nicht hinzugefügt wird:

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

Schritt 3: TOU-Zustimmung erteilen

In diesem Szenario akzeptiert oder lehnt der Benutzer die Nutzungsbedingungen für die Anwendung ab. Wenn der Benutzer den Nutzungsbedingungen zustimmt, wird der Benutzer auf die Anwendungsseite umgeleitet.

Wenn der Benutzer die Nutzungsbedingungen ablehnt, wird die 401-Antwort mit der Fehlermeldung AUTH-3035: Sie müssen die Nutzungsbedingungen akzeptieren, um auf diese Anwendung zuzugreifen angezeigt.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der Anforderung im JSON-Format, wenn der Benutzer TOU zustimmt.

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

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der Anforderung im JSON-Format, wenn der Benutzer die TOU ablehnt.

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format, wenn der Benutzer der TOU-Anweisung zustimmt.

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

Beispiel für eine Fehlerantwort

Im Folgenden wird der Inhalt der Antwort im JSON-Format angezeigt, wenn die TOU vom Benutzer abgelehnt wird.

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

Identitätsdomains können so konfiguriert werden, dass ein zeitbasierter Einmal-Passcode (OTP) zur Authentifizierung direkt an einen Benutzer gesendet wird oder dass der Passcode verschlüsselt und an den konsumierenden Client gesendet wird, der ihn dann zur Authentifizierung an den Benutzer senden kann.

Beispiel: Administratoren können Identitätsdomains so konfigurieren, dass zeitbasierte Einmal-Passcodes (OTP) an die Oracle Mobile Authenticator-(OMA-)App gesendet oder die OTPs per E-Mail an die primäre E-Mail-Adresse des Benutzers gesendet werden. In beiden Fällen generieren Identitätsdomains das OTP, senden es direkt an den Benutzer, und der Benutzer gibt den Code zur Authentifizierung ein. Weitere Informationen zum Festlegen dieser Optionen mit REST finden Sie unter Authentifizierungsfaktoranmeldung mit Faktorverifizierung - SMS und Authentifizierungsfaktoranmeldung mit Faktorverifizierung - E-Mail.

Verschlüsselung und Verschlüsselung

Bei dieser Implementierung wird der empfangene OTP-Code mit der folgenden Spezifikation ver- und entschlüsselt. Siehe PKCS #1: RSA Cryptography Specifications, Version 2.0, Section 7.1 RSAES-OAEP.

OTP-Entschlüsselungscode

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

Schritt 1: CustomUI-Anwendung erstellen

Weitere Informationen zu benutzerdefinierten Anwendungen finden Sie unter Anwendungen hinzufügen.

Schritt 2: Schlüsselpaar für ein selbstsigniertes Zertifikat generieren

Schritt 3: Anwendung so konfigurieren, dass OTP in der Antwort zurückgegeben wird

Schritt 4: OTP anfordern

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

Antwortbeispiel

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

Schritt 1: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort gibt der Wert nextOp an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsfallbeispiel sollte credSubmit im nächsten Schritt gesendet werden. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Schritt 2: Zugangsdaten des Benutzers weiterleiten

AuthnToken ist der id_token im JWT-Format, der die aktuellen Benutzerinformationen, Session- und Anforderungsdaten darstellt. Damit wird ein SSO-Sessioncookie erstellt und zur Ziel-URL umgeleitet. Wenn der Benutzername und das Kennwort gültig sind, wird AuthnToken abgerufen.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format für den Endpunkt /sso/v1/sdk/authenticate:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format, in dem die AuthnToken abgerufen wird:

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

Schritt 3: Zugriffstoken generieren

Nachdem Sie eine AuthnToken abgerufen haben, wird sie zum Abrufen des Zugriffstokens vom OAuth-Server verwendet.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Schritt 4: Benutzerinformationen abrufen

Der Benutzer leitet das Zugriffstoken weiter, um seine Informationen wie Benutzername, Anzeigename, E-Mail-ID usw. abzurufen.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der Anforderung im JSON-Format.

{{HOST}}/admin/v1/Me

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format mit Benutzerinformationen.

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

Schritt 1: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort gibt der Wert nextOp an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsfallbeispiel sollte credSubmit im nächsten Schritt gesendet werden. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Schritt 2: Zugangsdaten des Benutzers weiterleiten

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format, da PUSH Notifications der bevorzugte Faktor ist:

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

In der Antwort lautet der Status pending, da der Benutzer die PUSH-Benachrichtigung auf seinem Gerät zulassen oder deaktivieren muss. Die nextOp-Werte in der Antwort geben an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsbeispiel wird im nächsten Schritt credSubmit gesendet.

Schritt 3: Authentifizierung mit dem bevorzugten Faktor

Authentifizieren Sie mit dem bevorzugten Faktor, der in diesem Anwendungsbeispiel PUSH Notifications ist. Der Client muss die folgenden Attribute in diese Anforderung aufnehmen:

• op: teilt dem Server mit, welche Art von Vorgang der Client wünscht

• requestState: in der Schritt-2-Antwort empfangen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format, um die Authentifizierung mit der bevorzugten Methode abzuschließen:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Schritt 1: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort gibt der Wert nextOp an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsfallbeispiel sollte credSubmit im nächsten Schritt gesendet werden. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Schritt 2: Zugangsdaten des Benutzers weiterleiten

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Da in diesem Anwendungsbeispiel MFA in der Anmelde-Policy als optional festgelegt ist (angegeben durch den Wert false für das Attribut enrollmentRequired), kann der Benutzer sich entweder registrieren oder die Registrierung überspringen. Wenn MFA erforderlich ist, lautet der einzige nextOp-Wert enrollment.

In diesem Anwendungsbeispiel wird im nächsten Schritt enrollment gesendet, um die MFA-Faktorregistrierung für den Benutzer zu initiieren. Beachten Sie, dass BYPASSCODE als nextAuthFactors-Wert fehlt, da der Benutzer sich nicht mit einem Umgehungscode anmelden kann. Der Umgehungscode muss vom Benutzer mit "Mein Profil" generiert werden oder von einem Administrator angefordert werden, einen Umgehungscode für ihn zu generieren.

Schritt 3: Registrierung der zweiten Faktorauthentifizierung initiieren

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Schritt 4: Faktorzugangsdaten weiterleiten

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format, um die Factor-Zugangsdaten weiterzuleiten:

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

Antwortbeispiel

Der Status success wird in der Antwort angezeigt, wenn die OMA-App zur Server-Backchannel-Kommunikation abgeschlossen ist und die optCode-Verifizierung erfolgreich war. Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort geben die nextOp-Werte an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsbeispiel wird im nächsten Schritt createToken gesendet.

Beispiel für ausstehende Antwort

Der Status pending wird angezeigt, wenn die OMA-App zur Server-Backchannel-Kommunikation nicht abgeschlossen ist. Der Client fragt alle 10 Sekunden ab und fragt zwei Minuten ab. Nach zwei Minuten sendet der Server den Status "Nicht erfolgreich", wenn die otpCode-Verifizierung nicht erfolgreich war.

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

Schritt 5: Authentifizierungstoken erstellen

Dieser Schritt gibt an, dass der Client mit allen authnFactors abgeschlossen ist und eine Session erstellt werden muss. Der Server validiert, ob keine andere Faktorauswertung erforderlich ist (je nachdem, was für die Policy definiert ist), und antwortet mit dem Token oder verweigert den Zugriff. Der Client muss die folgenden Attribute enthalten:

• op: teilt dem Server mit, welche Art von Vorgang der Client wünscht

• requestState: in der Schritt-4-Antwort empfangen

Anforderungsbeispiel

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Schritt 1: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort gibt der Wert nextOp an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsfallbeispiel sollte credSubmit im nächsten Schritt gesendet werden. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Schritt 2: Zugangsdaten des Benutzers weiterleiten

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In diesem Anwendungsbeispiel muss sich der Benutzer bei der Accountwiederherstellung registrieren (durch den Wert true für das Attribut accRecEnrollmentRequired:true angegeben). Die nextAuthFactors gibt die Faktoren an, bei denen sich der Benutzer für die Accountwiederherstellung anmelden kann.

In diesem Anwendungsbeispiel wird die Registrierung im nächsten Schritt gesendet, um die Accountwiederherstellungsregistrierung für den Benutzer zu initiieren.

Schritt 3: Accountwiederherstellungsanmeldung initiieren

Dieser Schritt initiiert die SMS-Registrierung. Der Client muss die folgenden Attribute enthalten:

• op: Gibt dem Server an, welche Art von Vorgang der Client wünscht
• authFactor: Definiert den Authentifizierungsfaktor, für den der Benutzer sich anmelden möchte
• phoneNumber: Definiert die Telefonnummer, an die der SMS-Text gesendet wird
• countryCode: Definiert die Landeskennzahl der Telefonnummer, an die der SMS-Text gesendet wird
• requestState: in der Schritt-2-Antwort empfangen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Anforderung im JSON-Format:

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

In der Antwort geben die nextOp-Werte an, was als Operationswert in der nächsten Anforderung gesendet werden kann. In diesem Anwendungsbeispiel wird im nächsten Schritt credSubmit gesendet. Die otpCode wird per SMS an das Gerät des Benutzers gesendet.

Schritt 4: Faktorzugangsdaten weiterleiten

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format, um die Factor-Zugangsdaten weiterzuleiten:

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

Antwortbeispiel

Der Erfolgsstatus wird in der Antwort angezeigt, wenn die optCode-Verifizierung erfolgreich war. Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort wird der Wert accRecEnrollmentRequired auf false gesetzt, da die Accountregistrierung erfolgreich war. Die nextOp-Werte geben an, was in der nächsten Anforderung als op-Wert gesendet werden kann. Mit dem nextOp-Wert "Registrierung" kann der Benutzer zu einem anderen Faktor wechseln, um sich bei der Accountwiederherstellung anzumelden. In diesem Anwendungsbeispiel wird im nächsten Schritt createToken gesendet.

Schritt 5: Authentifizierungstoken erstellen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Schritt 1: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort gibt der Wert nextOp an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Anwendungsfallbeispiel sollte credSubmit im nächsten Schritt gesendet werden. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Schritt 2: Zugangsdaten des Benutzers weiterleiten

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In diesem Anwendungsbeispiel muss sich der Benutzer bei der Accountwiederherstellung registrieren (durch den Wert true für das Attribut accRecEnrollmentRequired:true angegeben). Die nextAuthFactors gibt die Faktoren an, bei denen sich der Benutzer für die Accountwiederherstellung anmelden kann.

In diesem Anwendungsbeispiel wird die Registrierung im nächsten Schritt gesendet, um die Accountwiederherstellungsregistrierung für den Benutzer zu initiieren.

Schritt 3: Accountwiederherstellungsanmeldung initiieren

Dieser Schritt initiiert die SMS-Registrierung. Der Client muss die folgenden Attribute enthalten:

• op: Gibt dem Server an, welche Art von Vorgang der Client wünscht
• authFactor: Definiert den Authentifizierungsfaktor, für den der Benutzer sich anmelden möchte
• phoneNumber: Definiert die Telefonnummer, an die der SMS-Text gesendet wird
• countryCode: Definiert die Landeskennzahl der Telefonnummer, an die der SMS-Text gesendet wird
• requestState: in der Schritt-2-Antwort empfangen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Anforderung im JSON-Format:

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

In der Antwort geben die nextOp-Werte an, was als Operationswert in der nächsten Anforderung gesendet werden kann. In diesem Anwendungsbeispiel wird im nächsten Schritt credSubmit gesendet. Die otpCode wird per SMS an das Gerät des Benutzers gesendet. Zugangsdaten teilen dem Benutzer mit, welche Eingabe für die nächste Anforderung erforderlich ist.

Schritt 4: Faktorzugangsdaten weiterleiten

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format, um die Factor-Zugangsdaten weiterzuleiten:

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

Antwortbeispiel

Der Erfolgsstatus wird in der Antwort angezeigt, wenn die optCode-Verifizierung erfolgreich war. Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort wird der Wert accRecEnrollmentRequired auf false gesetzt, da die Accountregistrierung erfolgreich war. Die nextOp-Werte geben an, was in der nächsten Anforderung als op-Wert gesendet werden kann. Mit dem nextOp-Wert "Registrierung" kann der Benutzer zu einem anderen Faktor wechseln, um sich bei der Accountwiederherstellung anzumelden. In diesem Anwendungsbeispiel wird im nächsten Schritt createToken gesendet.

Schritt 5: Authentifizierungstoken erstellen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

In der Antwort, da MFA erforderlich ist, hat enrollmentRequired den Wert true unter mfaSettings. Daher wird kein Token ausgegeben. Die EnrolledAccountRecoveryFactorsDetails zeigt die Accountwiederherstellungsfaktoren an, für die der Benutzer sich registriert hat. Die nextOp-Werte geben an, was in der nächsten Anforderung als op-Wert gesendet werden kann. In diesem Beispiel gibt der nextOp-Wert "enrollment" an, dass der Benutzer sich für MFA registrieren soll.

Schritt 6: SMS als Standard-MFA-Faktor in Überschneidung festlegen

Dieser Schritt gibt an, dass sich der Client bei MFA anmelden muss.

Der Client muss die folgenden Attribute enthalten:

• authFactor: Gibt an, für welchen Faktor die Anmeldung für MFA erfolgen soll
• accountRecoveryFactor: Wenn dieser Wert auf "true" gesetzt ist, gibt er an, dass der Benutzer den bereits registrierten Accountwiederherstellungsfaktor für MFA wiederverwenden möchte.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format:

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

Antwortbeispiel

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

In der Antwort geben die nextOp-Werte an, was als Operationswert in der nächsten Anforderung gesendet werden kann. Mit dem nextOp-Wert "Registrierung" kann der Benutzer einen zusätzlichen Faktor für MFA anmelden. In diesem Anwendungsbeispiel wird im nächsten Schritt createToken gesendet.

Schritt 7: Authentifizierungstoken erstellen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung im JSON-Format:

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

Antwortbeispiel

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

Bevor Sie beginnen

Schritt 1: KMSI für eine Identitätsdomain aktivieren

1. Rufen Sie das Admin-Zugriffstoken der Identitätsdomain für Ihren Account ab.
2. Führen Sie GET am Endpunkt /admin/v1/KmsiSettings/KmsiSettings aus. Das System gibt KmsiSettings zurück.
3. Aktualisieren Sie die erforderlichen Attribute, und führen Sie PUT am Endpunkt /admin/v1/KmsiSettings/KmsiSettings aus.

tokenValidityInDays

Geben Sie an, wie viele Tage Benutzer angemeldet bleiben können, bevor sie automatisch abgemeldet werden.

kmsiEnabled

Gibt an, ob KMSI für die Identitätsdomain aktiviert ist.

maxAllowedSessions

Geben Sie die maximale Anzahl von angemeldeten Sessions ein, die ein Benutzer haben kann.

Beispielanforderung

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

Schritt 2: Authentifizierungsablauf starten

Rufen Sie das anfängliche requestState ab, um den Authentifizierungsablauf zu starten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die Anforderung im cURL-Format:

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

Antwortbeispiel

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

Beachten Sie das neue keepMeSignedInEnabled-Attribut, das in der Antwort enthalten ist. Dies bedeutet, dass diese Identitätsdomain und Anwendung KMSI unterstützt. Wenn Sie über eine benutzerdefinierte Schnittstelle verfügen, zeigen Sie mit diesem Attribut die Option Angemeldet bleiben auf der Anmeldeseite an.

Schritt 3: Zugangsdaten des Benutzers mit KMSI weiterleiten

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

Wenn Sie über eine benutzerdefinierte Oberfläche verfügen, können Sie mit diesem Attribut die KMSI-Option anzeigen, den Status des Kontrollkästchens (ein- oder ausgeschaltet) aktivieren und diesen Parameter senden, um die KMSI-Session zu erstellen.

Antwortbeispiel

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

Beachten Sie im Antwortbeispiel das Attribut kmsiToken. Dieses Token kann zukünftig für den Zugriff auf alle Anwendungen verwendet werden, ohne dass sich ein Benutzer erneut anmelden muss.

Schritt 4: authnToken nach Ablauf der Session erneut ausstellen

Anforderungsbeispiel

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

Antwortbeispiel

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

Beachten Sie den Vorgang credSubmit, bei dem eine neue authFactor, appName und kmsiToken in der Anforderung gesendet werden. SSO wertet die Anforderung aus und gibt authnToken und das zuletzt aktualisierte kmsiToken in der Antwort zurück. Dies ist eine aktualisierte kmsiToken und ersetzt das vorhandene Token. Sie müssen diese aktualisierte kmsiToken in die nächste Anforderung aufnehmen.

Schritt 5: Zugangsdaten des Benutzers mit KMSI- und MFA-Ablauf übermitteln

Starten Sie GET in /sso/v1/sdk/authenticate aus Schritt 2: Authentifizierungsablauf starten.

Antwortbeispiel

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

Antwortbeispiel

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

Nachdem Sie den Einmal-Passcode (OTP) auf dem Gerät erhalten haben, fügen Sie den OTP in der Anforderung hinzu.

Anforderungsbeispiel

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

Die Antwort enthält authToken und kmsiToken. Dies ist eine aktualisierte kmsiToken.

Antwortbeispiel

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

Schritt 6: authnToken nach Ablauf der Session erneut ausstellen, wenn ein MFA-Faktor festgelegt ist

Wenn ein Benutzer versucht, sich mit kmsiToken anzumelden, und ein zweiter Faktor konfiguriert ist, wird der Benutzer immer zur Authentifizierung des zweiten Faktors aufgefordert. Erst nach erfolgreicher Authentifizierung werden authnToken und kmsiToken in der Antwort gesendet.

Anforderungsbeispiel

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

Die Antwort enthält ein aktualisiertes KMSI-Token und eine MFA-Challenge.

Antwortbeispiel

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

Wiederholen Sie denselben Vorgang, bei dem Sie erneut zur Eingabe des OTPs auf dem Gerät aufgefordert werden. Geben Sie die folgende Payload mit dem OTP an. Die Antwort muss die authnToken enthalten.

Anforderungsbeispiel

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

Antwortbeispiel

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

kmsiToken-Ablauf mit requestState

Verwenden Sie diesen Ablauf, um den Browserkontext zu unterstützen, wenn Sie das KMSI-Token, aber nicht das KMSI-Cookie besitzen. Nach Ablauf der Session führt die Anwendung einen Autorisierungsaufruf an das Identitätssystem mit redirectUrl, state, nonce usw. durch. In der Antwort gibt das Identitätssystem den requestState innerhalb von loginCtx zurück. Dieses requestState wird zusammen mit dem KMSI-Token übergeben, um die erforderliche Anwendung umzuleiten, nachdem die Session verlängert wurde.

Anforderungsbeispiel

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

Antwortbeispiel

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

Änderungen an /sso/v1/sdk/secure/session

KMSI erfordert, dass dem Endpunkt /sso/v1/sdk/secure/session ein neues Attribut hinzugefügt wird. kmsiToken muss von der benutzerdefinierten Anmeldeanwendung an den Endpunkt gesendet werden.

Payload-Signatur für von /authorize initiierte Anrufe

1. Wenn ein Benutzer auf eine Webanwendung zugreift, die durch Identitätsdomains geschützt ist, gibt er seine Anwendungs-URL ein. Beispiel: https://example.com/home/pages/profile.
2. Das System leitet zum Identitätsdomainaufruf /authorize um.
3. Die Identitätsdomain leitet den Benutzer zur vom Kunden bereitgestellten benutzerdefinierten Anmeldeseite um.
4. Die vom Kunden gehostete Anmeldeanwendung erfasst die Eingabeparameter und decodiert die loginCtx-Eingabe.
5. Der entschlüsselte Eingabeparameter stimmt mit dem Aufruf GET /sso/v1/sdk/authenticate überein.
6. Die Payload enthält keepMeSignedInEnabled, um zu identifizieren, ob KMSI aktiviert ist.
7. Die benutzerdefinierte Anmeldeanwendung erfasst die Zugangsdaten und leitet sie an die Identitätsdomain weiter.
8. Die Identitätsdomain validiert die Zugangsdaten und gibt kmsiToken und authnToken aus.
9. Die benutzerdefinierte Anmeldeanwendung verwendet authnToken und kmsiToken, während sie den Endpunkt /sso/v1/sdk/secure/session aufruft. Die neue Syntax des sicheren Endpunkts wird unter Änderungen an /sso/v1/sdk/secure/session beschrieben.
10. Die Identitätsdomain validiert authnToken, kmsiToken, und das Identitätssystem gibt dann das SSO-Sessioncookie und das KMSI-Cookie aus.
11. Während der Session wird das KMSI-Cookie validiert, um die Session zu verlängern, ohne die Zugangsdaten erneut einzugeben.