ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2.2) for All Platforms
B69533-09
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

43 ソーシャル・アイデンティティの構成

Mobile and Socialには、ソーシャル・アイデンティティを構成するためのGUIが用意されています。(バージョン11.1.2.2より前は、ソーシャル・アイデンティティはインターネット・アイデンティティ・サービスと呼ばれていました。)この章では、Oracle Access Managementコンソールを使用して、モバイル・サービスを構成する方法について説明します。この章の内容は、次のとおりです。


注意:

ソーシャル・アイデンティティは、WLSTを使用してコマンド行から構成することもできます。Mobile and SocialのWLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

43.1 ソーシャル・アイデンティティの構成ページを開く

Oracle Access Managementコンソールでソーシャル・アイデンティティの構成ページを開くには、次の手順を実行します。

  1. Oracle Access Managementコンソールにログインします。

    「起動パッド」が開きます。

  2. 「モバイル・セキュリティおよびソーシャルID」ペインの「ソーシャル・アイデンティティ」をクリックします。

    「ソーシャル・アイデンティティ」タブが開きます。

  3. 「OAuthアイデンティティ・ドメイン」をクリックして構成します。

    「Mobile and Socialへようこそ - ソーシャル・アイデンティティ」ページが開きます。

43.2 ソーシャル・アイデンティティの構成の理解

「Mobile and Socialへようこそ - ソーシャル・アイデンティティ」の構成ページはいくつかの個別のパネルに分割されていて、パネルの左上隅の矢印ボタンをクリックして、開いたり、折りたたんだりできます。次の各項では、ソーシャル・アイデンティティの各パネルについて詳細に説明します。

43.2.1 ソーシャル・アイデンティティ・プロバイダの理解

ソーシャル・アイデンティティ・プロバイダ・パネルは、Google、Facebook、Twitterなどのアイデンティティ・プロバイダの(事前構成されている)構成の詳細を編集するために使用します。これらの設定は、一度確立した後はそれほど頻繁に変更する必要はありません。

Javaインタフェースoracle.security.idaas.rp.spi.IdentityProviderを実装することで、ユーザー自身を追加するソーシャル・アイデンティティ・プロバイダの構成の詳細を定義することもできます。ソーシャル・アイデンティティ・プロバイダの追加の詳細は、『Oracle Access Management開発者ガイド』のMobile and Socialサーバーの機能の拡張に関する項を参照してください。

ソーシャル・アイデンティティ・プロバイダの詳細は、第43.3項「ソーシャル・アイデンティティ・プロバイダの定義」を参照してください。

43.2.2 サービス・プロバイダ・インタフェースの理解

サービス・プロバイダ・インタフェースは、指定したアプリケーション・プロファイルの認証フローを制御する一連のルールを指します。Mobile and Socialは、次のサービス・プロバイダ・インタフェースを提供します。

  • DefaultServiceProviderInterface: Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーションのサポートを提供します。

  • OAMServiceProviderInterface: Access Managerサービスで実行されるWebアプリケーションのサポートを提供します。

サービス・プロバイダ・インタフェースの詳細は、第43.4項「サービス・プロバイダ・インタフェースの定義」を参照してください。


注意:

Java開発者は、1つ以上のアイデンティティ・プロバイダ・インタフェース・コントラクトのカスタム実装を作成できます。「サービス・プロバイダ・インタフェース」セクションは、開発者が作成したカスタム・サービス・プロバイダを追加する必要がある場合にのみ使用します。

43.2.3 アプリケーション・プロファイルの理解

アプリケーション・プロファイルでは、Mobile and Socialサーバー上のソーシャル・アイデンティティ・プロバイダ・サービスを使用するアプリケーションを定義します。このパネルを使用して、モバイル・アプリケーション、Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーション、およびAccess Managerと統合されるWebアプリケーションが、ソーシャル・アイデンティティを使用するように構成します。

  • WebアプリケーションがAccess Managerと統合されていない場合は、ソーシャル・アイデンティティのログイン・ページをWebアプリケーションと統合します。詳細は、『Oracle Access Management開発者ガイド』の「ソーシャル・アイデンティティ・クライアントSDKを使用したアプリケーションの開発」の章を参照してください。

  • WebアプリケーションがAccess Managerに統合されている場合は、OAMApplicationという名前の事前構成済のアプリケーション・プロファイルを編集します。Oracle Access Managementのインストール時に、Access ManagerとMobile and Socialを同時にインストールすると、両方の製品が信頼されたパートナとして登録され、事前構成済のアプリケーション・プロファイルが含まれます。そのため、Access Managerとソーシャル・アイデンティティに統合されているWebアプリケーションを統合するために、コードを記述する必要はありません。Mobile and Socialに組み込まれているOAMApplicationアプリケーション・プロファイルは、Access Managerと連動するように事前構成済であり、わずかな構成変更を実行するだけで、使用している環境で動作するようになります。

アプリケーション・プロファイルの詳細は、第43.5項「アプリケーション・プロファイルの定義」を参照してください。

43.3 ソーシャル・アイデンティティ・プロバイダの定義

ソーシャル・アイデンティティ・プロバイダは、Google、Facebook、Twitterなどのアイデンティティ・プロバイダについての構成詳細を収集します。ソーシャル・アイデンティティ・プロバイダの作成後に、その設定を変更する必要はほとんどありません。次の各項では、ソーシャル・アイデンティティ・プロバイダの作成、変更および削除について説明します。

43.3.1 ソーシャル・アイデンティティ・プロバイダの作成

