48.6 ソーシャル・アイデンティティのプロセスの理解

様々なフローにより、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)および関連パーティが関与する認証シナリオが管理されます。

• ソーシャル・アイデンティティ認証の基本的なフロー

• ローカル・アカウントを持つユーザーが返された場合の認証フロー

• ローカル・アカウントのない新しいユーザーの認証フロー

• アクセス・トークンの取得のOAuthフロー

• Access Managerとソーシャル・アイデンティティによるユーザーの認証フロー

• ローカル・ユーザーの認証フロー

48.6.1 ソーシャル・アイデンティティ認証の基本的なフロー

次のシナリオでは、ソーシャル・アイデンティティを使用しているときの基本的な認証プロセスを説明します。

1. ユーザーが保護されたリソースへのアクセスを要求すると、Mobile and Socialにリダイレクトされます。

2. Mobile and Social (RP)は、Googleなど(アイデンティティ・プロバイダ)の資格証明を使用してログインするかどうかをユーザーに尋ねます。

3. Mobile and Socialは、ユーザー名とパスワードを入力するGoogleのログイン・ページにユーザーをリダイレクトします。

4. Googleは資格証明を検証し、ユーザーをMobile and Socialにリダイレクトします。それと同時に、アイデンティティ・プロバイダは、その構成に基づいて、Mobile and Socialにアイデンティティの属性を返します。

   ユーザーが組織のアカウントを持っていない場合は、ユーザーにアカウントを登録するように促します。登録フォームは、アイデンティティ・プロバイダから返された情報で入力済にされています。

ノート:

Access Managerの場合、ユーザーはローカルに登録されている必要があります。それ以外の場合は、アクセスが許可されません。Access Managerを使用していないときには、ユーザーは保護されたリソースにリダイレクトされ、ユーザーが登録されていない場合でもアクセスが許可されます。詳細は、「ソーシャル・アイデンティティをOracle Access Managerと組み合せて使用する方法」を参照してください。

48.6.2 ローカル・アカウントを持つユーザーが返された場合の認証フロー

ローカル・アイデンティティ・リポジトリにより、ユーザーがすでにローカル・アカウントを持っているかどうかが判断されます。そのため、Mobile and Socialが作成のプロンプトを表示することはありません。

このシナリオでは、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)、アイデンティティ・プロバイダおよびローカル・ユーザー認証サービス(図のLocal AuthおよびID Repository)の間の認証フローを説明します。説明の後の図48-8に、そのプロセスを示します。

1. ユーザーがWebブラウザで保護されたリソースのURLを開くと、Mobile and Socialサーバーは、ログイン・ページとアイデンティティ・プロバイダ(Google、Yahoo、Facebook、Windows Live、Foursquare、Twitter、LinkedInなど)の選択メニューをユーザーに表示します。

2. ユーザーがアイデンティティ・プロバイダを選択します。

3. Mobile and Socialサーバーが選択されたアイデンティティ・プロバイダにユーザーをリダイレクトすると、ログイン・ページが表示されます。

4. ユーザーが認証時にユーザー名とパスワードを入力すると、アイデンティティ・プロバイダはMobile and Socialサーバーに認証アサーションを送信します。

5. ユーザーがローカル・アカウントを持っているかどうかについて、Mobile and Socialサーバーがアイデンティティ・リポジトリに問い合せます。

   アイデンティティ・リポジトリは、ディレクトリ・サーバー、データベース、Oracle Identity Managerまたはそれに類似したものになります。このユーザーは、ローカル・アカウントを持つユーザーであると判断されます。

   • モバイル・アプリケーションまたは直接統合されたWebアプリケーションがMobile and Socialを使用して認証している場合は、Mobile and Socialサーバーはユーザーのブラウザに認証アサーションを送信します。

   • Access Mangerによって保護されたアプリケーションが認証している場合は、ユーザーがローカル・アカウントを持っている場合のみ、Access Managerはユーザーのためにセッションを作成します。(新しく登録されたユーザーは、ローカル・アカウント保持者とみなされます。)

6. ユーザーのブラウザは、Mobile and Socialによって送信された認証アサーションを、保護されたリソースのアクセス管理サービスに送信します。

7. アクセス管理サービスは、必要に応じて追加の認証ステップを実行します。

8. アクセス管理サービスが、保護されたリソースへのユーザーのアクセスを許可します。

図48-8 ローカル・アカウントを持つユーザーが返された場合の認証

「図48-8 ローカル・アカウントを持つユーザーが返された場合の認証」の説明

48.6.3 ローカル・アカウントのない新しいユーザーの認証フロー

ローカル・アカウントを持っていないユーザーの場合、Mobile and Socialによりアカウントの作成が求められます。

このシナリオでは、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)、アイデンティティ・プロバイダおよびローカル・ユーザー認証サービス(図のLocal AuthおよびID Repository)の間の認証フローを説明します。説明の後の図48-9に、そのプロセスを示します。

