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

このユースケースでは、アイデンティティ・ドメインREST APIを使用してアイデンティティ・ドメインのカスタム・サインイン・ページを開発するステップバイステップの例を示します。

ノート

この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
ノート

この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。

認証APIは、状態マシンの概念に基づいています。リクエスト・レスポンスでは、ユーザーがブラウザでサードパーティCookieを有効にする必要なく、次に実行する必要がある操作をアプリケーション・クライアントに通知します。サードパーティCookieは、特にエンド・ユーザーの動作に対する制御を強制できないB2Cアプリケーションで問題を引き起こす可能性があります。各リクエスト・レスポンスで提供されるrequestStateは、次のリクエストで使用され、リクエストの処理に必要な情報をクライアントに提供してから、許可される次の操作セットを提供します。

認証APIでは、次のことができます:
  • プライマリ認証としてのユーザーのユーザー名とパスワード資格証明を検証する際に役立ちます。
  • 管理者によって有効化されたMFAファクタへのユーザー登録のサポート
  • 時間ベースのワンタイム・パスコードやSMSパスコードの使用などの追加の検証を必要とすることで、多要素認証(MFA)を使用したパスワードベース認証のセキュリティを強化します。
  • 認証用の外部SAMLまたはソーシャル・アイデンティティ・プロバイダをユーザーが選択できるようにします。
ノート

広範な認証のユースケース例は、アイデンティティ・ドメイン認証API Postmanコレクションを参照してください。GitHub内のidcs-authn-api-rest-clientsフォルダから、コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

オンデマンドMFA APIステータス・コードの認証

外部SAMLアイデンティティ・プロバイダによる認証

このユースケースでは、アイデンティティ・ドメインを使用して、外部SAMLアイデンティティ・プロバイダ(IdP)を使用した認証を行うステップについて説明します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。
この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:

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

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

バックグラウンドでは、認証リクエストはアイデンティティ・ドメインによってインターセプトされ、/authorizeエンドポイントにリダイレクトされます。これにより、認証プロセスが開始されます。アイデンティティ・ドメインは、デフォルトのサインイン・ページを表示するかわりに、loginCtxおよびsignatureパラメータを含むHTMLフォームを作成してブラウザに送信することで応答します。
ノート

フォーム投稿を受信して2つのパラメータ値を読み取るには、エンドポイントを公開する必要があります。

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>
ブラウザは、フォームをカスタム・サインイン・ページに自動的に送信するためのJavaScriptを含むHTMLコードを受け取ります。loginCtxパラメータはbased64で暗号化されているため、カスタム・サインイン・アプリケーションは次を実行してloginCtxを暗号化する必要があります:
  • base64デコーダを使用してデコードし、暗号化されたバイナリ・データを取得する
  • テナント名を使用して復号化用のキーを生成する
  • キーおよびバイナリ・データを使用してデータを復号化する

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パラメータには、次の重要な属性が含まれます:
  • requestState:認証プロセスの状態。これは、アイデンティティ・ドメインへの将来のPOSTおよびGET、認証APIエンドポイントで使用する必要があります。
  • nextOp: カスタム・サインイン・アプリケーションが実行する必要がある次の操作。
  • nextAuthFactors: サインイン・ページが存在する必要がある可能な認証ファクタ。

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

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

ユーザーは、表示されるカスタム・サインイン・ページから、認証に使用する外部SAML IdPを選択します。カスタム・サインイン・ページでは、選択したIdPに必要な情報をHTMLフォームPOSTとして作成し、/sso/v1/sdk/idpエンドポイントに送信する必要があります。このステップでは、次の属性を含める必要があります:
  • requestState:ステップ1のレスポンスで受信した
  • idpName:ステップ1のレスポンスで受信したIdPの名前
  • idpType:ステップ1のレスポンスで受信したIdPのタイプ(この例では、SAML)
  • idpId:ステップ1のレスポンスで受信したIdPのID
  • appName:クライアントがアクセスするアプリケーションの名前
  • clientID:ブラウザがアクセスを試みているアプリケーションのクライアントID
  • authorization:セキュアなIdPに必要なパラメータ

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

