認証APIを使用したカスタム・サインイン・ページの開発

ステップ1: 認証フローの開始

ユーザーがブラウザ・ウィンドウを開き、保護されたページにアクセスします。

HTMLフォームPOSTの例

アイデンティティ・ドメインがカスタム・サインイン・ページを起動するために返すHTMLフォームPOSTの例を次に示します:

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

Javaで暗号化されたloginCtxの復号化ロジックの例

暗号化ロジックの例を次に示します:

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

レスポンスの例

レスポンスは次のようになります:

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

これらの属性の値によって、サインイン・ページに表示される認証ファクタ、アイデンティティ・プロバイダおよびソーシャル・プロバイダが定義されます。loginCtxパラメータの復号化された値とアクセス・トークンを含むサインイン・ページが表示されます。ログイン・ページには、アイデンティティ・ドメインへのAJAXコールの実行に使用されるJavaScriptが含まれます。

ステップ2: SAMLアイデンティティ・プロバイダの選択

SAML IdPを選択するHTMLフォームPOSTコードの例

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

リクエストの例

/sso/v1/sdk/secure/idpエンドポイントへのFORM POSTのコンテンツの例を次に示します:

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

レスポンスの例

標準HTTP形式のレスポンスのコンテンツの例を次に示します:

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

アイデンティティ・ドメインがリクエストを処理し、認証および認可のために選択した外部IdPにブラウザをリダイレクトします。外部IdPが終了すると、ブラウザはアイデンティティ・ドメインにリダイレクトされます。アイデンティティ・ドメインがアサーション・レスポンスを検証し、MFAなどの追加の認証が必要かどうかを確認します。

追加の認証が不要な場合、アイデンティティ・ドメインがセッションを作成し、ブラウザをターゲットURLにリダイレクトします。または、authnTokenを含むカスタム・サインイン・ページへのHTML自動送信FORM POSTをアイデンティティ・ドメインが作成します。次に、カスタム・サインイン・ページでセッションが作成されます。「セッションの作成」を参照してください。

ステップ1: 認証フローの開始

ユーザーがブラウザ・ウィンドウを開き、保護されたページにアクセスします。

HTMLフォームPOSTの例

アイデンティティ・ドメインがカスタム・サインイン・ページを起動するために返すHTMLフォームPOSTの例を次に示します:

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

Javaで暗号化されたloginCtxの復号化ロジックの例

暗号化ロジックの例を次に示します:

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

レスポンスの例

レスポンスは次のようになります:

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

これらの属性の値によって、サインイン・ページに表示される認証ファクタ、アイデンティティ・プロバイダおよびソーシャル・プロバイダが定義されます。loginCtxパラメータの復号化された値とアクセス・トークンを含むサインイン・ページが表示されます。ログイン・ページには、アイデンティティ・ドメインへのAJAXコールの実行に使用されるJavaScriptが含まれます。

ステップ2: ソーシャル・アイデンティティ・プロバイダの選択

ソーシャルIdPを選択するHTMLフォームPOSTコードの例

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

リクエストの例

/sso/v1/sdk/secure/idpエンドポイントへのFORM POSTのコンテンツの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

アイデンティティ・ドメインがリクエストを処理し、認証および認可のために選択したソーシャルIdPにブラウザをリダイレクトします。ソーシャルIdPが終了すると、ブラウザはアイデンティティ・ドメインにリダイレクトされます。アイデンティティ・ドメインがアサーション・レスポンスを検証し、MFAなどの追加の認証が必要かどうかを確認します。

追加の認証が不要な場合、アイデンティティ・ドメインがセッションを作成し、ブラウザをターゲットURLにリダイレクトします。または、authnTokenを含むカスタム・サインイン・ページへのHTML自動送信FORM POSTをアイデンティティ・ドメインが作成します。次に、カスタム・サインイン・ページでセッションが作成されます。「セッションの作成」を参照してください。

ステップ1: 認証フローの開始

ユーザーがブラウザ・ウィンドウを開き、保護されたページにアクセスします。

HTMLフォームPOSTの例