ソーシャル・アイデンティティ・プロバイダもWebLogic Scripting Toolを使用して作成できます。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

  1. Oracle Access Managementコンソールで、「ソーシャル・アイデンティティ」ホーム・ページを開きます(第43.1項「ソーシャル・アイデンティティの構成ページを開く」を参照)。

  2. ホーム・エリアのソーシャル・アイデンティティ・プロバイダ・パネルで「作成」をクリックします。

    「新規ソーシャル・アイデンティティ・プロバイダの作成」構成ページが表示されます。

  3. ソーシャル・アイデンティティ・プロバイダのプロパティに値を入力します。

    • 名前: この認証サービス・プロバイダに一意の名前を入力します。

    • 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

    • ソーシャル・アイデンティティ・プロバイダ・プロトコル: ドロップダウン・メニューからアイデンティティ・プロバイダ・プロトコルを選択します。

      • OpenID

      • OAuth

      • カスタム

      「カスタム」を選択すると、カスタム・アイデンティティ・プロバイダを構成できます。ここでの選択内容により、表示される「プロトコル属性」パネルと「返されたユーザー属性」パネルは、そのソーシャル・アイデンティティ・プロバイダ(OpenIDまたはOAuth)で使用する認証プロトコルに特有のプロパティを反映するように変更されます。

    • 実装クラス: このフィールドには、ソーシャル・アイデンティティ・プロバイダ・プロトコルの選択に基づいて、それに該当するプロバイダ固有のJavaインタフェースoracle.security.idaas.rp.spi.IdentityProviderの実装が移入されます。(「カスタム」の場合は、そのアイデンティティ・プロバイダと通信する該当の実装クラスを入力します。)Mobile and Socialサーバーは、この情報を使用して、ソーシャル・アイデンティティ・プロバイダと通信します。

  4. 「プロトコル属性」のプロパティに値を入力します。この値は、前の手順で選択したソーシャル・アイデンティティ・プロバイダで使用するプロトコル「OpenID」(表43-1)または「OAuth」(表43-2)に基づいて決定します。(「カスタム」の場合、カスタム・プロバイダに必要な値と、使用される認証プロトコルに関連する値をすべて追加します。)

    • OpenIDプロトコルを実装するアイデンティティ・プロバイダに必要になる値を指定します(表43-1を参照)。

      表43-1 OpenIDプロトコルの属性

      名前 注意

      Yadisエンドポイント

      HTTPまたはHTTPSの絶対URLになります

      このアイデンティティ・プロバイダのOpenID認証プロトコル・メッセージを受け入れる、公開URLを入力します。Mobile and Socialは、このURLを使用して、ユーザー認証リクエストを作成します。

      ハッシュ・アルゴリズム

      • SHA256は、256ビット長の鍵アルゴリズムです

      • SHA1は、160ビット長の鍵アルゴリズムです

      • なし

      署名アルゴリズムを選択します。Mobile and Socialによって、この値が内部で使用されて、アイデンティティ・プロバイダと通信するためのセッション・タイプおよびアソシエーション・タイプ・プロパティが構成されます。

      認証ポリシー

      ユーザーの認証時、OpenIDプロバイダで認証ポリシーを適用することを要求する場合は「はい」を選択します。それ以外の場合は、「いいえ」を選択します。

      PAPE (Provider Authentication Policy Extension)の使用により、Web開発者は、アイデンティティ・プロバイダからユーザーにパスワードの入力を再度要求することなどフローに対するその他の変更を要求できます。

      認証ポリシー最大期間

      0秒以上の値を指定します。パスワードの再入力の要求を強制するには、0を指定します。

      アクティブに認証を受けていないユーザーが、要求された認証ポリシーを使用して認証を受けることが必要になる前にログイン・セッションを使用できる最長時間を秒単位で入力します。このパラメータを使用すると、アイデンティティ・プロバイダへのユーザーのログイン・セッションが最新であることを確実にできます。

      優先認証ポリシー


      ユーザーの認証時、アイデンティティ・プロバイダが満たす必要がある認証ポリシーを表す0個以上のURIを空白で区切って入力します。例:

      http://schemas.openid.net/pape/policies/2007/06/phishing-resistant

      http://schemas.openid.net/pape/policies/2007/06/multi-factor


    • OAuthプロトコルを実装するアイデンティティ・プロバイダに必要になる値を指定します(表43-2を参照)。

      表43-2 OAuthプロトコルの属性

      名前 注意

      認可URL

      アイデンティティ・プロバイダの公開OAuth認可URLです。アイデンティティ・プロバイダが公開OAuth URLを変更したときには、それに合せて、この値を更新します。

      アイデンティティ・プロバイダによってリクエスト・トークンが返された後、Mobile and SocialによってユーザーがこのURLに誘導されます(「リクエスト・トークンURL」を参照してください)。アイデンティティ・プロバイダによってユーザーのアイデンティティが検証され、ユーザーは、ユーザーの保護されている情報をMobile and Socialサーバーに解放する権限をアイデンティティ・プロバイダに付与します。

      アクセス・トークンURL

      アイデンティティ・プロバイダの公開アクセス・トークンURLを入力します。

      ユーザーがリクエスト・トークンを(認可URLを使用して).認可した後、Mobile and SocialによってこのURLが使用されてアイデンティティ・プロバイダにアクセス・トークンが要求されます。

      リクエスト・トークンURL

      アイデンティティ・プロバイダの公開リクエスト・トークンURLを入力します。(Facebookには適用されません。)

      Mobile and Socialは、このURLを使用して、アイデンティティ・プロバイダからリクエスト・トークンを取得します。アイデンティティ・プロバイダによってリクエスト・トークンが付与された後、Mobile and Socialサーバーによってユーザーがアイデンティティ・プロバイダの認可URLに誘導されます。(RFC 5849「The OAuth 1.0 Protocol」request tokenおよびrequest secretという用語は、temporary credentialsという用語にかわりました。)

      プロファイルURL

      アイデンティティ・プロバイダの公開プロファイルURLを入力します。

      Mobile and Socialは、このURLを使用して、OAuthアクセス・トークンに基づいてユーザー属性を要求します。

      コンシューマ・キー

      Mobile and Socialサーバーが、それ自体をアイデンティティ・プロバイダに識別させるために使用する値を入力します。

      アイデンティティ・プロバイダからコンシューマ・キーを要求する方法の詳細は、第43.3.3項「OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成」を参照してください。

      コンシューマ・シークレット

      コンシューマ・キーの所有権を確立するためにMobile and Socialサーバーが使用するシークレットを入力します。

      アイデンティティ・プロバイダからコンシューマ・シークレットを要求する方法の詳細は、第43.3.3項「OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成」を参照してください。

      サーバー時間同期

      Mobile and Socialサーバーとリモート・アイデンティティ・プロバイダの時間が同期されていない場合は、リモート・プロバイダにリクエストを送信するときに現在のサーバー時刻に追加するスキューを分単位で入力します。このフィールドには、正と負の両方の整数を入力できます。

      通常、LinkedInでは、同期しているサーバー時刻値が必要とされます。FacebookやTwitterには適用されません。

      「属性名」列に、OpenIDアイデンティティ・プロバイダによって返される属性名に割り当てるローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、Mobile and Socialサーバーがアイデンティティ・プロバイダにユーザー・データを要求できるURLを入力します。

      「属性名」列に、アイデンティティ・プロバイダがサポートしていない属性を追加した場合、それらの属性は、Mobile and Socialで使用できません。


  5. 「返されたユーザー属性」パネルに値を追加します。この値は、前の手順で選択したソーシャル・アイデンティティ・プロバイダのプロトコル「OpenID」、「OAuth」または「カスタム」に基づいて決定します。

    • OpenID: 「属性名」列に、アイデンティティ・プロバイダが返す属性名に割り当てる、ローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、Mobile and Socialサーバーがアイデンティティ・プロバイダにユーザー・データを要求できるURLを入力します。「属性名」列に、アイデンティティ・プロバイダがサポートしていない属性を追加した場合、それらの属性は、Mobile and Socialで使用できません。表43-3「Googleが返すユーザー属性」表43-4「Yahooが返すユーザー属性」に、GoogleおよびYahooがサポートするユーザー属性を示します。

      表43-3 Googleが返すユーザー属性

      属性 説明

      country

      ユーザーの母国を要求します。次のように設定する必要があります。http://axschema.org/contact/country/home

      email

      ユーザーのGmailアドレスを要求します。次のように設定する必要があります。

      http://axschema.org/contact/email

      firstname

      ユーザーの名前を要求します。次のように設定する必要があります。

      http://axschema.org/namePerson/first

      language

      ユーザーの優先言語を要求します。次のように設定する必要があります。

      http://axschema.org/pref/language

      lastname

      ユーザーの姓を要求します。次のように設定する必要があります。

      http://axschema.org/namePerson/last


      表43-4 Yahooが返すユーザー属性

      属性 説明

      gender

      ユーザーの性別を要求します。次のように設定する必要があります。

      http://axschema.org/person/gender

      email

      ユーザーの電子メール・アドレスを要求します。次のように設定する必要があります。

      http://axschema.org/contact/email

      fullname

      ユーザーの姓名を要求します。次のように設定する必要があります。

      http://axschema.org/namePerson

      language

      ユーザーの優先言語を要求します。次のように設定する必要があります。

      http://axschema.org/pref/language

      nickname

      ユーザーの希望する名前を要求します。次のように設定する必要があります。

      http://axschema.org/namePerson/friendly

      Timezone

      ユーザーの優先タイムゾーンを要求します。次のように設定する必要があります。

      http://axschema.org/pref/timezone


    • OAuth: OAuthアイデンティティ・プロバイダが返すユーザー属性を指定します。「属性名」列に、アイデンティティ・プロバイダによって返される属性名に対応するローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、アイデンティティ・プロバイダ属性名を入力します。OAuthプロバイダの場合、「属性名」値と「属性スキーマ名」 値は、通常、同じです。


      注意:

      LinkedInは、ユーザー・アイデンティティ属性をMobile and Socialに返すときに電子メール・アドレスも暗号化されていないログインIDも返しません。LinkedInからのアイデンティティ属性を使用して、ユーザーの登録フォームに事前移入する場合は、この制限に注意してください。

      表43-5「Foursquareが返すユーザー・プロファイル属性」表43-6「Windows Liveが返すユーザー・プロファイル属性」に、FoursquareおよびWindows Liveがサポートするユーザー属性を示します。

      表43-5 Foursquareが返すユーザー・プロファイル属性

      属性 説明

      id

      ユーザーのIDを要求します。

      firstname

      ユーザーの名前を要求します。

      lastname

      ユーザーの姓を要求します。

      contact.email

      ユーザーの電子メール・アドレスを要求します。

      homecity

      ユーザーの所在地を要求します。

      gender

      ユーザーの性別を要求します。

      photo

      ユーザーの写真を要求します。


      表43-6 Windows Liveが返すユーザー・プロファイル属性

      属性 説明

      id

      ユーザーのIDを要求します。

      first_name

      ユーザーの名前を要求します。

      last_name

      ユーザーの姓を要求します。

      name

      ユーザーの名前を要求します。

      link

      ユーザーのリンクを要求します。

      email.preferred

      ユーザーの優先電子メール・アドレスを要求します。

      gender

      ユーザーの性別を要求します。

      locale

      ユーザーのローカルを要求します。

      updated_time

      更新時間を要求します。


    • カスタム: 「属性名」列に、カスタム・アイデンティティ・プロバイダが返す属性名に割り当てる、ローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、Mobile and Socialサーバーがアイデンティティ・プロバイダにユーザー・データを要求できるURLを入力します。

  6. 「作成」をクリックして、ソーシャル・アイデンティティ・プロバイダ構成オブジェクトを作成します。