次のJavaScriptの例は、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");
};

リクエストの例

/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をアイデンティティ・ドメインが作成します。次に、カスタム・サインイン・ページでセッションが作成されます。「セッションの作成」を参照してください。

ソーシャル・アイデンティティ・プロバイダによる認証

このユースケースでは、アイデンティティ・ドメインを使用して、FacebookやGoogleなどのソーシャル・アイデンティティ・プロバイダ(IdP)を使用した認証を行うステップについて説明します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。
この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:

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

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

バックグラウンドでは、認証リクエストはアイデンティティ・ドメインによってインターセプトされ、/authorizeエンドポイントにリダイレクトされます。これにより、認証プロセスが開始されます。アイデンティティ・ドメインは、デフォルトのサインイン・ページを表示するかわりに、loginCtxおよびsignatureパラメータを含むHTMLフォームを作成してブラウザに送信することで応答します。
ノート

フォーム投稿を受信して2つのパラメータ値を読み取るには、エンドポイントを公開する必要があります。

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>
ブラウザは、フォームをカスタム・サインイン・ページに自動的に送信するためのJavaScriptを含むHTMLコードを受け取ります。loginCtxパラメータはbased64で暗号化されているため、カスタム・サインイン・アプリケーションは次を実行してloginCtxを暗号化する必要があります:
  • base64デコーダを使用してデコードし、暗号化されたバイナリ・データを取得する
  • テナント名を使用して復号化用のキーを生成する
  • キーおよびバイナリ・データを使用してデータを復号化する

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パラメータには、次の重要な属性が含まれます:
  • requestState:認証プロセスの状態。これは、アイデンティティ・ドメインへの将来のPOSTおよびGET、認証APIエンドポイントで使用する必要があります。
  • nextOp: カスタム・サインイン・アプリケーションが実行する必要がある次の操作。
  • nextAuthFactors: サインイン・ページが存在する必要がある可能な認証ファクタ。

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

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

ユーザーは、表示されるカスタム・サインイン・ページから、認証に使用するソーシャルIdPを選択します。カスタム・サインイン・ページでは、選択したIdPに必要な情報をHTMLフォームPOSTとして作成し、/sso/v1/sdk/idpエンドポイントに送信する必要があります。このステップでは、次の属性を含める必要があります:
  • requestState:ステップ1のレスポンスで受信した
  • idpName:ステップ1のレスポンスで受信したIdPの名前
  • idpType:ステップ1のレスポンスで受信したIdPのタイプ(この例では、ソーシャル)
  • idpId:ステップ1のレスポンスで受信したIdPのID
  • appName:クライアントがアクセスするアプリケーションの名前
  • clientID:ブラウザがアクセスを試みているアプリケーションのクライアントID
  • authorization:セキュアなIdPに必要なパラメータ

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

次のJavaScriptの例は、ソーシャル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");
};

リクエストの例

/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をアイデンティティ・ドメインが作成します。次に、カスタム・サインイン・ページでセッションが作成されます。「セッションの作成」を参照してください。

外部SAMLアイデンティティ・プロバイダおよびMFAによる認証

このユースケースでは、アイデンティティ・ドメインを使用して、外部SAMLアイデンティティ・プロバイダ(IdP)およびマルチファクタ認証(MFA)を使用した認証を行うステップについて説明します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。
この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:

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

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

バックグラウンドでは、認証リクエストはアイデンティティ・ドメインによってインターセプトされ、/authorizeエンドポイントにリダイレクトされます。これにより、認証プロセスが開始されます。アイデンティティ・ドメインは、デフォルトのサインイン・ページを表示するかわりに、loginCtxおよびsignatureパラメータを含むHTMLフォームを作成してブラウザに送信することで応答します。
ノート