アイデンティティ・ドメインがカスタム・サインイン・ページを起動するために返すHTMLフォームPOSTの例を次に示します:

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

Javaで暗号化されたloginCtxの復号化ロジックの例

暗号化ロジックの例を次に示します:

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

レスポンスの例

レスポンスは次のようになります:

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

これらの属性の値によって、サインイン・ページに表示される認証ファクタ、アイデンティティ・プロバイダおよびソーシャル・プロバイダが定義されます。loginCtxパラメータの復号化された値とアクセス・トークンを含むサインイン・ページが表示されます。ログイン・ページには、アイデンティティ・ドメインへのAJAXコールの実行に使用されるJavaScriptが含まれます。

ステップ2: 外部アイデンティティ・プロバイダの選択

外部IdPを選択するHTMLフォームPOSTコードの例

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

リクエストの例

/sso/v1/sdk/secure/idpエンドポイントへのFORM POSTのコンテンツの例を次に示します:

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

レスポンスの例

標準HTTP形式のレスポンスのコンテンツの例を次に示します:

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

アイデンティティ・ドメインがリクエストを処理し、認証および認可のために選択した外部IdPにブラウザをリダイレクトします。外部IdPが終了すると、ブラウザがアイデンティティ・ドメインにリダイレクトされ、その後、ブラウザがリダイレクトされて2ステップ検証が開始されます。

ステップ3: 優先ファクタ(SMS)を使用した認証

2ステップ検証を開始する最初のステップは、ステップ1と似ています。アイデンティティ・ドメインは、暗号化されたloginCtxおよびsignatureパラメータを含むHTMLフォームを作成および送信します。フォームPOSTおよび復号化の方法の詳細は、ステップ1を参照してください。

loginCtxパラメータを復号化すると、レスポンスは次の例のようになります:

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

これらの属性の値は、サインイン・ページに表示する認証ファクタ(この例ではSMS)を定義します。ユーザーは、デバイスで受信するワンタイム・パスコードを入力します。

リクエストの例

優先メソッドを使用して認証を完了するためのJSON形式のPOSTリクエストのコンテンツを次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

セッションを作成する必要があります。セッションが作成されると、ブラウザは最初にリクエストされたURLにリダイレクトされます。「セッションの作成」を参照してください。

ステップ1: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitを送信する必要があります。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

ステップ2: ユーザーの資格証明の発行

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

エラー・レスポンスの例

指定したユーザー名またはパスワードが無効な場合のJSON形式でのレスポンスのコンテンツの例を次に示します:

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

ステップ1: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitを送信する必要があります。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

ステップ2: MFAを使用しないユーザーの資格証明の発行)

ユーザー名とパスワードが有効な場合、サーバーはユーザーのプロファイルで指定されたロケールでTOU文を使用して応答します。また、サーバーは、次のリクエストで承諾の資格証明を指定するようにユーザーに求めます。TOU文がユーザーのロケールfrに存在しない場合、401レスポンスとエラー・メッセージAUTH-3036 : ロケールfrの使用条件文が追加されていませんが表示されます。

リクエストの例

/sso/v1/sdk/authenticateエンドポイントに対するJSON形式のPOSTリクエストのコンテンツを次に示します:

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

レスポンスの例

ユーザーのロケールが追加された場合のJSON形式のレスポンスのコンテンツの例を次に示します:

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

エラー・レスポンスの例

ユーザーのロケールのTOUが追加されていない場合のJSON形式のレスポンスのコンテンツの例を次に示します:

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

ステップ3: TOU承諾の指定

このシナリオでは、ユーザーはアプリケーションの使用条件を受け入れるか拒否します。ユーザーが使用条件に同意すると、ユーザーはアプリケーション・ページにリダイレクトされます。

ユーザーが使用条件を拒否すると、401レスポンスとエラー・メッセージAUTH-3035 : このアプリケーションにアクセスするには、使用条件を受け入れる必要がありますが表示されます。

リクエストの例

ユーザーがTOUに同意した場合のJSON形式のリクエストのコンテンツの例を次に示します。

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

