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

ソーシャル・アイデンティティ・プロバイダは、Google、Facebook、Twitterなどのアイデンティティ・プロバイダについての構成詳細を収集します。

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

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

ソーシャル・アイデンティティ・プロバイダもWebLogic Scripting Toolを使用して作成できます。

Identity and Access Management WebLogic Scripting Toolコマンド・リファレンスの、セキュリティ・コマンドに関する項を参照してください。

「「ソーシャル・アイデンティティの管理」ページを開く」の説明に従って、「ソーシャル・アイデンティティの管理」ページにアクセスします。
ホーム・エリアの「ソーシャル・アイデンティティ・プロバイダ」パネルで、「作成」をクリックします。
「新規ソーシャル・アイデンティティ・プロバイダの作成」構成ページが表示されます。
ソーシャル・アイデンティティ・プロバイダのプロパティに値を入力します。
- 名前: この認証サービス・プロバイダに一意の名前を入力します。
- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。
- ソーシャル・アイデンティティ・プロバイダ・プロトコル: ドロップダウン・メニューからアイデンティティ・プロバイダ・プロトコルを選択します。
  - OpenID
  - OAuth
  - カスタム
  「カスタム」を選択すると、カスタム・アイデンティティ・プロバイダを構成できます。ここでの選択内容により、表示される「プロトコル属性」パネルと「返されたユーザー属性」パネルは、そのソーシャル・アイデンティティ・プロバイダ(OpenIDまたはOAuth)で使用する認証プロトコルに特有のプロパティを反映するように変更されます。
- 実装クラス: このフィールドには、ソーシャル・アイデンティティ・プロバイダ・プロトコルの選択に基づいて、それに該当するプロバイダ固有のJavaインタフェースoracle.security.idaas.rp.spi.IdentityProviderの実装が移入されます。(「カスタム」の場合は、そのアイデンティティ・プロバイダと通信する該当の実装クラスを入力します。)Mobile and Socialサーバーは、この情報を使用して、ソーシャル・アイデンティティ・プロバイダと通信します。

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

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

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

名前	値	ノート
Yadisエンドポイント	HTTPまたはHTTPSの絶対URLになります	このアイデンティティ・プロバイダのOpenID認証プロトコル・メッセージを受け入れる、公開URLを入力します。Mobile and Socialは、このURLを使用して、ユーザー認証リクエストを作成します。
Hashing Algorithm	SHA256は、256ビット長のキー・アルゴリズムです SHA1は、160ビット長のキー・アルゴリズムですなし	署名アルゴリズムを選択します。Mobile and Socialによって、この値が内部で使用されて、アイデンティティ・プロバイダと通信するためのセッション・タイプおよびアソシエーション・タイプ・プロパティが構成されます。
`Authentication Policy`	ユーザーの認証時、OpenIDプロバイダで認証ポリシーを適用することを要求する場合は「はい」を選択します。それ以外の場合は、「いいえ」を選択します。	PAPE (Provider Authentication Policy Extension)の使用により、Web開発者は、アイデンティティ・プロバイダからユーザーにパスワードの入力を再度要求することなどフローに対するその他の変更を要求できます。
`認証ポリシー最大期間`	0秒以上の値を指定します。パスワードの再入力の要求を強制するには、`0`を指定します。	アクティブに認証を受けていないユーザーが、要求された認証ポリシーを使用して認証を受けることが必要になる前にログイン・セッションを使用できる最長時間を秒単位で入力します。このパラメータを使用すると、アイデンティティ・プロバイダへのユーザーのログイン・セッションが最新であることを確実にできます。
`Preferred Authentication Policies`		ユーザーの認証時、アイデンティティ・プロバイダが満たす必要がある認証ポリシーを表す0個以上のURIを空白で区切って入力します。次に例を示します。 `http://schemas.openid.net/pape/policies/2007/06/phishing-resistant` `http://schemas.openid.net/pape/policies/2007/06/multi-factor`

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

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