フォーム投稿を受信して2つのパラメータ値を読み取るには、エンドポイントを公開する必要があります。

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>
ブラウザは、フォームをカスタム・サインイン・ページに自動的に送信するためのJavaScriptを含むHTMLコードを受け取ります。loginCtxパラメータはbased64で暗号化されているため、カスタム・サインイン・アプリケーションは次を実行してloginCtxを暗号化する必要があります:
  • base64デコーダを使用してデコードし、暗号化されたバイナリ・データを取得する
  • テナント名を使用して復号化用のキーを生成する
  • キーおよびバイナリ・データを使用してデータを復号化する

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パラメータには、次の重要な属性が含まれます:
  • requestState:認証プロセスの状態。これは、アイデンティティ・ドメインへの将来のPOSTおよびGET、認証APIエンドポイントで使用する必要があります。
  • nextOp: カスタム・サインイン・アプリケーションが実行する必要がある次の操作。
  • nextAuthFactors: サインイン・ページが存在する必要がある可能な認証ファクタ。

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

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

ユーザーは、表示されるカスタム・サインイン・ページから、認証に使用する外部IdPを選択します。カスタム・サインイン・ページでは、選択したIdPに必要な情報をHTMLフォームPOSTとして作成し、/sso/v1/sdk/idpエンドポイントに送信する必要があります。このステップでは、次の属性を含める必要があります:
  • requestState:ステップ1のレスポンスで受信した
  • idpName:ステップ1のレスポンスで受信したIdPの名前
  • idpType:ステップ1のレスポンスで受信したIdPのタイプ(この例では、SAML)
  • idpId:ステップ1のレスポンスで受信したIdPのID
  • appName:クライアントがアクセスするアプリケーションの名前
  • clientID:ブラウザがアクセスを試みているアプリケーションのクライアントID
  • authorization:セキュアなIdPに必要なパラメータ

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

次のJavaScriptの例は、外部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");
};

リクエストの例

/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
    }
}
loginCtxパラメータには、次の重要な属性が含まれます:
  • requestState:認証プロセスの状態。これは、アイデンティティ・ドメインへの将来のPOSTおよびGET、認証APIエンドポイントで使用する必要があります。
  • nextOp: カスタム・サインイン・アプリケーションが実行する必要がある次の操作。
  • nextAuthFactors: サインイン・ページが存在する必要がある可能な認証ファクタ。

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

次の属性をリクエストで送信する必要があります:
  • op:クライアントが必要とする操作の種類をサーバーに指示します
  • otpCode:ユーザーのデバイスに送信されるコード
  • requestState:ステップ2のレスポンスで受信

リクエストの例

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

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

レスポンスの例

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

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

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

セッションの作成

このユースケースでは、MFAを使用した認証後など、認証後にアイデンティティ・ドメインを使用してセッションを作成する例を示します。

ノート

この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
ノート

この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ノート

認証APIの使用の詳細は、認証APIの使用に関する他のユースケースを参照してください。

クライアントが認証およびMFAを使用して完了し、セッションを作成する必要がある場合は、FORM POSTとしてauthnTokenおよびrequestStateを送信します。このステップでは、最後に受信したレスポンスでcreateSessionnextOp属性値としてリストされ、FORM POSTに次のいずれかの属性が含まれている必要があります。

/sso/v1/sdk/secure/sessionエンドポイントの場合:
  • requestState:最後のレスポンスで受信

    または

  • authnToken:最後のレスポンスで受信

    AND

  • authorization:セキュアなセッションに必要なパラメータ

リクエストの例

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

requestState=value&authorization=<client sign-in access token>
または
authnToken=<value received from a previous response>&authorization=<client sign-in access token>

レスポンスの例

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

最後に受信したレスポンスのnextOpパラメータの値としてcreateSessionがリストされていない場合は、セッションの作成前にトークンの作成が必要になることがあります。createSessionnextOpの値としてリストされている場合sdk/sessionエンドポイントはrequestStateのみを使用して直接コールできます。

リクエストの例

JSON形式の/sso/v1/sdk/authenticateエンドポイントへのトークン・リクエストの例を次に示します:

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

レスポンスの例

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

{
    "authnToken":"eyJraWQiOiJ....4IacnWKSQ",
    "status":"success"
}