1. ユーザーがWebブラウザで保護されたリソースのURLを開くと、Mobile and Socialサーバー(この図ではRP)は、ユーザー・ログイン・ページとアイデンティティ・プロバイダ(Google、Yahoo、Facebook、Twitter、LinkedInなど)の選択メニューをユーザーに表示します。

2. ユーザーがアイデンティティ・プロバイダを選択します。

3. Mobile and Socialサーバーは選択されたアイデンティティ・プロバイダにユーザーをリダイレクトし、このプロバイダがログイン・ページを表示します。

4. ユーザー認証時にユーザーがユーザー名とパスワードを入力すると、アイデンティティ・プロバイダはMobile and Socialサーバーに認証アサーションを送信します。

5. ユーザーがローカル・アカウントを持っているかどうかについて、Mobile and Socialサーバーがアイデンティティ・リポジトリに問い合せます。

   アイデンティティ・リポジトリは、ディレクトリ・サーバー、データベース、Oracle Identity Managerまたはそれに類似したものになります。このユーザーは、ローカル・アカウントを持たないユーザーであると判断されます。Mobile and Socialによって、次のように続行されます。

   • アイデンティティ・プロバイダがOpen IDプロトコルを使用する場合は、Mobile and Socialサーバーは以前に取得された認証アサーションのデータを処理することで、ユーザーのプロファイル属性を取得します。

   • アイデンティティ・プロバイダがOAuthプロトコルを使用する場合は、Mobile and Socialサーバーは以前に取得されたアクセス・トークンを使用してアイデンティティ・プロバイダに別個のHTTPコールを行って、ユーザーのプロファイル属性を取得します。

6. Mobile and Socialサーバーは、新規ユーザー登録フォームをユーザーのブラウザに送信します。

   この登録フォームは、アイデンティティ・プロバイダによって送信されたユーザー・プロファイル属性を使用して入力済にされています。

7. ユーザーは登録フォームの入力を完了して、そのフォームをインタフェース接続しているユーザー・レジストリ(ディレクトリ・サーバーまたはOracle Identity Manager)に送信し、アカウントを作成します。

   アイデンティティ・プロバイダからアクセス・トークンが取得される場合は、アクセス・トークンもMobile and Socialからクライアント・アプリケーションに返されます。

8. クライアント・アプリケーションのアクセス管理サービスは、追加の認証ステップを必要に応じて実行します。

9. アクセス管理サービスが、保護されたリソースへのユーザーのアクセスを許可します。

図48-9 ローカル・アカウントのない新しいユーザーの認証

「図48-9 ローカル・アカウントのない新しいユーザーの認証」の説明

48.6.4 アクセス・トークンの取得のOAuthフロー

OAuth認証およびアクセス・トークン取得のフローは、ユーザー、リライイング・パーティおよびOAuthアイデンティティ・プロバイダの間に存在します。サーバーはOAuthアイデンティティ・プロバイダとインタフェース接続して、OAuthアイデンティティ・プロバイダによって保護されたリソースにアクセスするための認可コードとアクセス・トークンを取得します。

この項では、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)およびOAuthアイデンティティ・プロバイダ間のOAuth認証およびアクセス・トークン取得フローに関する補足的な詳細を説明します。(Facebook、FoursquareおよびWindows LiveではOAuth 2.0プロトコルが、LinkedInとTwitterではOAuth 1.0プロトコルが使用されています。)このシナリオのクライアント・アプリケーションは、Java準拠のアプリケーション・サーバー上で実行しているWebアプリケーションまたはモバイル・アプリケーションのどちらかになります。このプロセスの説明に後に、図48-10を示します。

1. ユーザーがクライアント・アプリケーションを開始すると、そのアプリケーションは保護されたWebページをユーザーのブラウザに返します。

2. ユーザーがクライアント・アプリケーション上で保護されたリソースを開こうとします。

3. ユーザーが保護されたリソースにアクセスできるように、クライアント・アプリケーションはMobile and Socialサーバーにアクセス・トークンの取得を求めます。

   Mobile and Socialのキャッシュ内に有効なアクセス・トークンがある場合は、Mobile and Socialによってアクセス・トークンがクライアント・アプリケーションにフォワードされ、認証シナリオはステップ10にスキップします。このフローでは、Mobile and Socialがローカル・キャッシュにアクセス・トークンを保持していないと仮定します。

4. アクセス・トークンがローカル・キャッシュに存在しないため、Mobile and SocialはユーザーのかわりにOAuthアイデンティティ・プロバイダによる認可リクエストを開始します(OAuthクライアントID、スコープ情報およびリダイレクトURLを埋め込むためにHTTPヘッダーを利用します)。

5. OAuthアイデンティティ・プロバイダは、ログイン・ページを表示します。

