| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
この章では、Oracle Access Management Mobile and Socialの用途と機能について説明します。内容は次のとおりです。
Oracle Access Management Mobile and Socialサービスは、保護されたリソースへのアクセスを必要とするユーザーまたはクライアントと、リソースを保護するバックエンドのアクセス管理サービスおよびアイデンティティ管理サービスの間の橋渡しの役割を果たします。Mobile and Socialには簡易なクライアント・ライブラリが用意されており、開発者はこれを使用して、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加できます。バックエンドでは、Mobile and Socialサーバーのプラガブルなアーキテクチャにより、システム管理者は、ユーザーのクライアント・ソフトウェアやモバイル・アプリケーションを更新しなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除できます。Mobile and Socialでは、次に示す無料の3つの機能セットを提供します。
モバイル・サービスは、アプリケーションおよびデバイスを、Oracle Identity Access Management製品スイートで使用可能なエンタープライズ・アクセス管理サービスおよびアイデンティティ管理サービスに接続します。これにより、認可されたデバイスのみがアクセスできるように制限するために、高度な認証および認可サービスの機能(モバイル・デバイスとアプリケーションの登録や、デバイス・フィンガープリンティングなど)を簡単に利用できるようになります。また、クライアント・アプリケーションでは、基本的なパスワードベースの認証よりも優れた強力な機能であるナレッジベース認証も実装できます。
|
注意: デバイス・フィンガープリンティングおよびナレッジベース認証には、いずれもOracle Adaptive Access Managerが必要です。 |
モバイル・サービスは、有効なデバイスとクライアント資格証明に加え、アプリケーション・トークン・リクエストごとにユーザー・トークンを要求するように構成できます。これにより、認可されたユーザーのみが保護リソースにアクセス可能であること、さらにユーザーが認可済のデバイスで認可済のアプリケーションのみを実行していることが保証されます。モバイル・サービスは、Mobile and SocialがLDAP準拠のディレクトリ・サーバーと統合されている場合、ユーザー・プロファイル・サービスへの簡単なアクセスも提供します。
ソーシャル・アイデンティティを使用すると、Mobile and Socialは、Google、Yahoo、Facebook、Foursquare、Windows Live、Twitter、LinkedInなどの一般的なクラウドベースのアイデンティティ認証および認可サービスとの相互作用中に、リライイング・パーティの役割を果たすことができます。Mobile and Socialをデプロイすると、各プロバイダを個別に実装しなくても、複数のログイン・オプションがユーザーに提供されます。これにより、ユーザーは信頼できるアイデンティティ・プロバイダにある自分の資格証明を使用して保護されたリソースにアクセスできるようになります。
|
注意: バージョン11.1.2.2より前は、ソーシャル・アイデンティティはインターネット・アイデンティティ・サービスと呼ばれていました。 |
Mobile and SocialはAccess Managerとの密接な統合に加え、Oracle Adaptive Access Managerおよび様々なLDAP準拠のディレクトリ・サーバーといった他のバックエンドのアイデンティおよびアクセス管理サービス・オファリングと連携動作するようにあらかじめ統合されています。フロントエンドに対して、Mobile and Socialは、簡単に使用できるSDKを提供し、Java、AndroidおよびiOSプラットフォーム上のクライアント・アプリケーションの統合に対応しています。クライアント・アプリケーションは簡単なRESTコールを使用して、Mobile and Socialサーバーと通信します。
|
注意: REST (REpresentational State Transfer)は、World Wide Webの開発に使用されているソフトウェアのアーキテクチャ様式です。それは軽量で、特にWebベースのアプリケーションやサービスの構築に適しています。 |
モバイル・サービスとソーシャル・アイデンティティを連動するように構成できます。たとえば、ソーシャル・アイデンティティを使用してGoogle、Facebook、Twitterなどでユーザーが認証できるようにし、モバイル・サービスを使用して(a)ローカル認証機能を提供するか、(b)ソーシャル・アイデンティティ・プロバイダのユーザーIDアサーションを受け付けることでユーザー・トークンを生成できます。モバイル・サービスをソーシャル・アイデンティティとともに使用すると、デバイス登録セキュリティを強化することもできます。
|
注意: Mobile and Socialサービスは、AndroidデバイスやiOSデバイスまたはJava SE JVMで実行される登録済アプリケーションや、RESTコールを使用してサービスと通信する登録済アプリケーションにセキュリティ・レイヤー機能を提供します。追加のモバイル機能が必要な場合は、無償のOracle製品オファリングであるADFモバイルが、iOSで動作するデバイス用のフル機能のアプリケーションを作成するためのアプリケーション開発フレームワークを提供します。詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkモバイル開発者ガイドを参照してください。 |
次の各項には、Mobile and Socialのインストールとデプロイメントについての追加情報と説明のリンクが含まれています。
Mobile and SocialをAccess Managerとともにインストールします。Mobile and Socialを単体で、またはAccess ManagerやOracle Adaptive Access Manager (OAAM)のいずれかと組み合せて動作するように構成できます。または、これら3つすべてを一緒にデプロイすることもできます。Mobile and Socialとともにデプロイしたソフトウェアに応じて使用できる機能が異なります。表41-1に詳細を示します。
表41-1 インストールしたコンパニオン・サービスに基づくMobile and Socialの機能
| 機能 | Mobile and Socialのみ | Mobile and Social + Access Manager | Mobile and Social + OAAM | Mobile and Social + Access Manager + OAAM |
|---|---|---|---|---|
|
ネイティブAccess Manager認証ダイアログを使用したAccess Managerトークン・サポート |
✔ |
✔ |
||
|
認証および認可のJWTトークン・サポート |
✔ |
✔ |
✔ |
✔ |
|
接続モバイル・デバイスを一意に識別する機能(デバイスのフィンガープリント) |
✔ |
✔ |
||
|
デバイスの登録およびアクセス・リクエスト時の基本的な(制限付きの)デバイス・セキュリティ・チェック |
✔ |
✔ |
||
|
リスクベースのアクセス制御(地理ロケーションおよび他のデバイス属性に基づくアクセスの許可または拒否など)を含む、デバイスの登録およびアクセス・リクエスト時の拡張デバイス・セキュリティ・チェック |
✔ |
✔ |
||
|
マルチステップ認証サポート(ナレッジベース認証およびワンタイム・パスワードのサポート) |
✔ |
✔ |
||
|
ディレクトリ・サーバーとの連携およびユーザー・プロファイル・サービスのサポート |
✔ |
✔ |
✔ |
✔ |
|
インターネットベースのアイデンティティ・プロバイダ(Facebook、Google、Twitter、LinkedIn、Yahoo)のリライイング・パーティ・サポート |
✔ |
✔ |
✔ |
✔ |
インストールの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。
次のリストは、Mobile and Socialのいくつかのデプロイメント方法の情報とリンクを示しています。
Mobile and SocialをAccess Managerとともにデプロイする場合は、Mobile and SocialとAccess Managerの両方を同一ドメインまたは別のドメインの同じサーバー上に一緒にデプロイできます。詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドを参照してください。
Mobile and SocialをOracle Access Manager 10gまたは11gR1 PS1とともにデプロイする場合は、Mobile and SocialとOracle Access Managerは別々のドメインの別々のサーバー上にインストールする必要があります。詳細は、第44.3項「Oracle Access Managerを使用するMobile and Socialのデプロイ」を参照してください。
|
注意: すでにAccess Managerがインストールされている場合は、OAMドメインを拡張することでMobile and SocialをOracle Access Managementのインストールに追加することはできません。これを試みると、次のようなエラーが発生します。
|
WebGateとともにMobile and Socialをデプロイする場合、Mobile and Socialは、WebGateによって保護されたリソースにクライアントがアクセスするために必要となるOracle Access Managementトークンを生成可能です。次の制限が適用されます。
Oracle Access Management 11gR2 (11.1.2)をデプロイした場合、Mobile and Socialは、11g WebGateと10g WebGateのいずれかにアクセス可能なトークンを生成可能です。
Access Manager 11gR1 (11.1.1)と10gのいずれかをデプロイした場合、Mobile and Socialは、10g WebGateのみにアクセス可能なOracle Access Managementトークンを生成可能です。
Mobile and Socialをテスト環境から本番環境に移行する場合は、第44.4項「テストから本番に移行するスクリプトを実行した後のMobile and Socialの構成」を参照してください。
Mobile and Social機能を活用するには、サービスを明示的に有効にする必要があります。次の手順に従って、Mobile and Socialを有効化します。
Oracle Access Managementコンソールにログインします。
「起動パッド」が開きます。
「構成」ペインの「使用可能なサービス」をクリックします。
「使用可能なサービス」ページが開きます。
「Mobile and Social」の隣の「有効化」をクリックします。
モバイル・サービスは、クライアント・デバイスで実行しているアプリケーションを、Oracle Identity Access Management製品スイートで使用可能なセキュリティ・サービスと製品に接続します。また、ユーザー・プロファイル・サービスはモバイル・サービス機能であり、多くの一般的なLDAP準拠ディレクトリ・サーバーにクライアント・アプリケーションを接続します。モバイル・サービスは、次のコンポーネントで構成されます。
バックエンドのアイデンティティ・サービス・インフラストラクチャとのインタフェースとなるサーバー・コンポーネント。サーバーは、サポートされているクライアント・アプリケーション(およびそれらのアプリケーションを使用するユーザー)と、バックエンドのアイデンティティ・サービスの間の橋渡しの役割を果たします。このような配置により、クライアント・アプリケーションはバックエンドのインフラストラクチャから分離されるため、クライアント・プログラムを更新しなくても、バックエンドのインフラストラクチャを変更できます。Mobile and Socialサービスは、単独で実行することも、Access ManagerサービスやOAAM製品と組み合せて実行することもできます。詳細は、第41.1項「Mobile and Socialの概要」を参照してください。
OAAMセキュリティ・ハンドラ・プラグインで必要とされるセキュリティ・トークンやセキュリティ情報など、セキュリティ・マテリアルを格納可能なサーバー側デバイス・ストア。サーバー側デバイス・ストアにはいくつかの利点があります。サーバー側デバイス・ストアによって管理されるトークンが、デバイスまたはクライアント・アプリケーションが危険にさらされた場合にコピー可能なクライアント・アプリケーションに送信されないため、セキュリティが向上します。また、モバイル・クライアント・アプリケーションがセキュリティ・マテリアルを管理および同期する必要がなくなります。さらに、セキュリティ・マテリアルを複数のクライアント・アプリケーション間で共有および同期できます。
Mobile and Socialモバイル・サービス・クライアント・ソフトウェア開発キット(クライアントSDK)には、AndroidデバイスとiOSデバイスおよびJavaに使用できます。これは、モバイル・デバイスとデスクトップ・デバイスで実行するアプリケーションに認証、認可およびディレクトリ・アクセス機能を組み込む場合に使用します。また、モバイル・サービス・クライアントSDKを使用すると、モバイル・シングル・サインオン(SSO)エージェント・アプリケーションを作成することもできます(AndroidデバイスとiOSデバイスのみ)。モバイルSSOの詳細は、第41.2.3項「モバイル・サービス用シングル・サインオン(SSO)の理解」を参照してください。Mobile and Socialモバイル・サービス・クライアントSDKの詳細は、第41.2.4項「Mobile and Socialモバイル・サービス・クライアントSDKの概要」を参照してください。
次の各項では、Mobile and Socialのモバイル・サービスの部分について詳細に説明します。
認証および認可サービスを使用すると、モバイルおよび非モバイル・アプリケーションに既存の認証および認可インフラストラクチャを拡張できます。モバイル・サービスは、次の一般的なトークン・タイプをサポートします。
ユーザー・トークンは、認証されたユーザーに関連付けられた権限をトークン・ベアラーに付与します。
アクセス・トークンは、WebリソースやURLなど保護されている特定のリソースへのアクセスを許可します。
クライアント・トークンは、Webアプリケーションやサーバー・アプリケーションなどの非モバイル・ハードウェア・デバイスへのアクセスを許可します。
クライアント登録ハンドル(クライアント・トークンと同様)もモバイル・サービスで使用されます。これは、モバイル・デバイスで実行しているモバイル・クライアント・アプリケーションを示すものです。Mobile and Socialは、クライアント登録ハンドルを使用して、モバイル・デバイスを登録します。これに対して、非モバイル・サービス・プロバイダは、クライアント・トークンを使用して、非モバイル・デバイスを認証します。
モバイル・デバイスとは、Google社のAndroidモバイル・オペレーティング・システムやApple社のiOSモバイル・オペレーティング・システムなどのモバイル・オペレーティング・システムを実行するデバイスです。一方、非モバイル・デバイスとは、Mac OS X、Windows 7およびLynxデスクトップなどの非モバイル・オペレーティング・システムを実行するデバイスです。モバイル・デバイスと非モバイル・デバイスのセキュリティ上の課題は異なるため、Mobile and Socialではモバイルの認証と非モバイルの認証は別々に管理されます。新しいモバイル・デバイス非常に頻繁にオンラインになるため、不正検出手段など、より詳細な精査を必要とします。
|
注意: 非モバイル・デバイスは、適切な入力を提供すると、モバイル・サービスと非モバイル・サービスの両方を使用できます。 |
Mobile and Socialは、Access Managerトークン(Mobile and SocialとともにAccess Managerがインストールされている場合)と、JWT (JSON Web Token)トークンをサポートします。それぞれのトークン・タイプには、それに対応するモバイルおよび非モバイル・サービス・プロバイダがあります。
Mobile and Socialには、次の4つの事前構成済認証サービス・プロバイダが用意されています。
OAM認証
モバイルOAM認証
JWT認証
モバイルJWT認証
次の2つの追加の認証サービス・プロバイダも作成できます。
JWT-OAM認証
モバイルJWT-OAM認証
表41-2では、認証サービス・プロバイダについて説明します。
表41-2 モバイル・サービスのモバイルおよび非モバイル認証サービス・プロバイダ
| 認証サービス・プロバイダ | 説明 |
|---|---|
|
OAMAuthentication |
これによって、デスクトップ・デバイスからWebアプリケーションを実行するユーザーは、Access Managerを使用して認証できます。 |
|
MobileOAMAuthentication |
これによって、モバイル・デバイスを使用するユーザーは、Access Managerを使用して認証できます。 |
|
JWTAuthentication |
これによって、デスクトップ・デバイスからWebアプリケーションを実行するユーザーは、JSON Webトークン・フォーマットを使用して認証できます。JSON Web Tokenは、HTTP認可ヘッダーなど、領域に制約がある環境に適したコンパクトなトークン形式です。 |
|
MobileJWTAuthentication |
これによって、モバイル・デバイスを使用するユーザーは、JSON Webトークン・フォーマットを使用して認証できます。 |
|
JWTOAMAuthentication |
軽量で継続時間の長いJWTトークンをOAMトークンと交換できるようにします。OAMトークンによりクライアントはSSOリソースおよびOAMリソースにアクセスできます。このプロバイダを使用して、非モバイル・アプリケーションを使用するユーザーは、継続時間の長い有効なJWTトークンがあれば、資格証明の提示なしで新しいOAMトークンを取得できます。 |
|
MobileJWTOAMAuthentication |
軽量で継続時間の長いJWTトークンをOAMトークンと交換できるようにします。OAMトークンによりクライアントはSSOリソースおよびOAMリソースにアクセスできます。このプロバイダを使用して、モバイル・アプリケーションを使用するユーザーは、継続時間の長い有効なJWTトークンがあれば、資格証明なしで新しいOAMトークンを取得できます。 |
モバイル・サービス認可フローは、クライアント・アプリケーションがAndroid、iOSまたはJava用Mobile and SocialクライアントSDKを使用してモバイル・セキュリティを実装する場合、またはクライアント・アプリケーションがモバイルSSOエージェント・アプリケーション(後述)を使用してモバイル・セキュリティを確立する場合に使用します。このフローでは、クライアント・アプリケーション(またはモバイルSSOエージェント)はユーザー入力を収集し、モバイル・デバイス上でユーザー・セッションを維持します。
次の各項に示す図は、モバイル・サービスの認可フローを示します。
モバイル・シングル・サインオン(モバイルSSO)を使用すると、ユーザーは、同一デバイス上で複数のモバイル・アプリケーションを実行するときに、それぞれの資格証明を提供する必要がなくなります。ネイティブ・アプリケーションとブラウザベースのアプリケーションは、どちらもモバイルSSOに参加できます。
|
注意: モバイル・サービス・アプリケーションとモバイルOAuthアプリケーションに対しては、別々のSSOを実装する必要があります。モバイルOAuthアプリケーション用シングル・サインオンの詳細は、第45.2.8項「モバイルOAuthシングル・サインオン(SSO)の理解」を参照してください。 |
モバイルSSOエージェント・アプリケーションの理解
モバイル・デバイスにインストールされている特殊なアプリケーションをモバイルSSOエージェントに指定できます。このアプリケーションは、リモートのMobile and Socialサーバーと、バックエンドのアイデンティティ・サービスで認証する必要のあるデバイス上の他のアプリケーションとの間でプロキシとしての役割を果たします。エージェントは、専用エージェント(他の用途には使用されないアプリケーション)であっても、エージェント機能も同時に提供するビジネス(クライアント)アプリケーションであってもかまいません。
|
注意: アプリケーションでモバイルSSOエージェント・アプリケーションを使用してMobile and Socialサーバーとの認証を行うには、そのサーバーでアプリケーションをモバイルSSOエージェントまたはクライアントとして構成しておく必要があります。モバイルSSO用にモバイル・サービス・セキュリティを構成する方法の詳細は、第42.7項「サービス・ドメインの定義」を参照してください。 |
モバイルSSOエージェントは、デバイスの登録や高度な認証スキーム(たとえば、マルチファクタ認証やワンタイム・パスワード認証など)を処理するため、このような機能をそれぞれのモバイル・アプリケーションに組み込む必要がなくなります。モバイルSSOエージェントが存在する場合は、ユーザー資格証明がモバイル・ビジネス・アプリケーションに公開されなくなります。モバイルSSOエージェントとSSOクライアントは、次のように相互作用します。
SSOクライアント・アプリケーションは、デバイス登録リクエスト、アプリケーション登録リクエストおよびユーザー・トークン・リクエストをSSOエージェントに送信します。
SSOエージェントは、SSOクライアントのかわりに必要な収集を実行します。
SSOクライアント・アプリケーションは、登録ハンドルとユーザー・トークンを使用して、必要になるアクセス・トークンをリクエストします。
SSOエージェント・アプリケーションは、サーバー側デバイス・ストアと同様に、モバイルSSOクライアントのかわりにトークンおよびセキュリティ・マテリアルを格納します。
ブラウザベースのビジネス・アプリケーションも、認証にモバイルSSOエージェントを使用するように構成できます。その場合は、ブラウザベースのビジネス・アプリケーションを起動すると、モバイルSSOエージェントが起動され、そのエージェントによってユーザー名とパスワードが収集されてMobile and Socialサーバーに送信されます。ビジネス・アプリケーションとエージェントがSSOで認可されると、Mobile and Socialサーバーはアクセスを認可します。続いて、エージェントは、リソースのアクセス・トークンを(ビジネス・アプリケーションのかわりに)要求し、ヘッダーに含まれているアクセス・トークンでブラウザをビジネス・アプリケーションのURLにリダイレクトします。
ユーザーの視点から見た場合、ネイティブおよびブラウザベースのアプリケーションは、ユーザーに資格証明を要求することなく、デバイス上で開始されます。モバイル・デバイスにエージェントがインストールされていない場合またはビジネス・アプリケーションがモバイルSSOで承認されない場合は、各アプリケーションを起動するたびに、ユーザーは自分の資格証明をMobile and Socialサーバーに個別に直接送信する必要があります。
モバイルSSOエージェントは、アイドル・セッションをタイムアウトにしたり、すべてのアプリケーションのグローバル・ログアウトを管理したり、デバイス選択消去をサポートできます。さらに、エージェントは、基本的なオフライン認証もサポートします。エージェントは、ローカル・ストレージ用にユーザー・パスワードの一方向暗号化を行います。オフライン認証の場合、エージェントは、ユーザー名とパスワードの検証に、ローカルに保存されているバージョンを使用します。エージェントは、すべてのセッションのアイドル・タイムアウトと、ローカル・パスワードの有効期限ポリシーを強制します。
モバイルSSOエージェントを使用する場合、アプリケーションは、ユーザーに資格証明を要求することなく、デバイス上で開かれます。モバイル・デバイスにエージェントがインストールされていない場合またはビジネス・アプリケーションがモバイルSSOで承認されない場合は、各アプリケーションを起動するたびに、ユーザーは自分の資格証明をMobile and Socialサーバーに個別に直接送信する必要があります。
構築済のモバイルSSOエージェントは提供していませんが、AndroidまたはiOS用のMobile and Socialモバイル・サービス・クライアントSDKを使用してモバイルSSOエージェント・アプリケーションを構築できるようにドキュメントを提供しています。モバイルSSOエージェント・アプリケーション作成の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のAndroidまたはiOSモバイル・サービスSDKに関するドキュメントを参照してください。
|
注意: モバイルSSOエージェントは、AndroidデバイスとiOSデバイスでのみサポートされます。 |
Mobile and Socialモバイル・サービス・クライアントSDKには、AndroidおよびiOSデバイス用とJava仮想マシン(JVM)用の個別のSDKが含まれています。表41-3は、各モバイル・サービス・クライアントSDK機能と、その機能が動作するソフトウェアについての説明です。
表41-3 Mobile and Socialモバイル・サービス・クライアントSDKのAndroid機能、iOS機能およびJava機能
| 機能 | Android | iOS | Java |
|---|---|---|---|
|
Mobile and Socialサーバー経由でのクライアント登録ハンドル、ユーザー・トークンおよびアクセス・トークンを取得可能なモバイル・アプリケーションの作成 |
✔ |
✔ |
|
|
Mobile and Socialサーバー経由でのクライアント・トークン、ユーザー・トークンおよびアクセス・トークンを取得可能なデスクトップ・アプリケーションの作成 |
✔ |
||
|
ディレクトリ・サーバーとの連携およびユーザー・プロファイル・サービスの実装 |
✔ |
✔ |
✔ |
|
モバイル・シングル・サインオン(SSO)アプリケーションの作成 |
✔ |
✔ |
ユーザー・プロファイル・サービスにより、組織のユーザーがモバイル・デバイスからユーザー・プロファイル・サービスにアクセスできるアプリケーションを作成できます。ユーザー・プロファイル・サービスを使用すると、Web、モバイルおよびデスクトップ・アプリケーションは、次に示すような各種のLDAP準拠のディレクトリ・サーバーのタスクを実行できるようになります。
ユーザーおよびグループの作成、読取り、更新および削除機能
検索機能
組織図のレポート機能
これを達成するために、Mobile and Socialサーバーは、次にあげる多くの一般的なLDAP準拠のディレクトリ・サーバーとインタフェース接続できます。
Microsoft Active Directory
Novell eDirectory
Oracle Directory Server Enterprise Edition
Oracle Internet Directory
Oracle Unified Directory
Oracle Virtual Directory
Open LDAP
WebLogic Server Embedded LDAP
ユーザー・プロファイル・サービスに対するSDKの使用方法を示すコード例については、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
|
注意: HTTP通信が可能なデバイスは、RESTコールをMobile and Socialサーバーに送信することで、ユーザー・プロファイル・サービスを使用できます。『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のcURLを使用したMobile and Social RESTコールの送信に関する項を参照してください。 |
保護されたリソースにユーザーがアクセスしようとすると、Mobile and Socialによってクライアント・トークン(クライアントの資格証明を安全に格納するサーバーまたはコンピュータを通してユーザーが接続している場合)またはクライアント登録ハンドル(ユーザーがモバイル・デバイスを使用している場合)が要求されます。つまり、クライアント・デバイス(モバイル・デバイスを含む)とクライアント・アプリケーションが保護されたリソースにアクセスするには、Mobile and Socialサーバーに登録する必要があるということです。
|
注意: また、アプリケーションは通常、ユーザー・トークンとアクセス・トークンを要求するように構成されています。 |
モバイル・デバイス上で実行するクライアント・アプリケーションが、この高度な認証プロセスに従った後で、モバイル・アプリケーションは保護されたリソースにアクセスできるようになります。
ユーザーは、アプリケーションのログイン画面でユーザー名とパスワードを入力して、Mobile and Socialサーバーで認証されます。
モバイル・デバイスがMobile and Socialサーバーにまだ登録されていない場合、ユーザーの認証後に、このサーバーはモバイル・デバイスにクライアント登録ハンドルを送信します。
クライアント登録ハンドルがMobile and Socialサーバーに返されて、ユーザー・トークンが取得されます。
クライアント登録ハンドルとユーザー・トークンがMobile and Socialサーバーに返されて、アクセス・トークンが取得されます。
非モバイル・アプリケーションも、モバイル・サービスが提供する認証サービスを利用できます。そのような場合は、クライアント登録ハンドルのかわりにクライアント・トークンが使用されます。クライアント・トークンを取得すると、前述したようにユーザー・トークンとアクセス・トークンをリクエストできます。追加のシナリオについては、この項で説明します。
モバイル・デバイスが保護されたリソースにアクセスしようとしたときに、そのデバイスがMobile and Socialにまだ登録されていない場合は、モバイルSSOエージェントをインストールする必要があります。登録認証プロセスは、次のフローで説明します。このプロセスの説明の後に、図41-1と図41-2を示します。
ユーザーがモバイル・デバイスでアプリケーションを起動します。
アプリケーションは、ユーザーをモバイルSSOエージェントにリダイレクトします。
モバイルSSOエージェントにより、ログイン・ページが表示されます。
ユーザーは、ユーザー名とパスワードを入力します。
モバイルSSOエージェントは、デバイス属性およびアプリケーションIDとともに、ユーザー名とパスワードをMobile and Socialサーバーに送信します。
Mobile and Socialサーバーはユーザー名とパスワードを、ユーザーを認証するAccess Managerにフォワードします。
Mobile and Socialサーバーは、デバイス属性と他の認証結果をOAAMモバイル・セキュリティ・ハンドラ・プラグインに送信し、プラグインはOAAMサーバーに格納されているポリシーを実行します。
|
注意: OAAMには、アクティブとパッシブの2つの登録フローがあります。アクティブ・フローでは、デバイス登録プロセスの続行を許可する前に、チャレンジによってユーザーへの本人確認を行います。パッシブ・フローは、ユーザーに対する本人確認なしで続行します。 |
OAAMセキュリティ・ハンドラ・プラグインは、2つのセキュリティ・ハンドル(Mobile and SocialがモバイルSSOエージェントまたはビジネス・アプリケーションそのものと一緒に格納するデータの一部)を作成します。各ハンドルには、名前、値および有効期限のタイムスタンプが格納されます。
oaam.deviceハンドルはモバイル・デバイスを表します。(同じデバイス上の異なるクライアント・アプリケーションは、すべて同じデバイス・ハンドル値を持ちます。)OAAMは、このハンドルをキーとして使用し、OAAMデータベースに保存されている完全なデバイス・プロファイルを取得します。このハンドルの存続期間は、比較的長期間です。
oaam.sessionハンドルは、クライアント・アプリケーション用のOAAMログイン・セッションを表します。(デバイス上の各クライアント・アプリケーションは、一意のセッション・ハンドル値を持ちます。)OAAMは、このハンドルをキーとして使用して、OAAMデータベースに保存されているOAAMセッションの詳細を取得します。ユーザーがクライアント・アプリケーションからログアウトすると、oaam.sessionハンドルは削除されます。
Mobile and Socialサーバーは、モバイル・クライアント登録ハンドル、OAAMデバイス・ハンドルおよびOAAMセッション・ハンドルを、モバイルSSOエージェントに返します。
モバイルSSOエージェントは、以前に受信したクライアント登録ハンドルとOAAMデバイス・ハンドルをサーバーに渡すことで、ユーザー・トークンを取得します。
モバイルSSOエージェントは、Access Managerのアクセス・トークンをリクエストします。このリクエストには、クライアント登録ハンドルとOAAMデバイス・ハンドルが含まれています。図41-2を参照してください。
図41-2 Access Managerからのアクセス・トークンをリクエストするモバイルSSOエージェント
このシナリオでは、Mobile and Socialと互換性があるビジネス・アプリケーションを起動するモバイル・デバイス(Mobile and Socialに登録済)を使用するユーザーについて説明します。このシナリオでは、モバイルSSOエージェントがインストールされていて、ユーザーはアクセス・トークンが必要になる保護されたリソースにアクセスする必要があります。ビジネス・アプリケーションは、アクセス・トークンをリクエストするために、最初にユーザー・トークンを取得する必要があります。添付の図(図41-3と図41-4)は、このプロセスを示しています。
ユーザーがモバイル・デバイスでビジネス・アプリケーションを起動します。
ビジネス・アプリケーションは、モバイルSSOエージェントにユーザー・トークンを求めます。このとき、次のいずれかが行われます。
モバイルSSOエージェントはログイン・ページを表示し、ユーザーはユーザー名とパスワードを入力します。
モバイルSSOエージェントは、ユーザー名、パスワードおよびクライアント登録ハンドルをMobile and Socialサーバーに送信します。(図41-4の手順2)。
Mobile and Socialサーバーはクライアント登録ハンドルを検証して、ユーザー資格証明を(JWTトークン・サービスまたはAccess Managerトークン・サービスを使用して)認証し、リスク分析のためにOAAMを起動します。その後で、ユーザー・トークンをモバイルSSOエージェントに返します。(図41-4の手順3)。
モバイルSSOエージェントはユーザー・トークンのコピーをそのローカル資格証明ストアに格納し、そのユーザー・トークンをビジネス・アプリケーションに返します。(図41-4の手順4)。
ビジネス・アプリケーションはそのユーザー・トークンを使用して、Mobile and Socialサーバーにアクセス・トークンを直接リクエストします。(この手順は図には示されていません。)
Mobile and SocialサーバーからモバイルSSOエージェントにアクセス・トークンが返されます。
ビジネス・アプリケーションは、アクセス・トークンを使用して、Access ManagerまたはOracle Enterprise Gateway (OEG)で保護されたリソースを呼び出します。(図41-4の手順5)。
このシナリオでは、モバイル・デバイスで実行するアプリケーションはモバイルSSOエージェントにインタフェース接続し、エージェントはRESTコールを使用してMobile and Socialサーバーと通信します。サーバーは必要に応じてAccess ManagerおよびOAAMとインタフェース接続し、モバイルSSOエージェントに(再度RESTコールを使用して)必要なトークンを返します。エージェントは、アプリケーションにトークンを送り返します。このアプリケーションは、保護されたリソースにRESTコールまたはSOAPコールを使用してアクセスできるようになります。このプロセスについて、次のフローで説明します。このプロセスの説明に後に、図41-5を示します。
ユーザーがモバイル・デバイスでアプリケーションを起動します。
クライアント・アプリケーションはAccess Managerによって保護されたリソースにアクセスする必要があるため、モバイルSSOエージェントにアクセス・トークンの取得を要求します。
モバイルSSOエージェントは、Mobile and Socialサーバーからアプリケーション・プロファイルを取得します。
モバイルSSOエージェントは、ユーザー名とパスワードの入力を求めます。
モバイルSSOエージェントは、デバイス属性およびアプリケーションIDとともに、ユーザー名とパスワードをMobile and Socialサーバーに送信します。
Mobile and Socialサーバーがデバイスを登録し、ユーザーを認証します。
サーバーからモバイルSSOエージェントにアクセス・トークンが返されます。
モバイルSSOエージェントは、ローカル資格証明ストアにハッシュ・パスワードを保存します。
モバイルSSOエージェントは、クライアント・アプリケーションにアクセス・トークンを渡します。
クライアント・アプリケーションは、アクセス・トークンを提示することで、保護されたリソースにアクセスします。
このシナリオでは、Mobile and Socialと互換性があるブラウザベースのWebアプリケーションを起動するMobile and Socialに登録されたモバイル・デバイスを使用するユーザーについて説明します。このシナリオでは、モバイルSSOエージェントがインストールされています。レガシー認証のプロセスを、次のフローで説明します。このプロセスの説明に後に、図41-6を示します。
ユーザーがモバイル・デバイスのWebブラウザでURLを開きます。
アプリケーションWebサーバーにより、ブラウザがAccess Managerにリダイレクトされます。
Access ManagerはWebブラウザにURLリダイレクトを送信します。
WebブラウザはモバイルSSOエージェントを起動することでリダイレクトに応答します。
エージェントがインストールされていない場合は、モバイルSSOエージェント・アプリケーションをインストールするためのリンクと指示が表示されます。
モバイルSSOエージェントは、ユーザー・ログイン・ページを表示します。
ユーザーは、ユーザー名とパスワードを入力します。
モバイルSSOエージェントは、ユーザー名、パスワードおよびクライアント登録ハンドルをMobile and Socialサーバーに送信します。(この手順は図には示されていません。)
Mobile and Socialサーバーはクライアント登録ハンドルを検証して、Access Managerで資格証明を認証し、IDコンテキストをAccess Managerサーバーに発行してから、リスク分析のためにOAAMを起動します。
Access Managerは、ユーザー・トークンまたはアクセス・トークンをMobile and Socialサーバーに返します。このサーバーは、そのユーザー・トークンまたはアクセス・トークンをモバイルSSOエージェントに返します。(この手順は図には示されていません。)
モバイルSSOエージェントはMobile and Socialサーバーにブラウザをリダイレクトして、このサーバーでCookieを注入します。
モバイルSSOエージェントは、WebブラウザにURLリダイレクトとアクセス・トークンを送信します。
モバイルWebブラウザはリダイレクトに応答しますが、今回はアクセス・リクエストにアクセス・トークンが含まれているため元のWeb URLを開きます。
アプリケーションWebサーバーによって、リクエストされたページがモバイルWebブラウザに送信されます。
図41-6 登録済モバイル・デバイス上のブラウザベースWebアプリケーションからのユーザー認証
次の図は、モバイル・サービスのコンテキストで、モバイル・アプリケーションとOracle Access Management OAuthサービス間の相互作用を大まかに示しています。レガシー認可フローとモバイルOAuth認可フロー間の相違を理解するには、第41.2.2項「モバイル・サービス認可フローの理解」を参照してください。
OAuthサービスのコンテキストでのOAuth認可フローの詳細は、第45.3.3項「モバイルOAuth認可の理解」を参照してください。
モバイル・アプリケーションは、デバイス・トークンを送信して、クライアント検証コードをリクエストします。
OAuthサービスは、クライアント検証コードを返します。APNS/GCMオプションが有効な場合、OAuthサービスはプッシュ通知を使用してコードの半分を返し、HTTPSを経由して残りの半分を返します。プッシュ通知は、アプリケーションおよびデバイスのアイデンティティを確認するために保証レベルを追加します。
モバイル・アプリケーションは、デバイス要求とクライアント検証コードを送信して、認可コードをリクエストします。
OAuthサービス:
ユーザーを認証します
アプリケーションの登録にユーザーの承認を求めます(オプション)
リスク分析のためにOAAMを起動します
プッシュ通知(オプション)とHTTPSを使用して認可コードを返します
モバイル・アプリケーションは、認可コードとデバイス要求を送信して、クライアント・トークンをリクエストします。
OAuthサービスは、プッシュ通知(オプション)とHTTPSを使用してクライアント・トークンを返します。
モバイル・アプリケーションは、クライアント・トークン、認可コードおよびデバイス要求を送信して、アクセス・トークンをリクエストします。
OAuthサービスは、アクセス・トークンを返します。
モバイル・アプリケーションは、アクセス・トークンを使用して保護されているリソースへのアクセスをリクエストします。(図には示されていません。)
リソース・サーバーは、保護されているリソースをクライアント・アプリケーションに返します。(図には示されていません。)
次の各項では、モバイル・サービスを使用する方法について説明します。
保護されたリソースにアクセスを試行するモバイル・デバイスは、Mobile and Socialサーバーに登録されている必要があります。これは、このサーバーの登録エンドポイントに送信された匿名のリクエストは、このサーバーによって拒否されるためです。さらに、各サービス・ドメインは、アプリケーションを登録する場合に、ユーザー・パスワードまたはユーザー・トークンを要求するように構成する必要があります。次に、モバイル・クライアントとモバイル・アプリケーションの登録エンドポイントの例を示します。
https:// host : port /idaas_rest/rest/mobileservice1/register
Mobile and Socialへの登録時、JavaクライアントSDKまたはREST APIを使用するクライアント・アプリケーションは、次のスキームの1つ以上を使用するサーバーに有効な資格証明を提示する必要があります。
HTTP Basic認証
ユーザーIDとパスワード(UIDPASSWORD)
OAMトークン認証
AndroidまたはiOS SDKを使用するクライアント・アプリケーションではクライアント登録ハンドルが取得され、クライアント登録ハンドルではUIDPASSWORD認証スキームを使用して登録が保護されます。
Android、iOSおよびJava SDKは、トークン、資格証明およびMobile and Socialサーバーによって要求される他のデータを送信します。表41-4は、クライアント・デバイスまたはアプリケーションに基づいて要求されるトークンおよび返されるトークンを示しています。
|
注意: 資格証明の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「cURLを使用したMobile and Social RESTコールの送信」のモバイル・サービスRESTリファレンス: 認証と認可に関する項を参照してください。 |
表41-4 Mobile and Socialサーバーのトークン要件
| 登録が必要なデバイスまたはアプリケーションのタイプ | Mobile and Socialサーバーによって要求されるトークン、資格証明またはデータ | 返されるトークンのタイプ |
|---|---|---|
|
非モバイル・デバイス(未登録) |
HTTPS上で送信されるクライアント・アプリケーションに関連付けられたIDとパスワード。 |
クライアント・トークン |
|
モバイルSSOエージェント・アプリケーション |
|
クライアント登録ハンドル |
|
モバイルSSOクライアント・アプリケーション (たとえば、Mobile and Socialに登録するためにモバイルSSOエージェント・アプリケーションを使用するビジネス・アプリケーション。) |
|
クライアント登録ハンドル |
モバイル・サービスのサービス・ドメインの構成時に、次のようにユーザー・プロファイル・サービスと認可サービスを保護できます。
ユーザー・プロファイル・サービス: ユーザー・プロファイル・サービスのセキュリティは、サービス・プロファイルに次を選択することで構成します。
認証サービス・プロバイダ(「OAMAuthentication」、「MobileOAMAuthentication」、「JWTAuthentication」、モバイルJWT認証、ソーシャル・アイデンティティ認証など)を選択します。
「セキュア・アプリケーション」セキュリティ・トークンと「セキュア・ユーザー」セキュリティ・トークンを要求することで、サービスを保護します。
「読取りの許可」および「書込みの許可」オプションを設定します。
認可サービス - : 認可サービスのセキュリティは、サービス・プロファイルに次を選択することで構成します。
認証サービス・プロバイダ(「OAMAuthentication」、「MobileOAMAuthentication」、「JWTAuthentication」、モバイルJWT認証、ソーシャル・アイデンティティ認証など)を選択します。
「セキュア・アプリケーション」セキュリティ・トークンと「セキュア・ユーザー」セキュリティ・トークンを要求することで、サービスを保護します。
開発者は、Oracle Access Management Access Managerや、10gまたは11gR1 PS1 (11.1.1.5)バージョンのOracle Access Managerで保護されたリソースにアクセスするアプリケーションを簡単に作成できます。Mobile and Social SDKは、資格証明コレクション・インタフェースを使用してユーザーの資格証明を収集した後は、認証をプログラム的に処理します。その後、SDKでは、アプリケーション用に構成されたトークン・サービスにより、Mobile and Social RESTインタフェースを使用してユーザーが認証されます。Access Managerを使用するモバイル・サービスの認証フローの詳細は、第41.3.1項「ユーザー認証によるモバイル・デバイスの登録」を参照してください。
Oracle Adaptive Access Manager (OAAM)を使用して、実行時の認証を決定することもできます。たとえば、認可されていない国や場所からユーザーの認証が実行された場合に認証を拒否できます。また、次の機能もサポートされています。
マルチパート・ログイン・フロー: たとえば、OAAMがリスクのある使用パターンや通常外の使用パターン(ユーザーが通常の時間以外にデバイスを使用していたり、最後の認証から地理的に遠く離れている場合など)を検知すると、ナレッジベース認証の質問でユーザーが本人であるか確認したり、ワンタイム・パスワード(OTP)機能を使用した認証をユーザーに要求できます。
デバイス属性(デバイスに割り当てられているMACアドレスなど)をチェックします。また、デバイスがジェイルブレークされていないことを検証します。デバイスの属性に基づいて、OAAMでアクセスを許可または拒否できます。
また、Mobile and SocialとともにOAAMを使用する場合は、デバイス選択消去もオプションです。
登録されたデバイス情報に基づいて、OAAMでは特定のデバイスをホワイトリストまたはブラックリストに記載できます。
Mobile and SocialとOAAMを併用する方法の詳細は、第42.9.2項「Oracle Adaptive Access Manager用のモバイル・サービスの構成」を参照してください。
ソーシャル・アイデンティティを使用すると、Mobile and Socialは、Google、Yahoo、Facebook、Twitter、Windows Live、Foursquare、LinkedInなどの一般的なクラウドベースのアイデンティティ認証および認可サービスとの相互作用中に、リライイング・パーティ(RP)の役割を果たすことができます。信頼できるアイデンティティ・プロバイダの資格証明を使用して保護されたリソースにログインできると、ユーザーにとって便利です。Mobile and Socialをデプロイすると、各プロバイダを個別に実装しなくても、便利な複数のログイン・オプションをユーザーに提供できます。ユーザーはクラウドベースのアイデンティティ・サービスの資格証明を使用して、次の3つのアプリケーション・タイプにログインできます。
Java準拠のアプリケーション・サーバー上で実行されるWebアプリケーション。Webアプリケーションにソーシャル・アイデンティティ機能を追加するには、ソーシャル・アイデンティティ・クライアントSDKを使用してWebアプリケーションをMobile and Socialサーバーに接続します。詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「ソーシャル・アイデンティティ・クライアントSDKを使用したアプリケーションの開発」の章を参照してください。
Access Managerや、10gまたは11.1.1.5バージョンのOracle Access Managerで保護されているアプリケーション。Oracle Access Management製品のAccess Managerサービスによって保護されているアプリケーションか、10gまたは11gR1 PS1バージョンのOracle Access Managerによって保護されているアプリケーションは、SDKを使用しないで、ソーシャル・アイデンティティとともに動作するように構成できます。認証フローの詳細は、第41.6.4項「Access Managerとソーシャル・アイデンティティによるユーザー認証」を参照してください。
AndroidまたはiOSを実行するモバイル・アプリケーション。AndroidまたはiOSを実行するモバイル・アプリケーションは、ソーシャル・アイデンティティ・プロバイダを使用して認証するように構成できます。Mobile and Socialサーバーに接続するには、AndroidアプリケーションおよびiOSアプリケーションで各プラットフォーム対応のモバイル・サービスSDKを使用します。別個のSDKは不要です。
ソーシャル・アイデンティティは、次の標準をサポートするアイデンティティ・プロバイダにサービスを提供します。
OpenIDバージョン2.0
OpenID Simple Registration Extension 1.0
Open ID Attribute Exchange Extension 1.0
OpenID Provider Authentication Policy Extension 1.0
OAuth 1.0および2.0
表41-5に示したアイデンティティ・プロバイダのネイティブ・サポートは、Mobile and Socialのインストール後に提供されます。
表41-5 Mobile and Socialがネイティブにサポートするアイデンティティ・プロバイダ
| アイデンティティ・プロバイダ | サポートされているプロトコル |
|---|---|
|
|
OAuth 2.0 |
|
|
OAuth 2.0 |
|
|
OAuth 2.0 |
|
|
OAuth 2.0 |
|
Yahoo |
OpenID 2.0 |
|
Foursquare |
OAuth 2.0 |
|
Windows Live |
OAuth 2.0 |
Javaプログラマは、Javaインタフェースを実装し、Mobile and Socialコンソールを使用してJavaクラスをMobile and Socialデプロイメントに追加することで、追加のOpenIDおよびOAuthアイデンティティ・プロバイダに対するリライイング・パーティのサポートを追加できます。詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「Mobile and Socialサーバーの機能の拡張」を参照してください。
次のシナリオでは、ソーシャル・アイデンティティを使用しているときのBasic認証プロセスについて説明します。
ユーザーが保護されたリソースへのアクセスを要求すると、Mobile and Socialにリダイレクトされます。
Mobile and Social (RP)は、Googleなど(アイデンティティ・プロバイダ)の資格証明を使用してログインするかどうかをユーザーに尋ねます。
Mobile and Socialは、ユーザー名とパスワードを入力するGoogleのログイン・ページにユーザーをリダイレクトします。
Googleは資格証明を検証し、ユーザーをMobile and Socialにリダイレクトします。それと同時に、アイデンティティ・プロバイダは、その構成に基づいて、Mobile and Socialにアイデンティティの属性を返します。
ユーザーが組織のアカウントを持っていない場合は、ユーザーにアカウントを登録するように促します。登録フォームは、アイデンティティ・プロバイダから返された情報で入力済にされています。
|
注意: Access Managerの場合、ユーザーはローカルに登録されている必要があります。それ以外の場合は、アクセスが許可されません。Access Managerを使用していないときには、ユーザーは保護されたリソースにリダイレクトされ、ユーザーが登録されていない場合でもアクセスが許可されます。詳細は、第41.7.1項「ソーシャル・アイデンティティとOracle Access Managerの併用」を参照してください。 |
追加のシナリオについては、この項で説明します。
このシナリオでは、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)、アイデンティティ・プロバイダおよびローカル・ユーザー認証サービス(図ではLocal AuthおよびID Repositoryで表示)の間の認証フローを説明します。このシナリオでは、ユーザーがすでにローカル・アカウントを持っているかどうかは、ローカル・アイデンティティ・リポジトリによって判断されます。そのため、Mobile and Socialが作成のプロンプトを表示することはありません。このプロセスの説明に後に、図41-8を示します。
ユーザーがWebブラウザで保護されたリソースのURLを開くと、Mobile and Socialサーバーは、ログイン・ページとアイデンティティ・プロバイダ(Google、Yahoo、Facebook、Windows Live、Foursquare、Twitter、LinkedInなど)の選択メニューをユーザーに表示します。
ユーザーがアイデンティティ・プロバイダを選択します。
Mobile and Socialサーバーが選択されたアイデンティティ・プロバイダにユーザーをリダイレクトすると、ログイン・ページが表示されます。
ユーザーが認証時にユーザー名とパスワードを入力すると、アイデンティティ・プロバイダはMobile and Socialサーバーに認証アサーションを送信します。
ユーザーがローカル・アカウントを持っているかどうかについて、Mobile and Socialサーバーがアイデンティティ・リポジトリに問い合せます。
アイデンティティ・リポジトリは、ディレクトリ・サーバー、データベース、Oracle Identity Managerまたはそれに類似したものになります。このユーザーは、ローカル・アカウントを持つユーザーであると判断されます。
モバイル・アプリケーションまたは直接統合されたWebアプリケーションがMobile and Socialを使用して認証している場合は、Mobile and Socialサーバーはユーザーのブラウザに認証アサーションを送信します。
Access Mangerによって保護されたアプリケーションが認証している場合は、ユーザーがローカル・アカウントを持っている場合のみ、Access Managerはユーザーのためにセッションを作成します。(新しく登録されたユーザーは、ローカル・アカウント保持者とみなされます。)
ユーザーのブラウザは、Mobile and Socialによって送信された認証アサーションを、保護されたリソースのアクセス管理サービスに送信します。
アクセス管理サービスは、必要に応じて追加の認証ステップを実行します。
アクセス管理サービスが、保護されたリソースへのユーザーのアクセスを許可します。
このシナリオでは、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)、アイデンティティ・プロバイダおよびローカル・ユーザー認証サービス(図ではLocal AuthおよびID Repositoryで表示)の間の認証フローを説明します。このシナリオでは、ユーザーはローカル・アカウントを持っていないため、Mobile and Socialによりアカウントの作成が求められます。このプロセスの説明に後に、図41-9を示します。
ユーザーがWebブラウザで保護されたリソースのURLを開くと、Mobile and Socialサーバー(この図ではRP)は、ユーザー・ログイン・ページとアイデンティティ・プロバイダ(Google、Yahoo、Facebook、Twitter、LinkedInなど)の選択メニューをユーザーに表示します。
ユーザーがアイデンティティ・プロバイダを選択します。
Mobile and Socialサーバーは選択されたアイデンティティ・プロバイダにユーザーをリダイレクトし、このプロバイダがログイン・ページを表示します。
ユーザー認証時にユーザーがユーザー名とパスワードを入力すると、アイデンティティ・プロバイダはMobile and Socialサーバーに認証アサーションを送信します。
ユーザーがローカル・アカウントを持っているかどうかについて、Mobile and Socialサーバーがアイデンティティ・リポジトリに問い合せます。
アイデンティティ・リポジトリは、ディレクトリ・サーバー、データベース、Oracle Identity Managerまたはそれに類似したものになります。このユーザーは、ローカル・アカウントを持たないユーザーであると判断されます。Mobile and Socialによって、次のように続行されます。
アイデンティティ・プロバイダがOpen IDプロトコルを使用する場合は、Mobile and Socialサーバーは以前に取得された認証アサーションのデータを処理することで、ユーザーのプロファイル属性を取得します。
アイデンティティ・プロバイダがOAuthプロトコルを使用する場合は、Mobile and Socialサーバーは以前に取得されたアクセス・トークンを使用してアイデンティティ・プロバイダに別個のHTTPコールを行って、ユーザーのプロファイル属性を取得します。
Mobile and Socialサーバーは、新規ユーザー登録フォームをユーザーのブラウザに送信します。
この登録フォームは、アイデンティティ・プロバイダによって送信されたユーザー・プロファイル属性を使用して入力済にされています。
ユーザーは登録フォームの入力を完了して、そのフォームをインタフェース接続しているユーザー・レジストリ(ディレクトリ・サーバーまたはOracle Identity Manager)に送信し、アカウントを作成します。
アイデンティティ・プロバイダからアクセス・トークンが取得される場合は、アクセス・トークンもMobile and Socialからクライアント・アプリケーションに返されます。
クライアント・アプリケーションのアクセス管理サービスは、追加の認証ステップを必要に応じて実行します。
アクセス管理サービスが、保護されたリソースへのユーザーのアクセスを許可します。
この項では、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)およびOAuthアイデンティティ・プロバイダ間のOAuth認証およびアクセス・トークン取得フローに関する補足的な詳細を説明します。(Facebook、FoursquareおよびWindows LiveではOAuth 2.0プロトコルが、LinkedInとTwitterではOAuth 1.0プロトコルが使用されています。)このシナリオでは、サーバーはOAuthアイデンティティ・プロバイダとインタフェース接続して、OAuthアイデンティティ・プロバイダによって保護されたリソースにアクセスするための認可コードとアクセス・トークンを取得します。このシナリオのクライアント・アプリケーションは、Java準拠のアプリケーション・サーバー上で実行しているWebアプリケーションまたはモバイル・アプリケーションのどちらかになります。このプロセスの説明に後に、図41-10を示します。
ユーザーがクライアント・アプリケーションを開始すると、そのアプリケーションは保護されたWebページをユーザーのブラウザに返します。
ユーザーがクライアント・アプリケーション上で保護されたリソースを開こうとします。
ユーザーが保護されたリソースにアクセスできるように、クライアント・アプリケーションはMobile and Socialサーバーにアクセス・トークンの取得を求めます。
Mobile and Socialのキャッシュ内に有効なアクセス・トークンがある場合は、Mobile and Socialによってアクセス・トークンがクライアント・アプリケーションにフォワードされ、認証シナリオは手順10にスキップします。このフローでは、Mobile and Socialがローカル・キャッシュにアクセス・トークンを保持していないと仮定します。
アクセス・トークンがローカル・キャッシュに存在しないため、Mobile and SocialはユーザーのかわりにOAuthアイデンティティ・プロバイダによる認可リクエストを開始します(OAuthクライアントID、スコープ情報およびリダイレクトURLを埋め込むためにHTTPヘッダーを利用します)。
OAuthアイデンティティ・プロバイダは、ログイン・ページを表示します。
ユーザーがOAuthアイデンティティ・プロバイダのログイン・ページにユーザー名とパスワードを入力して、ユーザーのプロファイル属性をMobile and Socialサーバー(および拡大解釈してクライアント・アプリケーション)に提供することをアイデンティティ・プロバイダに対して承認します。
OAuthアイデンティティ・プロバイダは、認可コードをMobile and Socialサーバーに送信します。
Mobile and Socialサーバーは、アクセス・トークン・リクエストをOAuthアイデンティティ・プロバイダに送信します。
リクエストには、前の手順で受信された認可コードに加え、OAuthクライアントIDおよびクライアント資格証明が含まれます。
OAuthアイデンティティ・プロバイダは、アクセス・トークンをMobile and Socialサーバーに返します。
Mobile and Socialサーバーは、アクセス・トークン(ユーザーIDとOAuthクライアントを含む)をキャッシュして、そのアクセス・トークンをクライアント・アプリケーションに転送します。
クライアント・アプリケーションはアクセス・トークンを使用して保護されたリソースにアクセスし、保護されたページをユーザーのブラウザに返します。
このシナリオでは、ユーザー、Access Manager、Mobile and Socialサーバー(リライイング・パーティ)およびアイデンティティ・プロバイダ間の認証プロセスを説明します。ユーザーは、ローカル・アカウントを持っているか、求められたときにローカル・アカウントに登録する必要があることに注意してください。そのようにしないと、Access Managerは保護されたリソースへのユーザーのアクセスを許可しないため、ユーザーはログイン・ページにリダイレクトされます。このプロセスの説明に後に、図41-11を示します。
ユーザーがクライアント・アプリケーション上で保護されたリソースを開こうとします。
リソースを保護するWebゲートが、アクセス・リクエストをインターセプトします。
Access Managerがリソースを保護する認証ポリシーを識別し、Mobile and Socialサーバーが提供するログイン・ページにユーザーをリダイレクトします。
ログイン・ページに、ソーシャル・アイデンティティ・プロバイダのメニューが表示されます。
ユーザーはOpenIDアイデンティティ・プロバイダを選択し、Access ManagerはユーザーのブラウザをMobile and Socialサーバーにリダイレクトします。Mobile and Socialサーバーはユーザーのブラウザを、選択されたソーシャル・アイデンティティ・プロバイダ(Google、Facebook、Twitterなど)のログイン・ページにリダイレクトします。
ユーザーはソーシャル・アイデンティティ・プロバイダのログイン・ページにユーザー名とパスワードを入力します。
アイデンティティ・プロバイダが認証プロセスを完了し、アイデンティ情報の共有に対するユーザーの承認を求めます(該当する場合)。
認証が完了すると、ソーシャル・アイデンティティ・プロバイダはブラウザをリダイレクトしてMobile and Socialサーバーに戻します。
アイデンティティ・プロバイダが提供するアイデンティ・アサーションのさらなる処理とユーザー・アイデンティティ情報の取得の後、Mobile and SocialサーバーはユーザーのブラウザをAccess Managerにリダイレクトします。今回は、ページ・リクエストのHTTPヘッダーで、ユーザーの認証ステータスと属性をAccess Managerに提供します。
Access Managerはユーザー・セッションを作成し、保護されたリソースにユーザーをリダイレクトします。
このシナリオでは、ユーザーがソーシャル・アイデンティティ・プロバイダを通じた認証を選択するかわりに、ローカル・アカウントを使用して認証する場合の認証プロセスを説明します。このプロセスの説明に後に、図41-12を示します。
ユーザーが保護されたリソースのURLをWebブラウザで開くと、Mobile and Socialサーバーがログイン・ページとアイデンティティ・プロバイダの選択メニューをユーザーに表示します。
ユーザーはローカル認証の使用を選択して、ログイン・ページにユーザー名とパスワードを入力します。
クライアント・アプリケーションのアクセス管理サービスは、追加の認証ステップを必要に応じて実行します。
JWTトークン・サービスを使用する場合は、ユーザー・トークンを作成できます。
OAMトークン・サービスは、ローカル認証フロー時にトークンを返しません。
アクセス管理サービスがユーザーのためにセッションを作成し、ユーザーは保護されたリソースにアクセスします。
次の各項では、ソーシャル・アイデンティティを使用する方法について詳細に説明します。ソーシャル・アイデンティティの統合方法の例については、第41.6項「ソーシャル・アイデンティティのプロセスの理解」を参照してください。
ソーシャル・アイデンティティをAccess Managerと統合する場合に、ユーザーは、ソーシャル・アイデンティティ・プロバイダからの資格証明を使用して、Access Managerで保護されたリソースにログインすることを選択できます。このアレンジでは、ユーザーは自分たちのアイデンティティ・プロバイダの資格証明を入力します。Access Managerは、ユーザーのログイン・リクエストをMobile and Socialにフォワードし、Mobile and Socialはバックグラウンドのアイデンティティ・プロバイダを使用して認証プロセスを完了します。Mobile and Social (リライイング・パーティ)は、ユーザーをAccess Managerにリダイレクトします。同時に、Mobile and SocialはAccess Managerに、アイデンティティ・プロバイダが送信したユーザーの認証ステータスとユーザー属性を提供します。Access Managerが認証にソーシャル・アイデンティティを使用する方法の詳細は、第41.6.4項「Access Managerとソーシャル・アイデンティティによるユーザー認証」を参照してください。
ソーシャル・アイデンティティを使用してモバイル・デバイスで認証できるように、モバイル・サービスを構成できます。アイデンティティ・プロバイダによってユーザーの資格証明が検証された後に、組織でのアカウントを作成するようにソーシャル・アイデンティティによってユーザーに促すことができます。アイデンティティ・プロバイダから返されたデータで新規ユーザー登録フォームを入力済にする場合は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「ソーシャル・アイデンティティ・クライアントSDKを使用したアプリケーションの開発」を参照してください。
Java準拠のWebアプリケーションを保守する開発者は、Mobile and Socialソーシャル・アイデンティティSDKを使用して、そのWebオファリングにソーシャル・アイデンティティ機能を追加できます。このSDKは、Javaが駆動するWebアプリケーションでのみ使用できます。SDKの詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「ソーシャル・アイデンティティ・クライアントSDKを使用したアプリケーションの開発」の章を参照してください。