サーバーは、その他のファクタ評価が必要ないことを確認します。他の評価が必要ない場合、トークンはレスポンスで送信されます。

ユーザー名とパスワードによる認証

このユースケースでは、アイデンティティ・ドメイン認証APIを使用してユーザーの資格証明で認証するステップ・バイ・ステップの例を示します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

この使用例では、次のステップを使用します。

ステップ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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

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

最初のファクタ(ユーザー名とパスワード)としてユーザーの資格証明を発行します。このステップでは、クライアントに次の属性を含める必要があります:

  • credentials:のユーザー名とパスワード

  • requestState:ステップ1のレスポンスで受信した

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

リクエストの例

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

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

TOU承諾によるユーザー名とパスワードの認証

このユースケースでは、アイデンティティ・ドメイン認証APIを使用して、ユーザーの資格証明とTOU承諾で認証するステップ・バイ・ステップの例を示します。ユーザーが承諾を受け入れると、ユーザーはそのアプリケーション・ページにリダイレクトされます。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

ステップ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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

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

最初のファクタ(ユーザー名とパスワード)としてユーザーの資格証明を発行します。このステップでは、クライアントに次の属性を含める必要があります:
  • credentials:のユーザー名とパスワード

  • requestState:ステップ1のレスポンスで受信した

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

ユーザー名とパスワードが有効な場合、サーバーはユーザーのプロファイルで指定されたロケールで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"
        }
    ]
}

ユーザー名とパスワードおよびMFAによる認証とOTPの返し

このユースケースでは、アイデンティティ・ドメインREST APIを使用して、ユーザーの資格証明およびマルチファクタ認証(MFA)で認証し、暗号化されたOTPをレスポンスで返すステップ・バイ・ステップの例を示します。

ノート

この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダから、アイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

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

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

または、管理者は、APIレスポンスで暗号化されたOTPをコンシューマ・クライアントに返すようにアイデンティティ・ドメインを構成して、コンシューマ・クライアントがOTPを開始したり、ユーザーにOTPを送信できるようにすることもできます。このアプローチの2つの利点は、コンシューミング・クライアントが認証メッセージをカスタマイズし、ビジネス・ニーズに合せて送信者の詳細も変更できることです。レスポンスで暗号化されたOTPを返すようにアイデンティティ・ドメインを構成するには、コンシューミング・クライアントで次のステップを実行する必要があります。
  1. ステップ1: CustomUIアプリケーションの作成

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

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

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

ノート

これらのステップでは、MFAが有効であり、MFAのサインオン・ポリシーが作成されていることを前提としています。「マルチファクタ認証設定の構成」を参照してください。

暗号化と暗号化

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

OTP復号化コード

次のJavaコードを使用して、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: 自己署名証明書のキー・ペアの生成

レスポンスでOTPを受信するには、コンシューマ・クライアントが秘密キーと公開キーのペアを生成し、自己署名証明書を生成して、その証明書をCustomUIアプリケーションにインポートする必要があります。
  • otp-client.conf構成ファイルに次の情報が含まれていることを確認します。次に、秘密キーと公開キーのペアを生成します。
    [ req ]
    encrypt_key = no
    default_bits = 2048
    default_md = sha256
    utf8 = yes
    string_mask = utf8only
    prompt = no
    distinguished_name = user_dn
    [ user_dn ]
    0.organizationName = "Oracle"
    organizationalUnitName = "OCI"
    commonName = "OtpClient"
    
  • 次のコマンドを使用して、自己署名証明書を生成します。
    #generate self signed client certificate
    
    openssl genrsa -out OtpClient.key 2048
    openssl req -new -x509 -days 10000 -key OtpClient.key -out OtpClient.crt  -subj "/CN=Root CA/C=IN/ST=KarnatakaCalifornia/L=Bangalore/O=Oracle"  -config otp-client.conf
    openssl pkcs8 -topk8 -inform PEM -in OtpClient.key -out OtpClientX509Format.key -nocrypt
    

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