リクエストの例

ユーザーがTOUを拒否した場合のJSON形式のリクエストのコンテンツの例を次に示します。

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

レスポンスの例

ユーザーがTOUに同意した場合のJSON形式のレスポンスのコンテンツの例を次に示します。

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

エラー・レスポンスの例

ユーザーがTOUを拒否する場合のJSON形式のレスポンスのコンテンツの例を次に示します。

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

アイデンティティ・ドメインは、時間ベースのワンタイム・パスコード(OTP)をユーザーに直接送信して認証できるように構成することも、パスコードを暗号化してコンシューマ・クライアントに送信するように構成することもできます。このユーザーは、そのパスコードをユーザーに送信して認証できます。

たとえば、管理者は、時間ベースのワンタイム・パスコード(OTP)をOracle Mobile Authenticator (OMA)アプリケーションに送信したり、OTPをユーザーのプライマリ電子メール・アドレスに電子メールを送信するようにアイデンティティ・ドメインを構成できます。どちらの場合も、アイデンティティ・ドメインはOTPを生成してユーザーに直接送信し、ユーザーは認証用のコードを入力します。RESTを使用して、これらのオプションを設定する方法の詳細は、ファクタ検証による認証ファクタ登録-SMSおよびファクタ検証による認証ファクタ登録-Eメールを参照してください。

暗号化と暗号化

この実装では、次の仕様を使用して、受信したOTPコードを暗号化および復号化します。PKCS #1: RSA暗号化仕様、バージョン2.0、セクション7.1 RSAES-OAEPを参照してください。

OTP復号化コード

/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */
package decryption;

import java.security.Key;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.cert.CertificateFactory;
import java.security.spec.PKCS8EncodedKeySpec;
import java.util.Base64;
import javax.crypto.Cipher;

/**
 *
 * @author <author>
 */
public class DecryptOtpCode {
    
    private static Key getPrivateKey(String privateKeyPEM) throws Exception {
        byte[] encoded = Base64.getDecoder().decode(privateKeyPEM);
        KeyFactory kf = KeyFactory.getInstance("RSA");
        PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(encoded);
        return kf.generatePrivate(keySpec);
    }
    
    public static void main(String args[]) {
        String value = "<encrypted_value>";
        String privatekey = 
                            "<pem_privatekey_data>";
        try {
                Cipher cipherInstance =
                        Cipher.getInstance("RSA/ECB/OAEPwithSHA1andMGF1Padding");
                CertificateFactory factory = CertificateFactory.getInstance("X.509");
                byte [] decoded = Base64.getDecoder().decode(value);
                PrivateKey pKey = (PrivateKey)getPrivateKey(privatekey);
                cipherInstance.init(Cipher.DECRYPT_MODE, pKey);
                byte[] decrypted = cipherInstance.doFinal(decoded);
                System.out.println("Decrypted text is " + new String(decrypted));
            } catch (Exception e) {
                //Unable to encrypt the content. Default to send the otp to user
                //no error or exception thrown.
                e.printStackTrace();
            }
    }
    
}

ステップ1: CustomUIアプリケーションの作成

カスタム・アプリケーションの詳細は、「アプリケーションの追加」を参照してください。

ステップ2: 自己署名証明書のキー・ペアの生成

ステップ3: レスポンスでOTPを返すためのアプリケーションの構成

ステップ4: OTPのリクエスト

true

{
   "op": "credSubmit",
   "credentials": {
      "username": "test.user",
      "password": "example-password"
   },
   "userFlowControlledByExternalClient": true,
   "x5t": "<certificate thumbprint>",
   "requestState": "{{requestState}}"
}

"otp": {
        "value": "IMCw==",
        "alg": "RSAES-OAEP",
        "x5t": "<certificate thumbprint>"
 }

レスポンスの例

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

ステップ1: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitを送信する必要があります。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

ステップ2: ユーザーの資格証明の発行