43.3.2 ソーシャル・アイデンティティ・プロバイダの編集または削除

ソーシャル・アイデンティティ・プロバイダを編集または削除するには、パネルでプロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。属性の説明は、第43.3.1項「ソーシャル・アイデンティティ・プロバイダの作成」を参照してください。

43.3.3 OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成

次の各項では、OAuthプロトコルをサポートするソーシャル・アイデンティティ・プロバイダ用のコンシューマ・キーとコンシューマ・シークレットの生成方法について説明します。


注意:

この項の手順は、このドキュメントの公開日の時点で正確です。Facebook、TwitterおよびLinkedInのWebサイトを使用したコンシューマ・キーおよびコンシューマ・シークレットの作成に必要な手順は、常に変更される可能性があります。

43.3.3.1 Facebook用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、Facebook用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

  1. 次のURLをWebブラウザで開きます。

    https://developers.facebook.com/apps

  2. 「Create New App」をクリックします。

  3. 「Create New App」フォームに入力します。

    Facebookによりアプリケーションが作成され、それに一意のアプリケーションIDおよびアプリケーション・シークレットが割り当てられます。

  4. 「Basic Info」セクションに情報を入力します。

    「Select how your application integrates with Facebook」セクションで、「Website with Facebook Login」を選択します。

  5. 「Site URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。例:

    http://OAM-Hosted-Machine: Port/

  6. 「Save Changes」をクリックします。

  7. 第43.3.2項の説明に従って、Mobile and Socialコンソールから、ソーシャル・アイデンティティ・プロバイダ→「フェイスブック」構成ページを開きます。

  8. 「コンシューマ・キー」フィールドにアプリケーションIDを、「コンシューマ・シークレット」フィールドにアプリケーション・シークレットを貼り付けます。

    「適用」をクリックして、変更を保存します。

