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 für das 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 ein Beispiel für Entschlü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, Identitätsprovider und Social Provider auf der Anmeldeseite angezeigt werden. Die Anmeldeseite wird angezeigt, in der die entschlüsselten Werte des Parameters loginCtx zusammen mit dem Zugriffstoken enthalten sind. Die Anmeldeseite enthält JavaScript, mit dem AJAX-Aufrufe an Identitätsdomains ausgeführt werden.

Schritt 2: SAML-Identitätsprovider auswählen

Beispiel für einen HTML-Formular-POST-Code zur Auswahl 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 an 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 Standard-HTTP-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 externe IdP um. 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 die Identitätsdomains die Session und leitet den Browser zur Ziel-URL um. Oder Identitätsdomains erstellen eine automatische HTML-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 für das 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 ein Beispiel für Entschlü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, Identitätsprovider und Social Provider auf der Anmeldeseite angezeigt werden. Die Anmeldeseite wird angezeigt, in der die entschlüsselten Werte des Parameters loginCtx zusammen mit dem Zugriffstoken enthalten sind. Die Anmeldeseite enthält JavaScript, mit dem AJAX-Aufrufe an Identitätsdomains ausgeführt werden.

Schritt 2: Social-Identitätsprovider auswählen

Beispiel für einen HTML-Formular-POST-Code zur Auswahl eines Social Media 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 an 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 Social IdP um. Wenn die Social 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 die Identitätsdomains die Session und leitet den Browser zur Ziel-URL um. Oder Identitätsdomains erstellen eine automatische HTML-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 für das 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 ein Beispiel für Entschlü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, Identitätsprovider und Social Provider auf der Anmeldeseite angezeigt werden. Die Anmeldeseite wird angezeigt, in der die entschlüsselten Werte des Parameters loginCtx zusammen mit dem Zugriffstoken enthalten sind. Die Anmeldeseite enthält JavaScript, mit dem AJAX-Aufrufe an Identitätsdomains ausgeführt werden.

Schritt 2: Externen Identitätsprovider auswählen

Beispiel für einen HTML-Formular-POST-Code zur Auswahl 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 an 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 Standard-HTTP-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 externe IdP um. Wenn die externe IdP beendet ist, wird der Browser zu Identitätsdomains umgeleitet. Anschließend wird der Browser zur 2-Schritt-Verifizierung umgeleitet.

Schritt 3: Authentifizierung mit dem bevorzugten Faktor (SMS)

Die ersten Schritte zum Beginnen der 2-Schritt-Verifizierung ähneln Schritt 1. Identitätsdomains erstellen und leiten ein HTML-Formular weiter, das die verschlüsselten Parameter loginCtx und signature enthält. Ausführliche Informationen zum Formular POST und zur Entschlüsselung finden Sie in Schritt 1.

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 einmaligen 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 Sitzung erstellt wurde, wird der Browser auf die ursprünglich angeforderte URL umgeleitet. Siehe Session erstellen.

Schritt 1: Authentifizierungsablauf starten

Rufen Sie die erste requestState ab, um den Authentifizierungsfluss 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 als Wert op in der nächsten Anforderung 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"
}

Fehlerantwort - Beispiel

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 die erste requestState ab, um den Authentifizierungsfluss 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 als Wert op in der nächsten Anforderung 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 Gebietsschema, das im Benutzerprofil angegeben ist. Der Server fordert den Benutzer auch auf, seine Zustimmungszugangsdaten in der nächsten Anforderung anzugeben. Wenn die TOU-Anweisung nicht im Gebietsschema fr des Benutzers vorhanden ist, wird die Antwort 401 mit der Fehlermeldung AUTH-3036: Nutzungsbedingungen für Gebietsschema fr nicht hinzugefügt angezeigt.

Anforderungsbeispiel

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

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

Fehlerantwort - Beispiel

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 bereitstellen

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

