プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11g リリース2 (11.1.2.3) for All Platforms
E61950-08
目次へ移動
目次

前
次

48.3 Mobile and Socialサービスのプロセスの理解

保護されたリソースにユーザーがアクセスしようとすると、Mobile and Socialによってクライアント・トークン(クライアントの資格証明を安全に格納するサーバーまたはコンピュータを通してユーザーが接続している場合)またはクライアント登録ハンドル(ユーザーがモバイル・デバイスを使用している場合)が要求されます。保護されたリソースへのアクセス権を付与するには、クライアント・デバイス(モバイル・デバイスを含む)とクライアント・アプリケーションをMobile and Socialサーバーに登録する必要があります。

ノート:

また、アプリケーションは通常、ユーザー・トークンとアクセス・トークンを要求するように構成されています。

モバイル・デバイス上で実行するクライアント・アプリケーションが、この高度な認証プロセスに従った後で、モバイル・アプリケーションは保護されたリソースにアクセスできるようになります。

  1. ユーザーは、アプリケーションのログイン画面でユーザー名とパスワードを入力して、Mobile and Socialサーバーで認証されます。

  2. モバイル・デバイスがMobile and Socialサーバーにまだ登録されていない場合、ユーザーの認証後に、このサーバーはモバイル・デバイスにクライアント登録ハンドルを送信します。

  3. クライアント登録ハンドルがMobile and Socialサーバーに返されて、ユーザー・トークンが取得されます。

  4. クライアント登録ハンドルとユーザー・トークンがMobile and Socialサーバーに返されて、アクセス・トークンが取得されます。

非モバイル・アプリケーションも、Mobile and Socialサービスが提供する認証サービスを利用できます。そのような場合は、クライアント登録ハンドルのかわりにクライアント・トークンが使用されます。クライアント・トークンを取得すると、前述したようにユーザー・トークンとアクセス・トークンをリクエストできます。追加のシナリオについては、この項で説明します。

48.3.1 ユーザー認証によるモバイル・デバイスの登録フロー

モバイル・デバイスが保護されたリソースにアクセスしようとしたときに、そのデバイスがMobile and Socialにまだ登録されていない場合は、モバイルSSOエージェントをインストールする必要があります。

登録認証プロセスは、次のフローで説明します。このプロセスの説明の後に、図48-1図48-2を示します。

  1. ユーザーがモバイル・デバイスでアプリケーションを起動します。

  2. アプリケーションは、ユーザーをモバイルSSOエージェントにリダイレクトします。

  3. モバイルSSOエージェントにより、ログイン・ページが表示されます。

  4. ユーザーは、ユーザー名とパスワードを入力します。

  5. モバイルSSOエージェントは、デバイス属性およびアプリケーションIDとともに、ユーザー名とパスワードをMobile and Socialサーバーに送信します。

  6. Mobile and Socialサーバーはユーザー名とパスワードを、ユーザーを認証するAccess Managerにフォワードします。

  7. 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ハンドルは削除されます。

  8. Mobile and Socialサーバーは、モバイル・クライアント登録ハンドル、OAAMデバイス・ハンドルおよびOAAMセッション・ハンドルを、モバイルSSOエージェントに返します。

  9. モバイルSSOエージェントは、以前に受信したクライアント登録ハンドルとOAAMデバイス・ハンドルをサーバーに渡すことで、ユーザー・トークンを取得します。

  10. モバイルSSOエージェントは、Access Managerのアクセス・トークンをリクエストします。このリクエストには、クライアント登録ハンドルとOAAMデバイス・ハンドルが含まれています。図48-2を参照してください。

図48-1 初回時のデバイス/アプリケーション登録と認証プロセス

図48-1の説明が続きます
「図48-1 初回時のデバイス/アプリケーション登録と認証プロセス」の説明

図48-2 Access Managerからのアクセス・トークンをリクエストするモバイルSSOエージェント

図48-2の説明が続きます
「図48-2 Access Managerからのアクセス・トークンをリクエストするモバイルSSOエージェント」の説明

48.3.2 登録済デバイスによるユーザーの認証フロー

モバイル・デバイス(Mobile and Socialに登録済)を使用するユーザーがMobile and Socialと互換性のあるビジネス・アプリケーションを起動する場合、モバイルSSOエージェントがすでにインストールされていて、ユーザーはアクセス・トークンを必要とする保護されたリソースにアクセスする必要があります。