43.3.3.2 Twitter用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、Twitter用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

  1. 次のURLをWebブラウザで開きます。

    https://dev.twitter.com/apps/new

  2. 「Create an application」フォームに入力します。

    「Callback URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。例:

    http://OAM-Hosted-Machine: Port/oic_rp/return

    Twitterによりアプリケーションが作成され、それに一意のコンシューマ・キーおよびコンシューマ・シークレットが割り当てられます。

  3. (オプション)自分のTwitterアプリケーションを必要に応じて構成し、変更内容を保存します。

  4. 第43.3.2項の説明に従って、Mobile and Socialコンソールから、ソーシャル・アイデンティティ・プロバイダ→「ツイッター」構成ページを開きます。

  5. 「コンシューマ・キー」フィールドにコンシューマ・キーを、「コンシューマ・シークレット」フィールドにコンシューマ・シークレットを貼り付けます。

    「適用」をクリックして、変更を保存します。

43.3.3.3 LinkedIn用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、LinkedIn用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

  1. 次のURLをWebブラウザで開きます。

    https://www.linkedin.com/secure/developer?newapp=

  2. 「Add New Application」フォームに入力します。

    「OAuth User Agreement」セクションの「OAuth Redirect URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。例:

    http://OAM-Hosted-Machine:Managed Server Port/

  3. 「Add Application」をクリックします。

    LinkedInによってアプリケーションが作成され、それに一意のAPIキーおよびシークレット・キーが割り当てられます。

  4. 第43.3.2項の説明に従って、Mobile and Socialコンソールから、ソーシャル・アイデンティティ・プロバイダ→「LinkedIn」構成ページを開きます。

  5. 「コンシューマ・キー」フィールドにAPIキーを、「コンシューマ・シークレット」フィールドにシークレット・キーを貼り付けます。

    「適用」をクリックして、変更を保存します。

43.3.3.4 Foursquare用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、Foursquare用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

  1. 次のURLをWebブラウザで開きます。

    https://foursquare.com/developers/register

  2. アプリケーション名とWebサイトURLを入力します。

  3. 「コールバックURL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。

    例:

    http://OAM-Hosted-Machine:Port/

  4. 変更を保存します。

    表示される画面から、「クライアントID」のコードと「クライアント・シークレット」のコードをコピーします。

  5. 第43.3.2項の説明に従って、Mobile and Socialコンソールから、ソーシャル・アイデンティティ・プロバイダ→「Foursquare」構成ページを開きます。

  6. 「コンシューマ・キー」フィールドにクライアントIDを、「コンシューマ・シークレット」フィールドにクライアント・シークレットを貼り付け、「適用」をクリックして、変更を保存します。

43.3.3.5 Windows Live用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、Windows Live用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

  1. 次のURLをWebブラウザで開きます。

    https://manage.dev.live.com/

  2. Windows Live IDとパスワードでサインインします。

  3. 「アプリケーションの作成」をクリックします。

  4. アプリケーション名を入力します。

  5. 使用条件に目を通して、同意します。

    表示される画面から、「クライアントID」のコードと「クライアント・シークレット」のコードをコピーします。

  6. 第43.3.2項の説明に従って、Mobile and Socialコンソールから、ソーシャル・アイデンティティ・プロバイダ→「Windows Live」構成ページを開きます。

  7. 「コンシューマ・キー」フィールドにクライアントIDを、「コンシューマ・シークレット」フィールドにクライアント・シークレットを貼り付け、「適用」をクリックして、変更を保存します。

43.3.3.6 Google用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、Google用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

  1. 次のURLをWebブラウザで開きます。

    https://code.google.com/apis/console

  2. 「APIと認証」(左側)で、「資格証明」をクリックします。

  3. 「OAuth」で、「新しいクライアントIDを作成」をクリックします。

    クライアントIDの作成フォームが開きます。

  4. フォームに入力して送信します。

    新しいクライアントIDおよびシークレットが追加されます。

  5. 第43.3.2項の説明に従って、Mobile and Socialコンソールから、「ソーシャル・アイデンティティ・プロバイダ」→「Google」構成ページを開きます。

  6. 「コンシューマ・キー」フィールドにクライアントIDを、「コンシューマ・シークレット」フィールドにクライアント・シークレットを貼り付けます。

    「適用」をクリックして、変更を保存します。

43.3.4 Facebookソーシャル・アイデンティティ・プロバイダのトラブルシューティング

この項では、Facebookソーシャル・アイデンティティ・プロバイダに影響する、既知の構成問題について説明します。

43.3.4.1 Facebookとの互換性があるWebLogic Serverの構成

次の手順に従って、FacebookをサポートするようにWebLogic Serverを構成します。

  1. WebLogicコンソールを開きます。

    http://host:port/console

  2. 「ドメイン」「環境」→「サーバー」「管理対象サーバー」を選択します。

  3. 「SSL」タブ、「詳細」を順にクリックします。

  4. ロックして編集構成をクリックします。

  5. ホスト名検証機能を「なし」に変更します。

  6. 管理対象サーバーを再起動します。

ホスト名検証機能「なし」に設定されていないと、Facebookがアイデンティティ・プロバイダである場合に、保護されたリソースへのアクセスが試みられたときに次のエラーが表示されることがあります。

Exception in processRequest method: oracle.security.idaas.rp.RPException:
oracle.security.idaas.rp.RPException: Request failed:

43.3.4.2 Facebookとの互換性があるWebLogic Server 10.3.5以前の構成