Wenn der Benutzer die Nutzungsbedingungen ablehnt, wird die 401-Antwort mit der Fehlermeldung AUTH-3035: Sie muss die Nutzungsbedingungen für den Zugriff auf diese Anwendung akzeptieren angezeigt.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der Anforderung im JSON-Format, wenn der Benutzer der 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"
}

Fehlerantwort - Beispiel

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. Informationen zum Festlegen dieser Optionen mit REST finden Sie unter Authentication Factor Enrollment With Factor Verification-SMS und Authentication Factor Enrollment With Factor Verification-Email.

Verschlüsselung und Entschlüsselung

Diese Implementierung verwendet die folgende Spezifikation, um den empfangenen OTP-Code zu verschlüsseln und zu entschlüsseln. 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 die erste requestState ab, um den Authentifizierungsfluss 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 als Wert op in der nächsten Anforderung 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 die id_token im JWT-Format, das 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 /sso/v1/sdk/authenticate-Endpunkt:

{  
   "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 die erste requestState ab, um den Authentifizierungsfluss 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 als Wert op in der nächsten Anforderung 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-Benachrichtigungen 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 Ablehnen muss. Die nextOp-Werte in der Antwort geben an, was als op-Wert in der nächsten Anforderung gesendet werden kann. In diesem Anwendungsfall wird im nächsten Schritt credSubmit gesendet.

Schritt 3: Authentifizierung mit dem bevorzugten Faktor

Authentifizierung mit dem bevorzugten Faktor, in diesem Anwendungsbeispiel PUSH-Benachrichtigungen. 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 die erste requestState ab, um den Authentifizierungsfluss 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 als Wert op in der nächsten Anforderung 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 Anwendungsfall MFA in der Anmelde-Policy als optional festgelegt ist (durch den Wert false für das Attribut enrollmentRequired gekennzeichnet), kann der Benutzer sich entweder anmelden oder die Anmeldung überspringen. Wenn MFA erforderlich ist, wäre der einzige nextOp-Wert enrollment.

In diesem Anwendungsfall 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, weil der Benutzer sich nicht mit einem Umgehungscode anmelden kann. Der Umgehungscode sollte vom Benutzer mit "Mein Profil" generiert werden, oder durch die Anforderung, dass ein Administrator einen Code für ihn generiert.

Schritt 3: Second Factor Authentication Enrollment starten

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 Faktorzugangsdaten weiterzuleiten:

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

Antwortbeispiel

Der Status success wird in der Antwort angezeigt, wenn die Backchannel-Kommunikation zwischen der OMA-App und dem Server 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 Anwendungsfall wird im nächsten Schritt createToken gesendet.

Beispiel für ausstehende Antwort

Der Status pending wird angezeigt, wenn die Backchannel-Kommunikation zwischen OMA und Server nicht abgeschlossen ist. Der Client fragt alle 10 Sekunden ab und fragt zwei Minuten weiter 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 ausgeführt wird und eine Session erstellt werden muss. Der Server validiert, dass keine andere Faktorauswertung (je nachdem, was für die Policy definiert ist) erforderlich 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 die erste requestState ab, um den Authentifizierungsfluss 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 als Wert op in der nächsten Anforderung 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 Anwendungsfall muss sich der Benutzer bei der Accountwiederherstellung anmelden (mit dem Wert true für das Attribut accRecEnrollmentRequired:true angegeben). nextAuthFactors gibt die Faktoren an, in denen sich der Benutzer für die Accountwiederherstellung anmelden kann.

In diesem Anwendungsfall wird die Anmeldung im nächsten Schritt gesendet, um die Accountwiederherstellungsanmeldung für den Benutzer zu initiieren.

3. Schritt: Account Recovery-Anmeldung starten

Dieser Schritt initiiert die SMS-Anmeldung. 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 Op-Wert in der nächsten Anforderung gesendet werden kann. In diesem Anwendungsfall 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 Faktorzugangsdaten weiterzuleiten:

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

Antwortbeispiel

Der Status "Erfolg" 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 Accountanmeldung erfolgreich war. Die nextOp-Werte geben an, was als op-Wert in der nächsten Anforderung gesendet werden kann. Mit dem Wert nextOp "enrollment" kann der Benutzer zu einem anderen Faktor wechseln, um sich bei der Accountwiederherstellung anzumelden. In diesem Anwendungsfall 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 die erste requestState ab, um den Authentifizierungsfluss 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 als Wert op in der nächsten Anforderung 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 Anwendungsfall muss sich der Benutzer bei der Accountwiederherstellung anmelden (mit dem Wert true für das Attribut accRecEnrollmentRequired:true angegeben). nextAuthFactors gibt die Faktoren an, in denen sich der Benutzer für die Accountwiederherstellung anmelden kann.

In diesem Anwendungsfall wird die Anmeldung im nächsten Schritt gesendet, um die Accountwiederherstellungsanmeldung für den Benutzer zu initiieren.

3. Schritt: Account Recovery-Anmeldung starten

Dieser Schritt initiiert die SMS-Anmeldung. 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 Op-Wert in der nächsten Anforderung gesendet werden kann. In diesem Anwendungsfall 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 Eingaben erforderlich sind, um die nächste Anforderung zu übergeben.

Schritt 4: Faktorzugangsdaten weiterleiten

Anforderungsbeispiel

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

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

Antwortbeispiel

Der Status "Erfolg" 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 Accountanmeldung erfolgreich war. Die nextOp-Werte geben an, was als op-Wert in der nächsten Anforderung gesendet werden kann. Mit dem Wert nextOp "enrollment" kann der Benutzer zu einem anderen Faktor wechseln, um sich bei der Accountwiederherstellung anzumelden. In diesem Anwendungsfall 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"
}

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