名前	値	ノート
`Authorization URL`	アイデンティティ・プロバイダの公開OAuth認可URLです。アイデンティティ・プロバイダが公開OAuth URLを変更したときには、それに合せて、この値を更新します。	アイデンティティ・プロバイダによってリクエスト・トークンが返された後、Mobile and SocialによってユーザーがこのURLに誘導されます(「リクエスト・トークンURL」を参照してください)。アイデンティティ・プロバイダによってユーザーのアイデンティティが検証され、ユーザーは、ユーザーの保護されている情報をMobile and Socialサーバーに解放する権限をアイデンティティ・プロバイダに付与します。
`Access Token URL`	アイデンティティ・プロバイダの公開アクセス・トークンURLを入力します。	ユーザーがリクエスト・トークンを(認可URLを使用して).認可した後、Mobile and SocialによってこのURLが使用されてアイデンティティ・プロバイダにアクセス・トークンが要求されます。
`Request Token URL`	アイデンティティ・プロバイダの公開リクエスト・トークンURLを入力します。(Facebookには適用されません。)	Mobile and Socialは、このURLを使用して、アイデンティティ・プロバイダからリクエスト・トークンを取得します。アイデンティティ・プロバイダによってリクエスト・トークンが付与された後、Mobile and Socialサーバーによってユーザーがアイデンティティ・プロバイダの認可URLに誘導されます。(RFC 5849「The OAuth 1.0 Protocol」のrequest tokenおよびrequest secretという用語は、temporary credentialsという用語にかわりました。)
`Profile URL`	アイデンティティ・プロバイダの公開プロファイルURLを入力します。	Mobile and Socialは、このURLを使用して、OAuthアクセス・トークンに基づいてユーザー属性を要求します。
`Consumer Key`	Mobile and Socialサーバーが、それ自体をアイデンティティ・プロバイダに識別させるために使用する値を入力します。	アイデンティティ・プロバイダからコンシューマ・キーを要求する方法の詳細は、「OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成」を参照してください。
`Consumer Secret`	コンシューマ・キーの所有権を確立するためにMobile and Socialサーバーが使用するシークレットを入力します。	アイデンティティ・プロバイダからコンシューマ・シークレットを要求する方法の詳細は、「OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成」を参照してください。
`Server Time Sync`	Mobile and Socialサーバーとリモート・アイデンティティ・プロバイダの時間が同期されていない場合は、リモート・プロバイダにリクエストを送信するときに現在のサーバー時刻に追加するスキューを分単位で入力します。このフィールドには、正と負の両方の整数を入力できます。	通常、LinkedInでは、同期しているサーバー時刻値が必要とされます。FacebookやTwitterには適用されません。「属性名」列に、OpenIDアイデンティティ・プロバイダによって返される属性名に割り当てるローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、Mobile and Socialサーバーがアイデンティティ・プロバイダにユーザー・データを要求できるURLを入力します。「属性名」列に、アイデンティティ・プロバイダがサポートしていない属性を追加した場合、それらの属性は、Mobile and Socialで使用できません。

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

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