FacebookのSSL証明書には、ワイルドカード識別子として*.facebook.comが含まれています。WebLogic Serverバージョン10.3.5以前には、ワイルドカードを含むホスト名の検証に問題があります。このため、Facebookと、WebLogic Server上にデプロイされたOracle Access Management Mobile and Socialのインストールの間に通信障害が発生する場合があります。回避方法は、次のとおりです。

  • WebLogic Serverバージョン10.3.5またはそれ以前を使用している場合、次の手順を実行します。

    1. 管理コンソールで、「サーバー」「oam_server_where_Mobile_and_Social_is_deployed」「SSL」→「詳細」を選択します。

    2. ホスト名検証機能を「なし」に変更します。

  • このWebLogic Serverのバグは、バージョン10.3.6で次のように修正されました。新しいカスタム・ホスト名検証機能SSLWLSWildcardHostnameVerifierが実装されました。これは、デフォルトのホスト名検証機能から導出されており、SANなど、デフォルトのホスト名検証機能で実行できることがすべてサポートされています。SSLハンドシェイク中にワイルドカード証明書のサポートが必要な場合はこのカスタム・ホスト名検証機能を使用するようにWebLogic Serverを構成する必要があります。1つの選択肢としては、次のWebLogicプロパティを使用することがありです。

    -Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildca rdHostnameVerifier
    

43.4 サービス・プロバイダ・インタフェースの定義

サービス・プロバイダ・インタフェースは、指定したアプリケーション・プロファイルの認証フローを制御する一連のルールを指します。Mobile and Socialは、次のサービス・プロバイダ・インタフェースを提供します。

  • DefaultServiceProviderInterface: Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーションのサポートを提供します。

  • OAMServiceProviderInterface: Access Managerサービスで実行されるWebアプリケーションのサポートを提供します。

必要に応じて、Java開発者は、1つ以上のアイデンティティ・プロバイダ・インタフェース・コントラクトのカスタム実装を作成できます。この項には次のトピックが含まれます:

43.4.1 サービス・プロバイダ・インタフェースの作成

  1. Oracle Access Managementコンソールで、「ソーシャル・アイデンティティ」ホーム・ページを開きます(第43.1項「ソーシャル・アイデンティティの構成ページを開く」を参照)。

  2. ホーム・エリアの「サービス・プロバイダ・インタフェース」パネルで、「作成」をクリックします。

    「新規サービス・プロバイダ・インタフェースの作成」構成ページが表示されます。

  3. サービス・プロバイダ・インタフェースのプロパティに値を入力します。

    • 名前: この認証サービス・プロバイダに一意の名前を入力します。

    • 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

  4. インタフェース情報のプロパティに値を入力します(表43-7を参照)。

    表43-7 サービス・プロバイダ・インタフェースのプロパティ

    名前 注意

    IDPセレクタ

    カスタム・プロバイダのIDPセレクタ実装クラスを選択します。

    注意: コンソールは、提示されたクラスの有効性をチェックしません。

    ポストIDPセレクタ

    カスタム・プロバイダのポストIDPセレクタ実装クラスを選択します。

    IDP相互作用プロバイダ

    カスタム・プロバイダのIDP相互作用プロバイダ実装クラスを選択します。

    登録ステータス・チェック

    カスタム・プロバイダの登録ステータス・チェック実装クラスを選択します。

    セッション作成プロバイダ

    カスタム・プロバイダのセッション作成プロバイダ実装クラスを選択します。


  5. 「作成」をクリックして、サービス・プロバイダ・インタフェース構成オブジェクトを作成します。

43.4.2 サービス・プロバイダ・インタフェースの編集または削除

サービス・プロバイダ・インタフェースを編集または削除するには、パネルでプロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。属性の説明は、第43.4.1項「サービス・プロバイダ・インタフェースの作成」を参照してください。

43.4.3 カスタム・サービス・プロバイダ・インタフェース実装の追加

カスタム・インタフェース実装を追加するには、新しいソーシャル・アイデンティティ・プロバイダを作成し、業務目的に合せて必要に応じてカスタムまたはデフォルト、あるいはその両方の実装クラスの組合せを選択します。詳細は、『Oracle Access Management開発者ガイド』のソーシャル・アイデンティティ・クライアントSDKを使用したアプリケーションの開発に関する項を参照してください。

43.5 アプリケーション・プロファイルの定義

アプリケーション・プロファイルでは、Mobile and Socialサーバー上のソーシャル・アイデンティティ・プロバイダ・サービスを使用するアプリケーションを定義します。このパネルを使用して、モバイル・アプリケーション、Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーション、およびAccess Managerと統合されるWebアプリケーションが、ソーシャル・アイデンティティを使用するように構成します。

  • WebアプリケーションがAccess Managerと統合されていない場合は、ソーシャル・アイデンティティのログイン・ページをWebアプリケーションと統合します。詳細は、『Oracle Access Management開発者ガイド』の「ソーシャル・アイデンティティ・クライアントSDKを使用したアプリケーションの開発」の章を参照してください。

  • WebアプリケーションがAccess Managerに統合されている場合は、OAMApplicationという名前の事前構成済のアプリケーション・プロファイルを編集します。Oracle Access Managementのインストール時に、Access ManagerとMobile and Socialを同時にインストールすると、両方の製品が信頼されたパートナとして登録され、事前構成済のアプリケーション・プロファイルが含まれます。そのため、Access Managerとソーシャル・アイデンティティに統合されているWebアプリケーションを統合するために、コードを記述する必要はありません。Mobile and Socialに組み込まれているOAMApplicationアプリケーション・プロファイルは、Access Managerと連動するように事前構成済であり、わずかな構成変更を実行するだけで、使用している環境で動作するようになります。

通常、Access ManagerでWebゲートを構成すると、リソースおよびポリシーを含むアプリケーション・ドメインが作成されます。Mobile and Socialでは、OAMApplicationが、Access Managerのアプリケーション・ドメインに対応するアプリケーション・プロファイルです。そのため、10個のWebゲートをAccess Managerで定義し、それぞれが、ユーザー認証にMobile and Socialを使用する必要がある1つのアプリケーションを表している場合は、OAMApplicationをテンプレートとして使用してその10個のアプリケーション・ドメインに一致する名前を持つ10個の対応するアプリケーション・プロファイルを作成します。


注意:

Access Managerでアプリケーションを保護するためにWebゲートをインストールすると、そのWebゲートのセットアップにより、認証メカニズムとしてLDAPを備えたアプリケーション・ドメインが自動的に作成されます。Mobile and Social認証を使用するには、認証スキームをOICSchemeに変更します。

この項では、アプリケーション・プロファイルの作成ウィザードおよび「アプリケーション・プロファイルの編集」ページのヘルプを提供します。

次の各項では、詳細を説明します。