AuthnTokenは、現在のユーザー情報、セッションおよびリクエスト・データを表すJWT形式のid_tokenです。これは、SSOセッションCookieを作成し、ターゲットURLにリダイレクトするために使用されます。ユーザー名とパスワードが有効な場合は、AuthnTokenが取得されます。

リクエストの例

/sso/v1/sdk/authenticateエンドポイントに対するJSON形式のPOSTリクエストのコンテンツを次に示します:

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

レスポンスの例

AuthnTokenが取得されるJSON形式のレスポンスのコンテンツの例を次に示します:

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

ステップ3: アクセス・トークンの生成

AuthnTokenを取得すると、OAuthサーバーからアクセス・トークンを取得するために使用されます。

リクエストの例

JSON形式のリクエストのコンテンツの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

ステップ4: ユーザー情報の取得

ユーザーは、アクセス・トークンを送信して、ユーザー名、表示名、電子メールIDなどの情報を取得します。

リクエストの例

JSON形式のリクエストのコンテンツの例を次に示します。

{{HOST}}/admin/v1/Me

レスポンスの例

JSON形式のレスポンスのコンテンツとユーザー情報の例を次に示します。

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

ステップ1: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitを送信する必要があります。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

ステップ2: ユーザーの資格証明の発行

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

レスポンスの例

PUSH通知が優先ファクタであるため、JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、ユーザーはデバイスでPUSH通知を許可または拒否する必要があるため、ステータスはpendingになります。レスポンスのnextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitが送信されます。

ステップ3: 優先ファクタを使用した認証

優先ファクタ(このユースケースではPUSH通知)を使用して認証します。クライアントは、このリクエストに次の属性を含める必要があります:

• op:クライアントが必要とする操作の種類をサーバーに指示します

• requestState:ステップ2のレスポンスで受信

リクエストの例

優先メソッドを使用して認証を完了するためのJSON形式のPOSTリクエストのコンテンツを次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

ステップ1: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitを送信する必要があります。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

ステップ2: ユーザーの資格証明の発行

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{
    "status": "success",
    "nextAuthFactors": [
        "TOTP",
        "SMS",
        "EMAIL",
        "SECURITY_QUESTIONS"
    ],
    "TOTP": {
        "credentials": [
            "offlineTotp"
        ]
    },
    "SMS": {
        "credentials": [
            "phoneNumber"
        ]
    },
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "mfaSettings": {
        "enrollmentRequired": false
    },
    "requestState": "m3oIaGVOlHwA...../Fi+1RpmKmd4"
}

このユースケースの例では、MFAがサインオン・ポリシー(enrollmentRequired属性の値falseで示される)でオプションとして設定されているため、ユーザーには登録またはスキップの選択肢が与えられます。MFAが必要な場合、nextOp値はenrollment.のみです

このユースケースの例では、ユーザーのMFAファクタ登録を開始するために、次のステップでenrollmentが送信されます。ユーザーがバイパス・コードを使用して登録できないため、BYPASSCODEがnextAuthFactors値として欠落していることに注意してください。バイパス・コードは、マイ・プロファイルを使用して、または管理者がそのコードを生成するように要求することによって、ユーザーが生成する必要があります。