6. ユーザーがOAuthアイデンティティ・プロバイダのログイン・ページにユーザー名とパスワードを入力して、ユーザーのプロファイル属性をMobile and Socialサーバー(および拡大解釈してクライアント・アプリケーション)に提供することをアイデンティティ・プロバイダに対して承認します。

7. OAuthアイデンティティ・プロバイダは、認可コードをMobile and Socialサーバーに送信します。

8. Mobile and Socialサーバーは、アクセス・トークン・リクエストをOAuthアイデンティティ・プロバイダに送信します。

   リクエストには、前のステップで受信された認可コードに加え、OAuthクライアントIDおよびクライアント資格証明が含まれます。

9. OAuthアイデンティティ・プロバイダは、アクセス・トークンをMobile and Socialサーバーに返します。

10. Mobile and Socialサーバーは、アクセス・トークン(ユーザーIDとOAuthクライアントを含む)をキャッシュして、そのアクセス・トークンをクライアント・アプリケーションに転送します。

11. クライアント・アプリケーションはアクセス・トークンを使用して保護されたリソースにアクセスし、保護されたページをユーザーのブラウザに返します。

図48-10 OAuthアイデンティティ・プロバイダによるユーザー認証

「図48-10 OAuthアイデンティティ・プロバイダによるユーザー認証」の説明

48.6.5 Access Managerとソーシャル・アイデンティティによるユーザーの認証フロー

ユーザーは、ローカル・アカウントを持っているか、求められたときにローカル・アカウントに登録する必要があります。そのようにしないと、Access Managerは保護されたリソースへのユーザーのアクセスを許可しないため、ユーザーはログイン・ページにリダイレクトされます。

このシナリオでは、ユーザー、Access Manager、Mobile and Socialサーバー(リライイング・パーティ)およびアイデンティティ・プロバイダ間の認証プロセスを説明します。このプロセスの説明に後に、図48-11を示します。

1. ユーザーがクライアント・アプリケーション上で保護されたリソースを開こうとします。

2. リソースを保護するWebゲートが、アクセス・リクエストをインターセプトします。

3. Access Managerがリソースを保護する認証ポリシーを識別し、Mobile and Socialサーバーが提供するログイン・ページにユーザーをリダイレクトします。

4. ログイン・ページに、ソーシャル・アイデンティティ・プロバイダのメニューが表示されます。

5. ユーザーはOpenIDアイデンティティ・プロバイダを選択し、Access ManagerはユーザーのブラウザをMobile and Socialサーバーにリダイレクトします。Mobile and Socialサーバーはユーザーのブラウザを、選択されたソーシャル・アイデンティティ・プロバイダ(Google、Facebook、Twitterなど)のログイン・ページにリダイレクトします。

6. ユーザーはソーシャル・アイデンティティ・プロバイダのログイン・ページにユーザー名とパスワードを入力します。

   アイデンティティ・プロバイダが認証プロセスを完了し、アイデンティ情報の共有に対するユーザーの承認を求めます(該当する場合)。

7. 認証が完了すると、ソーシャル・アイデンティティ・プロバイダはブラウザをリダイレクトしてMobile and Socialサーバーに戻します。

   アイデンティティ・プロバイダが提供するアイデンティ・アサーションのさらなる処理とユーザー・アイデンティティ情報の取得の後、Mobile and SocialサーバーはユーザーのブラウザをAccess Managerにリダイレクトします。今回は、ページ・リクエストのHTTPヘッダーで、ユーザーの認証ステータスと属性をAccess Managerに提供します。

8. Access Managerはユーザー・セッションを作成し、保護されたリソースにユーザーをリダイレクトします。

図48-11 Access Managerによるユーザーの認証

「図48-11 Access Managerによるユーザーの認証」の説明

48.6.6 ローカル・ユーザーの認証フロー

ユーザーがソーシャル・アイデンティティ・プロバイダによる認証を選択しない場合、ローカル・アカウントを使用して認証を実行できます。

このプロセスの説明に後に、図48-12を示します。

1. ユーザーが保護されたリソースのURLをWebブラウザで開くと、Mobile and Socialサーバーがログイン・ページとアイデンティティ・プロバイダの選択メニューをユーザーに表示します。

2. ユーザーはローカル認証の使用を選択して、ログイン・ページにユーザー名とパスワードを入力します。

3. クライアント・アプリケーションのアクセス管理サービスは、追加の認証ステップを必要に応じて実行します。

   • JWTトークン・サービスを使用する場合は、ユーザー・トークンを作成できます。

   • OAMトークン・サービスは、ローカル認証フロー時にトークンを返しません。

4. アクセス管理サービスがユーザーのためにセッションを作成し、ユーザーは保護されたリソースにアクセスします。

図48-12 ユーザーのローカル認証

「図48-12 ユーザーのローカル認証」の説明