43.5.1 アプリケーション・プロファイルの作成

  1. Oracle Access Managementコンソールで、「ソーシャル・アイデンティティ」ホーム・ページを開きます(第43.1項「ソーシャル・アイデンティティの構成ページを開く」を参照)。

  2. ホーム・エリアの「アプリケーション・プロファイル」パネルで、「作成」をクリックします。

    「新規アプリケーション・プロファイルの作成」構成ページが表示されます。

  3. アプリケーション・プロファイルの一般プロパティに値を入力します。

    • 名前 - Webアプリケーションまたはモバイル・アプリケーションのコンテキスト名を表示します。この名前は、リソースを保護しているエージェントに登録されている名前と一致する必要があります。アプリケーションがAccess Managerに統合されている場合は、Access Managerに定義されているアプリケーション・ドメイン名が表示されます。この値は、モバイル・サービスのアプリケーション・プロファイルで定義した名前の値と同じにする必要があります(該当する場合)。

    • 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

    • 共有シークレット: モバイル・アプリケーションまたはWebアプリケーションの場合は、そのアプリケーションとMobile and Socialサーバーがセキュアな通信を容易にするために共有するセキュリティ・シークレットを指定します。Mobile and Socialのユーザー登録機能を使用するには、これが必要になります。任意の文字列にすることもできます。

    • 戻りURL: アプリケーションがモバイル・アプリケーションの場合、この値は使用されません。ただし、これは必須の属性です。そのため、モバイル・アプリケーションには、「モバイル・アプリケーション戻りURL」を使用してください。Webアプリケーションには、認証レスポンスを送り返すためにMobile and Socialが使用する必要があるURLを入力します。アプリケーションがAccess Managerに統合されている場合は、次のURLを指定します。これは、Mobile and Socialが認証レスポンスを送り返すために使用するURLです。

      http://oam-host:port/oam/server/dap/cred_submit

    • モバイル・アプリケーション戻りURL - モバイル・アプリケーションに対して、認証レスポンスを送り返すためにMobile and Socialが使用する必要があるURLを入力します。この値は、モバイル・アプリケーションの戻りURLに一致している必要があります。

  4. 次のアプリケーション・プロファイル構成のプロパティに値を入力します。

    • ログイン・タイプ: ユーザー・ログイン・ページで、ユーザーがローカルでの認証とアイデンティティ・プロバイダを使用する認証のどちらかを選択できるようにする場合は、ローカル認証およびソーシャル・アイデンティティ・プロバイダ認証を選択します。モバイル・アプリケーションまたは非モバイル・アプリケーションのいずれかを構成している場合、ユーザー・ログイン・ページにローカル認証オプションを提示しないのであれば、ソーシャル・アイデンティティ・プロバイダ認証のみを選択します。

      Mobile and Socialのログイン・ページは「ソーシャル・アイデンティティ・プロバイダ認証のみ」をサポートします。ローカル・ログインはサポートされません。


      注意:

      モバイル・アプリケーションを構成している場合は、「ログイン・タイプ」メニューからソーシャル・アイデンティティ・プロバイダ認証のみを選択します。ローカル認証およびソーシャル・アイデンティティ・プロバイダ認証オプションは、モバイル・アプリケーションに対しては無効です。

    • ブラウザ・ポップアップの有効化 - ログイン・ページをポップアップ・ウィンドウで開くには、「はい」を選択します。これがモバイル・アプリケーションの場合は、この値は無効になります。

    • ユーザー登録 - ユーザーがソーシャル・アイデンティティ・プロバイダで認証を受けた後にアプリケーションに登録できるようにする場合は、「有効」を選択します。アプリケーションのログイン・ページには、「ユーザー登録」フォームが表示され、ユーザーに登録を求めるようになります。ユーザーはそのフォームに入力して登録するか、「登録のスキップ」ボタンをクリックできます。ログイン・ページに「ユーザー登録」フォームを表示せず、ユーザーに登録を求めない場合は、「無効」を選択します。

    • 登録URL - ユーザーがローカル・アカウントに登録できるようにユーザーを転送する先となるURLを入力します。通常、ユーザーは、アプリケーション・プロファイルで定義されている登録サービス属性に対応するフィールドがあるフォームに誘導されます。マップでは属性オブジェクトを含む暗号化トークンも、パラメータとしてクライアント・アプリケーションに渡されます。これらの属性は、ユーザーのプロファイル・データを登録ページに事前移入するために使用されます。

    • UserID属性 - ユーザーを一意に識別するために使用される属性名を入力します。この属性名は、「アプリケーション・プロファイル構成」ページの「アプリケーション・ユーザー属性」セクションにも表示されます。

    • ユーザー・プロファイル・サービス・エンドポイント - アプリケーションによって使用されるユーザー・プロファイル・サービス・エンドポイントを選択します。ユーザー・プロファイル・サービスによって、アプリケーションがLDAPディレクトリ・サービスに誘導され、そこで登録時にユーザーが作成されます。ユーザー・プロファイル・サービス・エンドポイントは、モバイル・サービスで構成されます。

    • 認証サービス・エンドポイント: 認証サービス・エンドポイントにより、ローカル・ログインが要求されたときにユーザーを認証する方法が決定されます。モバイル・アプリケーションの場合は、InternetIdentityAuthentication、またはInternetIdentityAuthenticationタイプの任意のカスタム認証を選択します。

      • 認証リクエストをAccess Managerに転送するには、「/oamauthentication」を選択します。IAMSuiteアプリケーション・ドメイン内のMobile and Social認証ポリシーと関連付けられた認証スキームにより、ユーザーの認証方法が決定されます。

      • 対応するエンドポイントで指定されているアイデンティティ・ストアを使用するには、/internetidentityauthenticationを選択します。

    • アプリケーション・プロファイル・プロパティ - アプリケーション・プロファイル属性を表に追加するには、「追加」をクリックします。サポート対象は次のとおりです。

      • app.passwd.field - 登録ページ上のパスワードを暗号化します。passwordを値として追加します。登録ページでパスワードをアスタリスク(*)でマスクするには、app.passwd.fieldプロパティを追加し、その値としてpasswordを追加します。

      • oic.app.idp.oauth.token - Mobile and Socialに、アプリケーションへの最終リダイレクトの一部としてOAuthアクセス・トークンを含めるように指示します。値としてtrueを追加します。ユーザーがOAuthプロバイダ(Facebook、Twitter、LinkedIn)を選択した場合にのみ適用されます。

      • oic.app.user.token - ユーザーがアイデンティティ・プロバイダで認証を受けてアプリケーションにリダイレクトされるときにJWTユーザー・トークンを作成します。値としてtrueを追加します。このトークンには、アイデンティティ・プロバイダ関連のURIと、アイデンティティ・プロバイダに記録されているユーザー識別子の値が含まれています。このトークンを使用して、ユーザー・プロファイルRESTサービスなど、他の保護されているMobile and Social RESTサービスにアクセスします。

  5. 「追加」をクリックして、ソーシャル・アイデンティティ・プロバイダが認証後にアプリケーションに返す、アプリケーション・ユーザー属性を追加します。

    これらの属性の詳細は、次の「登録サービス詳細とアプリケーション・ユーザー属性のマッピング」の手順で構成します。

  6. 「登録サービス詳細とアプリケーション・ユーザー属性のマッピング」表に行を追加して、ソーシャル・アイデンティティ・プロバイダが提供するアプリケーション属性に、ローカル(ユーザー)登録属性をマップします。

    追加のアプリケーション・ユーザー属性については、前の手順で先に追加しておきます。次の各定義は、「登録サービス詳細とアプリケーション・ユーザー属性のマッピング」表のプロパティに適用されます。

    • 登録サービス属性 - このメニューから、構成する登録サービス属性を選択します。

    • ユーザー属性表示名 - 「登録サービス属性」列の属性に対して、ユーザー登録フォームに表示する名前を入力します。これが、ユーザーに表示される属性名です。

    • 読取り専用 - ユーザーによる属性値の更新を防止する場合に選択します。属性値はフォーム上でグレー表示されるようになり、ユーザーによる更新はブロックされるようになります。


      注意:

      Yahooがソーシャル・アイデンティティ・プロバイダである場合は、「名」および「姓」に対して「読取り専用」オプションを選択しないでください。Yahooでは、これらの属性の値は返されません。「読取り専用」オプションを選択すると、ユーザー登録に失敗し、例外エラーが表示されるようになります。

    • 必須 - この属性をユーザー登録フォームの必須項目にする場合に選択します。

    • アプリケーション・ユーザー属性 - 「登録サービス属性」列の属性に対応する属性を選択します。

  7. 「次へ」をクリックして、サービス・プロバイダ・インタフェースを構成します。

    「サービス・プロバイダ・インタフェース」ページが表示されます。

  8. ドロップダウン・メニューから「DefaultServiceProviderInterface」を選択します。

    サービス・プロバイダ・インタフェースの詳細は、第43.4項「サービス・プロバイダ・インタフェースの定義」を参照してください。

  9. 「次」をクリックして、ソーシャル・アイデンティティ・プロバイダを構成します。

    ソーシャル・アイデンティティ・プロバイダ・ページが表示されます。このセクションを使用して、1つ以上のソーシャル・アイデンティティ・プロバイダを選択して、ローカル・アプリケーション・ユーザーの属性をソーシャル・アイデンティティ・プロバイダの属性にマップします。たとえば、ソーシャル・アイデンティティ・プロバイダがGoogleの場合、一意のローカル・ユーザー識別子として電子メール・アドレスを使用するには、次の手順を実行します。

    1. ソーシャル・アイデンティティ・プロバイダ列で「Google」を選択します。

      2列の表が開きます。

    2. 次のようにマッピングを作成します。

      1. 「アプリケーション・ユーザー属性」列の最初の行で「uid」を選択します。

      2. ソーシャル・アイデンティティ・プロバイダ・ユーザー属性列で、「電子メール」を選択します。

  10. 「終了」をクリックして、アプリケーション・プロファイルを作成します。