ステップ3: 第2要素認証登録の開始

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{
    "status": "success",
    "displayName": "Joe's Phone",
    "TOTP": {
        "credentials": [
            "otpCode"
        ],
        "qrCode": {
            "content": "oraclemobileauthenticator://totp/user?issuer=example1&Period=30&algorithm=SHA1&digits=6&RSA=SHA256withRSA&Deviceid=22f38324e67f4e2bb8e9e24583924a31&RequestId=9b428c1a-abb3-40ee-bd24-5064a87b638e&LoginURL=https%3A%2F%2Fexampletenant.com%3A8943%2Fsso%2Fv1%2F&OTP=eyJraWQiOiJTSUdOSU5HX0tFWSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0.eyJkZXZpY2VfaWQiOiIyMmYzODMyNGU2N2Y0ZTJiYjhlOWUyNDU4MzkyNGEzMSIsImlzcyI6IkF1dGhTcnYiLCJleHAiOjE1MjcxODEwODEsImlhdCI6MTUyNzE4MDc4MSwidGVuYW50IjoidGVuYW50MSJ9.Of0Hv5H3aRpDqdsiFLO0YkK2gbzq78k3jaJFwoWwR5LKOEH-9qTt1zjSiXujPD1T__8fEZDi8iKDyxXtL5zjAlEKd5wI026JjekG58ROPjW8gADWcMrTGQ4Lgw4Q0UPjk8Fm8AloQ1vS6xpDre6S-Vv620z28EKWZK_yGhUVSfAJVzSUxaypLtQhOQJBCNAzCElUgqyav7Vpi2z5eVQBQRtXv-Z_sTgrFXaVmVU3uSNVcg6zVX2x0fMQFgeO5lyC3U2Yy9JgA7iMfAMpuNvBzW0GjyByPAYRVnHSLPuHL1qiNx9ygpoVEcFLQJcOPuDLW2bW9ZwbUcVdS0F4L_2NfA&ServiceType=TOTP&KeyPairLength=2048&SSE=Base32",
            "imageType": "image/png",
            "imageData": "iVBORw0KG.......5ErkJggg=="
        }
    },
    "nextOp": [
        "credSubmit",
        "createToken",
        "createSession",
        "enrollment"
    ],
    "mfaSettings": {
        "enrollmentRequired": false
    },
    "requestState": "8A317/A1JiQe.....ce5/paoVOWw"
}

ステップ4: ファクタ資格証明の発行

リクエストの例

次の例に、ファクタ資格証明を発行するためのJSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

OMAアプリケーションからサーバー・バックチャネルへの通信が完了し、optCodeの検証に成功すると、レスポンスにsuccessステータスが表示されます。JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcreateTokenが送信されます。

保留中のレスポンスの例

pendingステータスは、OMAアプリケーションからサーバーへのバックチャネル通信が完了していない場合に表示されます。クライアントは10秒ごとにポーリングを続け、2分間ポーリングを続けます。2分後に、otpCode検証が成功しなかった場合、サーバーは失敗ステータスを送信します。

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

ステップ5: 認証トークンの作成

このステップは、クライアントがすべてのauthnFactorsを完了し、セッションを作成する必要があることを示しています。サーバーは、他のファクタ評価(ポリシーに定義されている内容に応じて)が必要ないことを検証し、トークンを使用して応答するか、アクセスを拒否します。クライアントには次の属性が含まれている必要があります:

• op:クライアントが必要とする操作の種類をサーバーに指示します

• ステップ4のレスポンスでrequestState:を受信

リクエストの例

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

ステップ1: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitを送信する必要があります。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

ステップ2: ユーザーの資格証明の発行

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{
    "status": "success",
    "ecId": "R^iCq18G000000000",
    "accRecEnrollmentRequired": true,
    "nextAuthFactors": [
        "SMS",
        "SECURITY_QUESTIONS",
        "EMAIL"
    ],
    "SMS": {
        "credentials": [
            "phoneNumber",
            "countryCode"
        ]
    },
    "EMAIL": {
        "userAllowedToSetRecoveryEmail": "true",
        "primaryEmailVerified": "true",
        "primaryEmail": "clarence.saladna@example.com",
        "credentials": [
            "recoveryEmail"
        ]
    },
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "IjhvZPILfadhlnih+4uTJ83CHf....0SDELTO0mTRqC+nNU"
}

このユースケースの例では、ユーザーはアカウント・リカバリに登録する必要があります(accRecEnrollmentRequired:true属性の値(true)で指定)。nextAuthFactorsは、ユーザーがアカウント・リカバリに登録できるファクタを示します。

このユースケースの例では、ユーザーのアカウント・リカバリ登録を開始するために、次のステップで登録が送信されます。

ステップ3: アカウント・リカバリ登録の開始

このステップでは、SMS登録を開始します。クライアントには次の属性が含まれている必要があります:

• op: クライアントが必要とする操作の種類をサーバーに指示します
• authFactor: ユーザーが登録する認証ファクタを定義します
• phoneNumber: SMSテキストが送信される電話番号を定義します
• countryCode: SMSテキストが送信される電話番号の国コードを定義します
• requestState: ステップ2のレスポンスで受信

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

JSON形式のリクエストのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitが送信されます。otpCodeは、SMSを使用してユーザーのデバイスに送信されます。

ステップ4: ファクタ資格証明の発行

リクエストの例

次の例に、ファクタ資格証明を発行するためのJSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

optCodeの検証に成功すると、レスポンスに成功ステータスが表示されます。JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、アカウントの登録が成功すると、accRecEnrollmentRequired値がfalseに設定されます。nextOp値は、次のリクエストでop値として送信できる内容を示します。nextOp値"enrollment"を使用すると、ユーザーは別のファクタに切り替えてアカウント・リカバリに登録できます。このユースケースの例では、次のステップでcreateToken が送信されます。

ステップ5: 認証トークンの作成

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

ステップ1: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitを送信する必要があります。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

ステップ2: ユーザーの資格証明の発行

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{
    "status": "success",
    "ecId": "HI^kd1M0000000000",
    "accRecEnrollmentRequired": true,
    "nextAuthFactors": [
        "SMS",
        "SECURITY_QUESTIONS",
        "EMAIL"
    ],
    "SMS": {
        "credentials": [
            "phoneNumber",
            "countryCode"
        ]
    },
    "EMAIL": {
        "userAllowedToSetRecoveryEmail": "true",
        "primaryEmailVerified": "true",
        "primaryEmail": "clarence.saladna@example.com",
        "credentials": [
            "recoveryEmail"
        ]
    },
    "nextOp": [
        "createToken",
        "createSession",
        "enrollment"
    ],
    "requestState": "wtyRQpBzFZnuGMQvLNRotKfRIlgliWNc8sxipU....41zjKQcvdzk2bmvWs"
}

このユースケースの例では、ユーザーはアカウント・リカバリに登録する必要があります(accRecEnrollmentRequired:true属性の値(true)で指定)。nextAuthFactorsは、ユーザーがアカウント・リカバリに登録できるファクタを示します。

このユースケースの例では、ユーザーのアカウント・リカバリ登録を開始するために、次のステップで登録が送信されます。

ステップ3: アカウント・リカバリ登録の開始

このステップでは、SMS登録を開始します。クライアントには次の属性が含まれている必要があります:

• op: クライアントが必要とする操作の種類をサーバーに指示します
• authFactor: ユーザーが登録する認証ファクタを定義します
• phoneNumber: SMSテキストが送信される電話番号を定義します
• countryCode: SMSテキストが送信される電話番号の国コードを定義します
• requestState: ステップ2のレスポンスで受信

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

JSON形式のリクエストのコンテンツの例を次に示します:

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitが送信されます。otpCodeは、SMSを使用してユーザーのデバイスに送信されます。資格証明では、次のリクエストで渡す必要がある入力を確認できます。

ステップ4: ファクタ資格証明の発行

リクエストの例

次の例に、ファクタ資格証明を発行するためのJSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

optCodeの検証に成功すると、レスポンスに成功ステータスが表示されます。JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスでは、アカウントの登録が成功すると、accRecEnrollmentRequired値がfalseに設定されます。nextOp値は、次のリクエストでop値として送信できる内容を示します。nextOp値"enrollment"を使用すると、ユーザーは別のファクタに切り替えてアカウント・リカバリに登録できます。このユースケースの例では、次のステップでcreateToken が送信されます。