ビジネス・アプリケーションは、アクセス・トークンをリクエストするために、最初にユーザー・トークンを取得する必要があります。添付の図(図48-3図48-4)は、このプロセスを示しています。

  1. ユーザーがモバイル・デバイスでビジネス・アプリケーションを起動します。

  2. ビジネス・アプリケーションは、モバイルSSOエージェントにユーザー・トークンを求めます。このとき、次のいずれかが行われます。

    1. ローカル資格証明ストアに有効なユーザー・トークンが存在する場合、モバイルSSOエージェントは、そのトークンをビジネス・アプリケーションに返します。ビジネス・アプリケーションは、Mobile and Socialサーバーにアクセス・トークンを求める直接リクエストに、ユーザー・トークンを挿入します。ビジネス・アプリケーションが、サーバーから返されたアクセス・トークンを使用して保護されたリソースにアクセスした時点で、このフローは完了します(図48-3を参照)。

      図48-3 資格証明ストアに有効なアクセス・トークンを持つモバイルSSOエージェント

      図48-3の説明が続きます
      「図48-3 資格証明ストアに有効なアクセス・トークンを持つモバイルSSOエージェント」の説明
    2. ローカル資格証明ストアに有効なユーザー・トークンが存在しない場合は、次のようにログイン・フローを続行します(図48-4を参照)。

  3. モバイルSSOエージェントはログイン・ページを表示し、ユーザーはユーザー名とパスワードを入力します。

  4. モバイルSSOエージェントは、ユーザー名、パスワードおよびクライアント登録ハンドルをMobile and Socialサーバーに送信します。(図48-4のステップ2)。

  5. Mobile and Socialサーバーはクライアント登録ハンドルを検証して、ユーザー資格証明を(JWTトークン・サービスまたはAccess Managerトークン・サービスを使用して)認証し、リスク分析のためにOAAMを起動します。その後で、ユーザー・トークンをモバイルSSOエージェントに返します。(図48-4のステップ3)。

  6. モバイルSSOエージェントはユーザー・トークンのコピーをそのローカル資格証明ストアに格納し、そのユーザー・トークンをビジネス・アプリケーションに返します。(図48-4のステップ4)。

  7. ビジネス・アプリケーションはそのユーザー・トークンを使用して、Mobile and Socialサーバーにアクセス・トークンを直接リクエストします。(このステップは図には示されていません。)

  8. Mobile and SocialサーバーからモバイルSSOエージェントにアクセス・トークンが返されます。

  9. ビジネス・アプリケーションは、アクセス・トークンを使用して、Access ManagerまたはOracle Enterprise Gateway (OEG)で保護されたリソースを呼び出します。(図48-4のステップ5)。

図48-4 資格証明ストアに有効なトークンを持たないモバイルSSOエージェント

図48-4の説明が続きます
「図48-4 資格証明ストアに有効なトークンを持たないモバイルSSOエージェント」の説明

48.3.3 ユーザー認証のためのRESTコールのフロー

モバイル・デバイスで稼働しているアプリケーションはモバイルSSOエージェントにインタフェース接続し、エージェントはRESTコールを使用してMobile and Socialサーバーと通信します。

サーバーは必要に応じてAccess ManagerおよびOAAMとインタフェース接続し、モバイルSSOエージェントに(再度RESTコールを使用して)必要なトークンを返します。エージェントは、アプリケーションにトークンを送り返します。このアプリケーションは、保護されたリソースにRESTコールまたはSOAPコールを使用してアクセスできるようになります。このプロセスについて、次のフローで説明します。このプロセスの説明に後に、図48-5を示します。

  1. ユーザーがモバイル・デバイスでアプリケーションを起動します。

  2. クライアント・アプリケーションはAccess Managerによって保護されたリソースにアクセスする必要があるため、モバイルSSOエージェントにアクセス・トークンの取得を要求します。

  3. モバイルSSOエージェントは、Mobile and Socialサーバーからアプリケーション・プロファイルを取得します。

  4. モバイルSSOエージェントは、ユーザー名とパスワードの入力を求めます。

  5. モバイルSSOエージェントは、デバイス属性およびアプリケーションIDとともに、ユーザー名とパスワードをMobile and Socialサーバーに送信します。

  6. Mobile and Socialサーバーがデバイスを登録し、ユーザーを認証します。

  7. サーバーからモバイルSSOエージェントにアクセス・トークンが返されます。

  8. モバイルSSOエージェントは、ローカル資格証明ストアにハッシュ・パスワードを保存します。

  9. モバイルSSOエージェントは、クライアント・アプリケーションにアクセス・トークンを渡します。

  10. クライアント・アプリケーションは、アクセス・トークンを提示することで、保護されたリソースにアクセスします。

図48-5 RESTを使用するユーザー認証