43.5.2 アプリケーション・プロファイルの編集または削除

アプリケーション・プロファイルを編集または削除するには、パネルでプロファイルを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。属性の説明は、第43.5.1項「アプリケーション・プロファイル」を参照してください。

43.6 ソーシャル・アイデンティティとモバイル・アプリケーションの統合

モバイル・デバイス上のアプリケーションがソーシャル・アイデンティティを使用して認証を受けられるように、モバイル・サービスを構成できます。ソーシャル・アイデンティティを使用する必要のあるアプリケーションは、それに対応するアプリケーション・プロファイルがソーシャル・アイデンティティに存在している必要があります。モバイル・アプリケーションにソーシャル・アイデンティティを使用する必要がある場合、そのアプリケーションのプロファイルが、ソーシャル・アイデンティティとモバイル・サービスに存在している必要があります。

  1. 「ソーシャル・アイデンティティ」の下で、アプリケーション・プロファイルの作成ウィザードを開きます。

  2. 保護するモバイル・アプリケーションに該当する値を、アプリケーション・プロファイルの属性に入力して、「次へ」をクリックします。

    属性の定義は、第43.5.1項「アプリケーション・プロファイルの作成」を参照してください。

  3. サービス・プロバイダ・インタフェースを選択して、「次へ」をクリックします。

    第43.4項「サービス・プロバイダ・インタフェースの定義」を参照してください。

  4. ソーシャル・アイデンティティ・プロバイダを選択して、「次」をクリックします。

    第43.2項「ソーシャル・アイデンティティの構成の理解」を参照してください。

  5. 「アプリケーション・プロファイル」のサマリーを確認してから、「終了」をクリックしてアプリケーション・プロファイルを作成します。

  6. 「モバイル・サービス」の下で、「サービス・ドメインの作成」ウィザードを開きます。

    既存のサービス・ドメインを変更する場合は、それを開いて編集します。詳細は、第42.4項「サービス・プロファイルの定義」を参照してください。

  7. フォームに次のように入力します。

    • 「タイプ」については、「モバイル・アプリケーション」を選択します。

    • 「認証スキーム」については、ソーシャル・アイデンティティの認証を選択します。

    詳細は、第42.7項「サービス・ドメインの定義」を参照してください。

  8. 「アプリケーション・プロファイル選択」セクションで、保護するモバイル・アプリケーションを示すモバイル・サービスのアプリケーション・プロファイルを追加し、モバイルSSOに、エージェントとして参加するのか、クライアントとして参加するのか、それとも参加しないのかを選択します。

    既存のプロファイルを参照するか、名前を入力して、該当するアプリケーション・プロファイルを選択します。アプリケーション・プロファイルは、先に作成しておく必要があります。(モバイル・サービスのアプリケーション・プロファイルを作成する場合は、第42.6項「アプリケーション・プロファイルの定義」を参照してください。ソーシャル・アイデンティティのアプリケーション・プロファイルを作成する場合は、第43.5項「アプリケーション・プロファイルの定義」を参照してください。)

  9. 「次へ」をクリックして、サービス・プロファイルを選択(または作成)します。

    第42.4項「サービス・プロファイルの定義」を参照してください。

  10. 「次へ」をクリックして、サービス保護を選択します。

    たとえば、ユーザー・プロファイル・サービスを保護する場合は、認証サービスとしてInternetIdentityAuthenticationを使用します。

  11. 「次へ」をクリックして、「サービス・ドメインの作成」のサマリーを確認します。

  12. 「終了」をクリックして、サービス・ドメインを作成します。