ステップ5: 認証トークンの作成

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{
    "status": "success",
    "ecId": "HI^kd1Q0000000000",
    "nextAuthFactors": [
        "TOTP",
        "SECURITY_QUESTIONS",
        "SMS",
        "EMAIL",
        "PUSH"
    ],
    "EnrolledAccountRecoveryFactorsDetails": {
        "SMS": {
            "credentials": [
                "accountRecoveryFactor"
            ],
            "enrolledDevices": [
                {
                    "deviceId": "3ed9b2ed366441fb91c9277abd694348",
                    "displayName": "+44XXXXXXXX455"
                }
            ]
        },
        "EMAIL": {
            "credentials": [
                "accountRecoveryFactor"
            ],
            "enrolledDevices": [
                {
                    "displayName": "clarence.saladna@example.com"
                }
            ]
        },
        "enrolledAccRecFactorsList": [
            "SMS",
            "EMAIL"
        ]
    },
    "nextOp": [
        "enrollment"
    ],
    "mfaSettings": {
        "enrollmentRequired": true
    },
    "requestState": "YN9sdSJiNtD5lOEKt33paDa9Ezs5ZZhZhF3C1BsDCuMdVVNqt1RmA3d3SppmnVOIP3uYrErQNYADHCIQLrXgmxpxReUzdcFDArlejaaph3qWctYvLQiIsBwixsHgTOfQiDkzyjN8JZiX/gqbkTEmHi1S3EtjYXuw7qCcwi...G8ZnyfTrcZtKEpaDDj7CtWF/+LIwAEQLvFaXvkOK4P4"
}

レスポンスではMFAが必要であるため、enrollmentRequiredのmfaSettingsの値はtrueになります。その結果、トークンは発行されません。EnrolledAccountRecoveryFactorsDetailsには、ユーザーが登録したアカウント・リカバリ・ファクタが表示されます。nextOp値は、次のリクエストでop値として送信できる内容を示します。この例のnextOp値"enrollment"は、ユーザーがMFAに登録することを示します。

ステップ6: 重複でのデフォルトMFAファクタとしてのSMSの設定

このステップは、クライアントがMFAに登録する必要があることを示します。

クライアントには次の属性が含まれている必要があります:

• authFactor: MFAに登録するファクタを示します
• accountRecoveryFactor: trueに設定されている場合、MFAにすでに登録されているアカウント・リカバリ・ファクタをユーザーが再利用することを示します。

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

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

レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。nextOp値"enrollment"を使用すると、ユーザーはMFAに追加のファクタを登録できます。このユースケースの例では、次のステップでcreateTokenが送信されます。

ステップ7: 認証トークンの作成

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:

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

レスポンスの例

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

開始前

ステップ1: アイデンティティ・ドメインのKMSIの有効化

1. アカウントのアイデンティティ・ドメイン管理アクセス・トークンを取得します。
2. /admin/v1/KmsiSettings/KmsiSettingsエンドポイントでGETを実行します。KmsiSettingsが返されます。
3. 必要な属性を更新し、/admin/v1/KmsiSettings/KmsiSettingsエンドポイントでPUTを実行します。

tokenValidityInDays

ユーザーが自動的にサインアウトされるまでにサインインできる日数を入力します。

kmsiEnabled

アイデンティティ・ドメインに対してKMSIが有効かどうかを示します。

maxAllowedSessions

ユーザーが保持できるサインインセッションの最大数を入力します。

リクエストの例

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

ステップ2: 認証フローの開始

最初のrequestStateを取得して、認証フローを開始します。

リクエストの例

cURL形式のリクエストの例を次に示します:

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

レスポンスの例

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

レスポンスに含まれる新しいkeepMeSignedInEnabled属性に注意してください。これは、このアイデンティティ・ドメインおよびアプリケーションがKMSIをサポートしていることを示します。カスタム・インタフェースがある場合は、この属性を使用して、サインイン・ページに「サインイン状態を保持」オプションを表示します。

ステップ3: KMSIを使用したユーザーの資格証明の送信

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

カスタムインタフェースがある場合は、この属性を使用してKMSIオプションを表示し、チェックボックスのステータス(オンまたはオフ)をチェックして、このパラメータを送信してKMSIセッションを作成します。

レスポンスの例

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

レスポンスの例では、kmsiToken属性に注意してください。このトークンは、ユーザーが再度サインインしなくても、将来すべてのアプリケーションにアクセスするために使用できます。

ステップ4: セッションの有効期限後にauthnTokenを再発行します

リクエストの例

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

レスポンスの例

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