自己署名証明書が生成されたら、CustomUIアプリケーションにインポートする必要があります。
  1. Identity Cloud Serviceコンソールで、「ナビゲーション・ドロワー」を展開し、「アプリケーション」CustomUIアプリケーション→「構成」→「クライアント構成」をクリックします。
  2. トラスト・クライアント証明書に自己署名証明書をインポートし、構成を保存します。

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

リクエスト・ペイロード
属性 サポートされる値/サンプル値 複数値 使用量の詳細
userFlowControlledByExternalClient true/false False
このオプションの設定
true
OTPは、指定された暗号化形式でレスポンスに返されます。

ノート: 暗号化に使用される証明書は事前にアプリケーションにアップロードされ、次に示すように、リクエストの例でx5t属性を使用して参照されます。

x5t 文字列/X509 SHA-1証明書サムプリント

指定した場合、サービスは、アップロードされたこの証明書を使用してOTPデータを暗号化します。

ノート: "x5t"属性は、アップロードされた証明書と一致する必要があります。

リクエストの例
{
   "op": "credSubmit",
   "credentials": {
      "username": "test.user",
      "password": "example-password"
   },
   "userFlowControlledByExternalClient": true,
   "x5t": "<certificate thumbprint>",
   "requestState": "{{requestState}}"
}
レスポンス・ペイロード
属性 サポートされる値/サンプル値 複数値 使用量の詳細
otp

マップ

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

レスポンスに存在する場合、属性には、暗号化されたOTPに次の詳細が含まれます。

  • value: 暗号化された値。
  • alg: 暗号化に使用されるアルゴリズム。
  • x5t: SHA-1 X509暗号化に使用される証明書のサムプリント

レスポンスの例

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

認証APIを使用したアクセス・トークンの生成

このユースケースでは、アイデンティティ・ドメインを使用して、認証APIを使用するアクセス・トークンを生成するステップ・バイ・ステップの例を示します。ユーザーは、認証APIを使用して自己アクセス・トークンを介してユーザー情報を取得します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

ユーザーがTOUに関連付けられたアプリケーションにアクセスしようとすると、アイデンティティ・ドメイン・サーバーはアプリケーション名を使用して、このアプリケーションに割り当てられたポリシーをフェッチします。テナント設定に基づいて、サーバーはIDPおよび認証ポリシーを取得し、ユーザーを次のステップに進めます。

ステップ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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

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

このシナリオでは、ユーザーはユーザー資格証明をポストし、authnTokenを取得します。次のものがリクエストに含まれている必要があります:
  • credentials:のユーザー名とパスワード

  • requestState:ステップ1のレスポンスで受信した

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

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

ユーザー名とパスワードおよびMFAによる認証

このユースケースでは、アイデンティティ・ドメインREST APIを使用して、ユーザーの資格証明およびマルチファクタ認証(MFA)で認証するステップ・バイ・ステップの例を示します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

このユース・ケースでは、次のステップを実行します。

ノート

これらのステップでは、MFAが有効であり、MFAのサインオン・ポリシーが作成されていることを前提としています。「マルチファクタ認証設定の構成」を参照してください。

ステップ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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

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

最初のファクタ(ユーザー名とパスワード)としてユーザーの資格証明を発行します。このステップでは、クライアントに次の属性を含める必要があります:

  • credentials:のユーザー名とパスワード

  • requestState:ステップ1のレスポンスで受信した

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

リクエストの例

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

{
   "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}}属性はレスポンスで返されません。

「信頼できるデバイス」設定がテナント・レベルで有効になっており、一致したサインオン・ルール・ルールの「MFA頻度」が「毎回」の場合、{{trustedDeviceSettings}}フィールドが返されますが、{{trustDurationInDays}}値は0として返されます。
"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"
}

ユーザー名とパスワードによる認証およびMFAへの登録

このユースケースでは、アイデンティティ・ドメイン認証APIを使用してユーザーの資格証明で認証し、マルチファクタ認証(MFA)に登録するステップ・バイ・ステップの例を示します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。
この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:
ノート