表50-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`

表50-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からのアイデンティティ属性を使用して、ユーザーの登録フォームに事前移入する場合は、この制限に注意してください。

表50-5および表50-6に、FoursquareおよびWindows Liveでサポートされるユーザー属性を示します。

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

属性	説明
id	ユーザーのIDを要求します。
firstname	ユーザーの名前を要求します。
lastname	ユーザーの姓を要求します。
contact.email	ユーザーの電子メール・アドレスを要求します。
homecity	ユーザーの所在地を要求します。
gender	ユーザーの性別を要求します。
photo	ユーザーの写真を要求します。

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

属性	説明
id	ユーザーのIDを要求します。
first_name	ユーザーの名前を要求します。
last_name	ユーザーの姓を要求します。
name	ユーザーの名前を要求します。
link	ユーザーのリンクを要求します。
email.preferred	ユーザーの優先電子メール・アドレスを要求します。
gender	ユーザーの性別を要求します。
locale	ユーザーのローカルを要求します。
updated_time	更新時間を要求します。

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

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

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

ソーシャル・アイデンティティ・プロバイダを編集または削除できます。

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

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

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

ノート:

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

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

Facebook用のコンシューマ・キーおよびコンシューマ・シークレットを生成できます。

生成するには、次のようにします。

次のURLをWebブラウザで開きます。
https://developers.facebook.com/apps
「Create New App」をクリックします。
「Create New App」フォームに入力します。
Facebookによりアプリケーションが作成され、それに一意のアプリケーションIDおよびアプリケーション・シークレットが割り当てられます。
「Basic Info」セクションに情報を入力します。
「Select how your application integrates with Facebook」セクションで、「Website with Facebook Login」を選択します。
「Site URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。次に例を示します。
http://OAM-Hosted-Machine: Port/
「Save Changes」をクリックします。
「ソーシャル・アイデンティティ・プロバイダの編集または削除」の説明に従って、Mobile and Socialコンソールから、「ソーシャル・アイデンティティ・プロバイダ」→Facebook構成ページを開きます。
「コンシューマ・キー」フィールドにアプリケーションIDを、「コンシューマ・シークレット」フィールドにアプリケーション・シークレットを貼り付けます。
「適用」をクリックして変更を保存します。

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

Twitter用のコンシューマ・キーおよびコンシューマ・シークレットを生成できます。

生成するには、次のようにします。

次のURLをWebブラウザで開きます。
https://dev.twitter.com/apps/new
「Create an application」フォームに入力します。
「Callback URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。次に例を示します。

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

Twitterによりアプリケーションが作成され、それに一意のコンシューマ・キーおよびコンシューマ・シークレットが割り当てられます。
(オプション)自分のTwitterアプリケーションを必要に応じて構成し、変更内容を保存します。
「ソーシャル・アイデンティティ・プロバイダの編集または削除」の説明に従って、Mobile and Socialコンソールから、「ソーシャル・アイデンティティ・プロバイダ」→Twitter構成ページを開きます。
「コンシューマ・キー」フィールドにコンシューマ・キーを、「コンシューマ・シークレット」フィールドにコンシューマ・シークレットを貼り付けます。
「適用」をクリックして変更を保存します。

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

LinkedIn用のコンシューマ・キーおよびコンシューマ・シークレットを生成できます。

生成するには、次のようにします。

次のURLをWebブラウザで開きます。
https://www.linkedin.com/secure/developer?newapp=
「Add New Application」フォームに入力します。
「OAuth User Agreement」セクションの「OAuth Redirect URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。次に例を示します。

http://OAM-Hosted-Machine:Managed Server Port/
「Add Application」をクリックします。
LinkedInによってアプリケーションが作成され、それに一意のAPIキーおよびシークレット・キーが割り当てられます。
「ソーシャル・アイデンティティ・プロバイダの編集または削除」の説明に従って、Mobile and Socialコンソールから、「ソーシャル・アイデンティティ・プロバイダ」→LinkedIn構成ページを開きます。
「コンシューマ・キー」フィールドにAPIキーを、「コンシューマ・シークレット」フィールドにシークレット・キーを貼り付けます。
「適用」をクリックして変更を保存します。

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

Foursquare用のコンシューマ・キーおよびコンシューマ・シークレットを生成できます。

生成するには、次のようにします。

次のURLをWebブラウザで開きます。
https://foursquare.com/developers/register
アプリケーション名とWebサイトURLを入力します。
「コールバックURL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。
次に例を示します。

http://OAM-Hosted-Machine:Port/
変更を保存します。
表示される画面から、「クライアントID」のコードと「クライアント・シークレット」のコードをコピーします。
「ソーシャル・アイデンティティ・プロバイダの編集または削除」の説明に従って、Mobile and Socialコンソールから、「ソーシャル・アイデンティティ・プロバイダ」→Foursquare構成ページを開きます。
「コンシューマ・キー」フィールドにクライアントIDを、「コンシューマ・シークレット」フィールドにクライアント・シークレットを貼り付け、「適用」をクリックして、変更を保存します。

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

Windows Live用のコンシューマ・キーおよびコンシューマ・シークレットを生成できます。

生成するには、次のようにします。

次のURLをWebブラウザで開きます。
https://manage.dev.live.com/
Windows Live IDとパスワードでサインインします。
「アプリケーションの作成」をクリックします。
アプリケーション名を入力します。
使用条件に目を通して、同意します。
表示される画面から、「クライアントID」のコードと「クライアント・シークレット」のコードをコピーします。
「ソーシャル・アイデンティティ・プロバイダの編集または削除」の説明に従って、Mobile and Socialコンソールから、「ソーシャル・アイデンティティ・プロバイダ」→Windows Live構成ページを開きます。
「コンシューマ・キー」フィールドにクライアントIDを、「コンシューマ・シークレット」フィールドにクライアント・シークレットを貼り付け、「適用」をクリックして、変更を保存します。

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

Google用のコンシューマ・キーおよびコンシューマ・シークレットを生成できます。

生成するには、次のようにします。

次のURLをWebブラウザで開きます。
https://code.google.com/apis/console
「APIと認証」(左側)で、「資格証明」をクリックします。
「OAuth」で、「新しいクライアントIDを作成」をクリックします。
クライアントIDの作成フォームが開きます。
フォームに入力して送信します。
新しいクライアントIDおよびシークレットが追加されます。
「ソーシャル・アイデンティティ・プロバイダの編集または削除」の説明に従って、Mobile and Socialコンソールから、「ソーシャル・アイデンティティ・プロバイダ」→Google構成ページを開きます。
「コンシューマ・キー」フィールドにクライアントIDを、「コンシューマ・シークレット」フィールドにクライアント・シークレットを貼り付けます。
「適用」をクリックして変更を保存します。

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

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

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

FacebookをサポートするようにWebLogic ServerをWebLogicコンソールから構成できます。

構成するには、次のようにします。

WebLogicコンソールを開きます。
http://host:port/console
「ドメイン」→「環境」→「サーバー」→「管理対象サーバー」を選択します。
「SSL」タブ、「詳細」を順にクリックします。
ロックして編集構成をクリックします。
ホスト名検証機能を「なし」に変更します。
管理対象サーバーを再起動します。

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

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

50.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
```