図48-5の説明が続きます
「図48-5 RESTを使用するユーザー認証」の説明

48.3.4 モバイルのブラウザベースのWebアプリケーションによるユーザーの認証フロー

Mobile and Socialに登録されたモバイル・デバイスを使用するユーザーがMobile and Socialと互換性があるブラウザベースのWebアプリケーションを起動すると、モバイルSSOエージェントがインストールされます。

レガシー認証のプロセスを、次のフローで説明します。このプロセスの説明に後に、図48-6を示します。

  1. ユーザーがモバイル・デバイスのWebブラウザでURLを開きます。

  2. アプリケーションWebサーバーにより、ブラウザがAccess Managerにリダイレクトされます。

  3. Access ManagerはWebブラウザにURLリダイレクトを送信します。

  4. WebブラウザはモバイルSSOエージェントを起動することでリダイレクトに応答します。

    エージェントがインストールされていない場合は、モバイルSSOエージェント・アプリケーションをインストールするためのリンクと指示が表示されます。

  5. モバイルSSOエージェントは、ユーザー・ログイン・ページを表示します。

  6. ユーザーは、ユーザー名とパスワードを入力します。

  7. モバイルSSOエージェントは、ユーザー名、パスワードおよびクライアント登録ハンドルをMobile and Socialサーバーに送信します。(このステップは図には示されていません。)

  8. Mobile and Socialサーバーはクライアント登録ハンドルを検証して、Access Managerで資格証明を認証し、IDコンテキストをAccess Managerサーバーに発行してから、リスク分析のためにOAAMを起動します。

  9. Access Managerは、ユーザー・トークンまたはアクセス・トークンをMobile and Socialサーバーに返します。このサーバーは、そのユーザー・トークンまたはアクセス・トークンをモバイルSSOエージェントに返します。(このステップは図には示されていません。)

  10. モバイルSSOエージェントはMobile and Socialサーバーにブラウザをリダイレクトして、このサーバーでCookieを注入します。

  11. モバイルSSOエージェントは、WebブラウザにURLリダイレクトとアクセス・トークンを送信します。

  12. モバイルWebブラウザはリダイレクトに応答しますが、今回はアクセス・リクエストにアクセス・トークンが含まれているため元のWeb URLを開きます。

  13. アプリケーションWebサーバーによって、リクエストされたページがモバイルWebブラウザに送信されます。

図48-6 登録済モバイル・デバイス上のブラウザベースWebアプリケーションからのユーザー認証

図48-6の説明が続きます
「図48-6 登録済モバイル・デバイス上のブラウザベースWebアプリケーションからのユーザー認証」の説明

48.3.5 モバイルOAuth認可フローを使用した認可

Mobile and Socialサービスに関連したモバイル・アプリケーションとOracle Access Management OAuthサービス間のやり取りは、OAuth認可フローを表しています。

レガシー認可フローとモバイルOAuth認可フロー間の相違を理解するには、「Mobile and Socialサービス認可フローの理解」を参照してください。

OAuthサービスに関連したOAuth認可フローの詳細は、「モバイル・クライアント用のOAuthサービスの認可の理解」を参照してください。

  1. モバイル・アプリケーションは、デバイス・トークンを送信して、クライアント検証コードをリクエストします。

    OAuthサービスは、クライアント検証コードを返します。APNS/GCMオプションが有効な場合、OAuthサービスはプッシュ通知を使用してコードの半分を返し、HTTPSを経由して残りの半分を返します。プッシュ通知は、アプリケーションおよびデバイスのアイデンティティを確認するために保証レベルを追加します。

  2. モバイル・アプリケーションは、デバイス要求とクライアント検証コードを送信して、認可コードをリクエストします。

    OAuthサービス:

    • ユーザーを認証します

    • アプリケーションの登録にユーザーの承認を求めます(オプション)

    • リスク分析のためにOAAMを起動します

    • プッシュ通知(オプション)とHTTPSを使用して認可コードを返します

  3. モバイル・アプリケーションは、認可コードとデバイス要求を送信して、クライアント・トークンをリクエストします。

    OAuthサービスは、プッシュ通知(オプション)とHTTPSを使用してクライアント・トークンを返します。

  4. モバイル・アプリケーションは、クライアント・トークン、認可コードおよびデバイス要求を送信して、アクセス・トークンをリクエストします。

    OAuthサービスは、アクセス・トークンを返します。

  5. モバイル・アプリケーションは、アクセス・トークンを使用して保護されているリソースへのアクセスをリクエストします。(図には示されていません。)

    リソース・サーバーは、保護されているリソースをクライアント・アプリケーションに返します。(図には示されていません。)