Schritt 6: SMS als Standard-MFA-Faktor für Überschneidung festlegen

Dieser Schritt gibt an, dass sich der Client für MFA registrieren soll.

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 angemeldeten 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 Vorgangswert in der nächsten Anforderung gesendet werden kann. Mit dem Wert nextOp "enrollment" kann der Benutzer zusätzlichen Faktor für MFA anmelden. In diesem Anwendungsfall 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 die KmsiSettings zurück.
3. Aktualisieren Sie die erforderlichen Attribute, und führen Sie PUT am /admin/v1/KmsiSettings/KmsiSettings-Endpunkt 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 der 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 die erste requestState ab, um den Authentifizierungsfluss 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 weist darauf hin, 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: Übermitteln der Zugangsdaten des Benutzers mit KMSI

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

Wenn Sie über eine benutzerdefinierte Schnittstelle verfügen, verwenden Sie dieses Attribut, um die KMSI-Option anzuzeigen, aktivieren Sie den Status des Kontrollkästchens (ein oder aus), und senden Sie diesen Parameter, um die KMSI-Sitzung 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 ein Benutzer sich 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 die neuen authFactor-, appName- und kmsiToken-Dateien 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: Benutzerzugangsdaten mit KMSI und MFA-Ablauf übermitteln

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

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 Sessionablauf erneut ausgeben, 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 OTP auf dem Gerät aufgefordert werden. Geben Sie die folgende Payload mit dem OTP an. Die Antwort muss 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 ruft die Anwendung einen Autorisierungsaufruf im Identitätssystem mit redirectUrl, state, nonce usw. ab. In der Antwort gibt das Identitätssystem die requestState innerhalb von loginCtx zurück. Dieses requestState-Token wird zusammen mit dem KMSI-Token übergeben, um die erforderliche Anwendung nach der Erweiterung der Session umzuleiten.

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

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

Payload-Signatur für /authorize-initiierte Aufrufe

1. Wenn ein Benutzer auf eine Webanwendung zugreift, die durch Identitätsdomains geschützt ist, geben er seine Anwendungs-URL ein. Beispiel: https://example.com/home/pages/profile.
2. Das System leitet zum Aufruf der Identitätsdomain /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 beim Aufruf des /sso/v1/sdk/secure/session-Endpunkts. 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 Sitzung wird das KMSI-Cookie validiert, um die Sitzung zu verlängern, ohne die Zugangsdaten erneut einzugeben.