新しいauthFactor、appNameおよびkmsiTokenがリクエストで送信される操作credSubmitに注意してください。SSOはリクエストを評価し、レスポンスでauthnTokenおよび最新の更新されたkmsiTokenを返します。これはリフレッシュされたkmsiTokenであり、既存のトークンを置き換えます。このリフレッシュされたkmsiTokenを次のリクエストに含める必要があります。

ステップ5: KMSIおよびMFAフローを使用したユーザーの資格証明の送信

ステップ2: 認証フローの開始から、/sso/v1/sdk/authenticateでGETを開始します。

レスポンスの例

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

レスポンスの例

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

デバイスでワンタイム・パスコード(OTP)を取得したら、リクエストにOTPを追加します。

リクエストの例

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

レスポンスには、authTokenおよびkmsiTokenが含まれます。これはリフレッシュされたkmsiTokenです。

レスポンスの例

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

ステップ6: MFAファクタが設定されている場合のセッション有効期限後のauthnTokenの再発行

ユーザーがkmsiTokenを使用してサインインしようとし、2番目のファクタが構成されている場合、ユーザーは常に2番目のファクタの認証を求められます。認証が成功した後にのみ、authnTokenおよびkmsiTokenがレスポンスで送信されます。

リクエストの例

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

レスポンスには、リフレッシュされたKMSIトークンとMFAチャレンジが含まれます。

レスポンスの例

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

同じ手順を繰り返して、デバイスでOTPの入力を再度要求します。次のペイロードにOTPを指定します。レスポンスにはauthnTokenを含める必要があります。

リクエストの例

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

レスポンスの例

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

kmsiToken requestStateを使用したフロー

このフローは、KMSIトークンを所有しているがKMSI Cookieを所有していない場合にブラウザ・コンテキストをサポートするために使用します。セッションの有効期限が切れた後、アプリケーションはredirectUrl、state、nonceなどを使用してアイデンティティ・システムに認可コールを実行します。このレスポンスでは、アイデンティティ・システムはloginCtx内のrequestStateを返します。このrequestStateは、KMSIトークンとともに渡され、セッションの拡張後に必要なアプリケーションをリダイレクトします。

リクエストの例

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

レスポンスの例

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

/sso/v1/sdk/secure/sessionへの変更

KMSIでは、/sso/v1/sdk/secure/sessionエンドポイントに新しい属性を追加する必要があります。カスタム・ログイン・アプリケーションからエンドポイントにkmsiTokenを送信する必要があります。

/authorize開始コールのペイロード署名

1. ユーザーがアイデンティティ・ドメインで保護されているWebアプリケーションにアクセスすると、アプリケーションURL (https://example.com/home/pages/profileなど)を入力します。
2. アイデンティティ・ドメインの/authorizeコールにリダイレクトされます。
3. アイデンティティ・ドメインは、ユーザーをカスタマがデプロイしたカスタム・サインイン・ページにリダイレクトします。
4. 顧客がホストするサインイン・アプリケーションは、入力パラメータを収集し、loginCtx入力をデコードします。
5. 復号化された入力パラメータは、GET /sso/v1/sdk/authenticateコールと一致します。
6. ペイロードには、KMSIが有効かどうかを識別するためのkeepMeSignedInEnabledが含まれます。
7. カスタム・ログイン・アプリケーションは、資格証明を収集してアイデンティティ・ドメインに送信します。
8. アイデンティティ・ドメインは資格証明を検証し、kmsiTokenおよびauthnTokenを発行します。
9. カスタム・ログイン・アプリケーションは、/sso/v1/sdk/secure/sessionエンドポイントのコール中にauthnTokenおよびkmsiTokenを使用します。セキュア・エンドポイントの新しい構文については、「/sso/v1/sdk/secure/sessionの変更」を参照してください。
10. アイデンティティ・ドメインはauthnToken、kmsiTokenを検証し、アイデンティティ・システムがSSOセッションCookieおよびKMSI Cookieを発行します。
11. セッション中に、KMSI Cookieが検証され、資格証明を再入力せずにセッションが拡張されます。