注意:

詳細は、『Oracle Access Management開発者ガイド』の「ソーシャル・アイデンティティ・クライアントSDKを使用したアプリケーションの開発」のソーシャル・アイデンティティとモバイル・アプリケーションとの統合に関する項を参照してください。

43.7 ソーシャル・アイデンティティ・プロバイダ・アカウントのリンク

ソーシャル・アイデンティティ・アカウント・リンクによって、ユーザーは、既存または新しいローカル・ユーザー・アカウントに複数のインターネット・アイデンティティをリンクできます。次の項では、この機能を有効し、使用する方法について説明します。

43.7.1 ソーシャル・アイデンティティ・プロバイダ・アカウント・リンクの使用

アカウント・リンク・フローのステップは次のとおりです。

  1. ユーザーがMobile and Socialのログイン・ページにアクセスします。

  2. ローカル・ログインまたはアイデンティティ・プロバイダでログインするように要求されます。

  3. ユーザーは、アイデンティティ・プロバイダ(たとえばGoogle)のログインを選択し、パスワード資格証明を入力します。

    認証され(および、すでにローカル・アカウントで登録されていることが確認された場合)、ユーザーは、自動的にローカル・ユーザーとしてログインされ、このローカル・アカウントにアイデンティティ・プロバイダをリンクできるオプションを提供するリンク済アカウント・ページが表示されます。

    ユーザーはGoogleの隣のリンクをクリックして、ローカル・アカウントをGoogleアイデンティティ・プロバイダ・アカウントにリンクします。ユーザーは、このページから、追加のアイデンティティ・プロバイダのリンクまたはリンク解除を選択できます。図43-1に、このシナリオを示します。

図43-1 ソーシャル・アイデンティティ・アカウント・リンク

アカウント・リンクを示す論理図

次のようなシナリオがあります。

  • ローカル・アカウントを持たないユーザーがアイデンティティ・プロバイダにログインし、アイデンティティ・プロバイダ認証後に登録オプションを選択した場合、エンタープライズIDが作成され、アイデンティティ・プロバイダ・アカウントはこのエンタープライズIDに自動的に関連付けられます。つまり、ユーザーはアイデンティティ・プロバイダ・ログインIDでログインし、Mobile and Socialは、そのアイデンティティ・プロバイダ・ログインIDと同じユーザー名でローカル・アカウントを作成します。それから、ユーザーは、新しく作成されたローカル・アカウントと関連付けられているリンク済アカウント・ページにリダイレクトされます。このページから、ユーザーはアイデンティティ・プロバイダ・アカウントのリンクまたはリンク解除を選択したり、アプリケーションに戻ることができます。

  • ユーザーがローカル・アカウントのみを使用してログインした場合、アプリケーション内で、ユーザーは、アイデンティティ・プロバイダを表示するリンク済アカウント・ページを選択する必要があります。このページから、ユーザーはアイデンティティ・プロバイダ・アカウントのリンクまたはリンク解除を選択したり、アプリケーションに戻ることができます。アカウントがリンクされると、ソーシャル・アイデンティティは、ユーザーがアイデンティティ・プロバイダの資格証明でログインした場合でも、そのユーザーがローカル・アカウントにリンクされていることを検出します。


注意:

リンク済アカウント・ページは、リライイング・パーティにより(ソーシャル・アイデンティティ経由で)、またはアカウントのリンク・オプションをホストするサード・パーティ・アプリケーションから提供されます。いずれの場合でも、次の項目を提供する必要があります。
  • リンクできる様々なアイデンティティ・プロバイダのリストを提供するAPI呼出し(たとえばAccountLinkingHelper.getProviders ())。リンク・ステータスとIDが含まれます。

  • リンクできる様々なアイデンティティ・プロバイダを表示するRP固有アカウント・リンク・ページ(たとえばlinkedAccounts.jsp)。リンク・ステータスとIDが含まれます。


43.7.2 ソーシャル・アイデンティティ・プロバイダ・アカウント・リンクの構成

アカウント・リンクを使用するためには、表43-8に示すプロパティを構成する必要があります。「アプリケーション・プロファイル・プロパティ」表で設定します。

表43-8 アカウント・リンク・プロパティ

プロパティ 詳細

app.acct.link.enabled

アカウント・リンクを有効にするには、この構成プロパティをtrueに設定する必要があります。

app.acct.link.attr

アカウント・リンク情報を格納する(複数値)LDAP属性。


アカウント・リンクを有効にする際には、次のことが必要になります。

  • プロキシ設定が正しいかどうか確認します。この設定は、Oracle Access Managementコンソールで「システム構成」→「Mobile and Social」→「Mobile and Social設定」の順に選択して、見つけることができます。

  • アイデンティティ・プロバイダのアイコンまたはロゴのイメージはWLSTを使用してのみ指定できます。イメージ・パスがhttpで始まる場合、イメージはimgタグを使用して取得されます。そうでない場合、ソーシャル・アイデンティティから提供される内部参照が使用されます。

  • username属性とアカウント・リンク属性が異なることを確認します。これらが同じ場合、矛盾した動作が発生する原因になります。たとえば、username属性はuidに設定し、リンク属性はmailに設定できます。

  • アプリケーションに対して共有秘密を設定します。アプリケーション・ポリシーで認証スキームを設定してOICSchemeをポイントし、設定が正しいことを確認します。たとえば、MatchLDAPAttributeは、リライイング・パーティのアプリケーション・プロファイルで設定されているusername属性(通常はuid)と一致している必要があります。