これらのステップでは、MFAが有効であり、MFAのサインオン・ポリシーが作成されていることを前提としています。「多要素認証設定の構成」を参照してください。

ステップ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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

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

最初のファクタ(ユーザー名とパスワード)としてユーザーの資格証明を発行します。このステップでは、クライアントに次の属性を含める必要があります:

  • credentials:のユーザー名とパスワード

  • requestState:ステップ1のレスポンスで受信した

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

リクエストの例

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

{
   "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要素認証登録の開始

このステップでは、オンライン時間ベースのワンタイム・パスコード(TOTP)登録を開始します。クライアントには次の属性が含まれている必要があります:
  • op:クライアントが必要とする操作の種類をサーバーに指示します

  • authFactor:は、ユーザーが登録する認証ファクタを定義します

  • requestState:ステップ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"
}
レスポンスでは、nextOp値は、次のリクエストでop値として送信できる内容を示します。このユースケースの例では、次のステップでcredSubmitが送信されます。
ノート

contentの値は、常にoraclemobileauthenticator//.で始まります

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

このステップでは、ステップ3のレスポンスで受信したrequestStateのファクタ資格証明を発行します。authFactor属性はrequestStateに含まれるため、リクエスト・ペイロードには含まれないことに注意してください。クライアントには次の属性が含まれている必要があります:
  • op:クライアントが必要とする操作の種類をサーバーに指示します

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

リクエストの例

次の例に、ファクタ資格証明を発行するための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:を受信

リクエストの例

次の例に、JSON形式のPOSTリクエストのコンテンツを示します:
{  
   "op":"createToken",
   "requestState":"{{requestState}}"
}

レスポンスの例

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

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

ユーザー名とパスワードの認証およびアカウント・リカバリへの登録

このユースケースでは、アイデンティティ・ドメイン認証APIを使用してユーザーの資格証明で認証し、アカウント・リカバリに登録するステップ・バイ・ステップの例を示します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。
ノート

これらのステップでは、アカウント・リカバリに対して複数のファクタが有効になっているが、MFA登録が構成されていないことを前提としています。「アカウント・リカバリの構成」および「マルチファクタ認証設定の構成」を参照してください。

ステップ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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

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

最初のファクタ(ユーザー名とパスワード)としてユーザーの資格証明を発行します。このステップでは、クライアントに次の属性を含める必要があります:

  • credentials:のユーザー名とパスワード

  • requestState:ステップ1のレスポンスで受信した

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

リクエストの例

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

{
   "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: ファクタ資格証明の発行

このステップでは、ステップ3のレスポンスで受信したrequestStateのファクタ資格証明を発行します。authFactor属性はrequestStateに含まれるため、リクエスト・ペイロードには含まれないことに注意してください。クライアントには次の属性が含まれている必要があります:
  • op: クライアントが必要とする操作の種類をサーバーに指示します
  • requestState: ステップ3のレスポンスで受信

リクエストの例

次の例に、ファクタ資格証明を発行するための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: 認証トークンの作成

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

リクエストの例

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

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

レスポンスの例

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

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

ユーザー名とパスワードの認証およびアカウント・リカバリとMFAへの登録

このユースケースでは、アイデンティティ・ドメイン認証APIを使用してユーザーの資格証明で認証し、アカウント・リカバリおよびマルチファクタ認証(MFA)に登録するステップ・バイ・ステップの例を示します。

ノート

  • この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。
  • この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。
ヒント

idm-samples GitHubリポジトリ内のidcs-authn-api-rest-clientsフォルダからアイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。
ノート

これらのステップでは、アカウント・リカバリおよびMFAが有効であり、MFAのサインオン・ポリシーが作成されていることを前提としています。「アカウント・リカバリの構成」および「マルチファクタ認証設定の構成」を参照してください。

ステップ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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

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

最初のファクタ(ユーザー名とパスワード)としてユーザーの資格証明を発行します。このステップでは、クライアントに次の属性を含める必要があります:

  • credentials:のユーザー名とパスワード

  • requestState:ステップ1のレスポンスで受信した

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

リクエストの例

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

{
   "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: ファクタ資格証明の発行

このステップでは、ステップ3のレスポンスで受信したrequestStateとファクタ資格証明を発行します。authFactor属性はrequestState に含まれるため、リクエスト・ペイロードには含まれないことに注意してください。クライアントには次の属性が含まれている必要があります:
  • op: クライアントが必要とする操作の種類をサーバーに指示します
  • requestState: ステップ3のレスポンスで受信

リクエストの例

次の例に、ファクタ資格証明を発行するための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: 認証トークンの作成

このステップは、クライアントがアカウント・リカバリ登録を完了し、セッションを作成する必要があることを示しています。サーバーは、他のファクタ評価(ポリシーに定義されているものに応じて)が必要ないことを検証し、トークンを使用して応答するか、適宜応答します。クライアントには次の属性が含まれている必要があります:
  • op: ステップ4のレスポンスでクライアントがrequestStateを受信する操作の種類をサーバーに指示します
  • requestState: ステップ4のレスポンスで受信

リクエストの例

次の例に、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が必要であるため、enrollmentRequiredmfaSettingsの値は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: 認証トークンの作成

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

リクエストの例

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

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:
{
    "authnToken": "{{authnToken}}",
    "status": "success",
    "ecId": "HI^kd1W0000000000"
}

ユーザー名とパスワードによる認証およびサインイン状態を保持

ユーザーが何度もサインインしなくてもアイデンティティ・ドメインにアクセスできるように、サインイン状態を保持(KMSI)を有効にして構成します。

プログラム的なアプリケーションインタフェースを使用してKMSIを設定するには、次の手順を使用します。

この項の内容は、次のとおりです。

開始前

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

KMSIをクラウド・アカウントに対して有効にした後、次のステップを実行して、IAMアイデンティティ・ドメインに対してKMSIを有効にします。
ノート

topでユーザー・インタフェースを使用して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}}
ノート

appNameはオプションです。appNameは、クライアントがアクセスするアプリケーションの名前です。appNameを指定すると、アプリケーションに固有のサインオン・ポリシーが処理され、クライアントは、そのポリシーに基づいて必要なファクタのチャレンジを受けます。

レスポンスの例

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

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

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

リクエスト
  • 操作: POST
  • エンドポイント: /sso/v1/sdk/authenticate

リクエストの例
ノート

リクエストに含まれる新しいkeepMeSignedIn属性に注意してください。この属性は、ユーザーが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を再発行します

リクエスト
  • 操作: POST

  • エンドポイント: /sso/v1/sdk/authenticate

リクエストの例

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

レスポンスの例

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

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

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

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

リクエスト
  • 操作: POST

  • エンドポイント: /sso/v1/sdk/authenticate

レスポンスの例

{
    "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がレスポンスで送信されます。

リクエスト
  • 操作: POST

  • エンドポイント: /sso/v1/sdk/authenticate

リクエストの例

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

リクエスト
  • 操作: POST

  • エンドポイント: /sso/v1/sdk/authenticate

APIは、KMSIをauthFactorとしてサポートし、KMSIをrequestStateパラメータで認証します。これにより、requestStateを持つkmsiTokenloginCtxから取得できます。
ノート

requestStatekmsiTokenが同じアプリケーションのものではない場合、リクエストは拒否されます。

リクエストの例

{
    "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を送信する必要があります。

リクエストの例 レスポンスの例

authnTokenまたはrequestState

authorization

kmsiToken
新しいフォーム投稿変数kmsiTokenauthnTokenまたはrequestStateは、SSOセッションCookieおよびKMSI Cookieとともにアプリケーションにリダイレクトされます。

/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. アイデンティティ・ドメインはauthnTokenkmsiTokenを検証し、アイデンティティ・システムがSSOセッションCookieおよびKMSI Cookieを発行します。
  11. セッション中に、KMSI Cookieが検証され、資格証明を再入力せずにセッションが拡張されます。