| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
サーバー側シングル・サインオン(SSO)機能を使用すると、1つのデバイス上の複数のモバイル・アプリケーションが、クライアントではなくOAMサーバーに存在する1つのユーザー・セッションを共有できます。
この機能によって、JWTユーザー・トークンとOAMユーザー・トークンがサーバー側デバイス・ストアに保存され、Cookieを使用してユーザー・セッションがブラウザで管理されます。したがって、サーバー・セッションはクライアントに関連付けられません。クライアント・トークン、ユーザー・トークンおよびアクセス・トークンのセッション・タイムアウト値は、サービス・プロファイル・レベルで構成可能です。また、アクセス・トークンのタイムアウト値は、リソース・サーバー・レベルでオーバーライドすることもできます。
機密的なセッション情報を(デバイスでなく)サーバー上に保持することで、デバイスまたはクライアント・アプリケーションが危殆化された場合にトークンがコピーされるリスクを低減できます。2-leggedフローの場合、サーバー側シングル・サインオンをオフにすると(デフォルトではオン)、ユーザー・トークンはサーバーに格納されず、モバイル・デバイス上のクライアントに送信されます。この機能は、モバイルOAuthサービスのサービス・プロファイル構成ページを使用して有効および無効にできます。3-leggedフローの場合、サーバー側シングル・サインオンは常に自動的に有効になります。
組織の開発者は、外部ブラウザや埋込みブラウザを使用するか、Mobile and SocialサービスにSSOプロキシとして登録されているネイティブ・アプリケーションを使用して、クライアント・アプリケーションにシングル・サインオンを実装できます。
この項では、様々な方法を簡単に説明します。
モバイル・アプリケーションが外部ブラウザに切り替わり、外部ブラウザがユーザー認証およびユーザー承認管理のロジックを実行します。
共有のブラウザCookieは、ユーザー・セッションを維持し、複数のアプリケーション間でSSOを提供するために使用されます。外部ブラウザは、OAMユーザー認証、JWTユーザー認証、サード・パーティ・ユーザー認証および(ソーシャル・アイデンティティ・サービスを使用する)ソーシャル認証をサポートする、一般的なWeb SSOメカニズムを使用します。外部ブラウザを使用することのデメリットは、アプリケーション・コンテキストがブラウザとアプリケーション間で切り替わるときに発生する画面の"ちらつき"です。
モバイル・アプリケーションで独自の埋込みブラウザを使用します。ブラウザCookieを複数のアプリケーション間で共有できないので、OAMおよびサード・パーティSSO認証は使用できません。
そのかわりに、モバイルOAuthサービスでは、サーバー側デバイス・ストアに格納されているJWTユーザー・セッション・トークンが使用されます。追加のアプリケーションを起動するときは、デバイスIDと共有JWTユーザー・セッション・トークンを組み合せて使用して、SSOが確立されます。埋込みブラウザを使用する方法では、アプリケーションと外部ブラウザ間でアプリケーション・コンテキストを切り替えるときに発生する画面の"ちらつき"がなくなります(「外部ブラウザによる方法」を参照)。
ネイティブ・アプリケーションがすでにデバイスにインストールされている場合、これがブラウザベースのアプリケーションとOAMサーバー上のモバイルOAuthサービスSSOサーブレットの間のプロキシとなるため、SSOが容易になります。
必要に応じて、OAMで保護されたリソースへのアクセスを可能にするために、サーブレットはデバイスおよびアプリケーションをOAMに登録し、ブラウザでアプリケーションを認証するために必要なトークンを取得します。この方法を使用する場合、ネイティブ・アプリケーションはMobile and Socialサービスを使用してAccess Managerに対する認証を行う必要があります。この方法は、2-leggedフローで使用できます。
ユーザーは1回ログインすれば、再度ログインを要求されることなくすべてのシステムにアクセスできるようになります。JWT認証、サード・パーティ認証およびソーシャル認証の場合、OAMサーバーはユーザー・トークンをデバイス・ストアに格納しますが、OAM認証の場合は(OAMセッションを表す) OAM_IDをデバイス・ストアに格納します。ユーザー・トークンまたはOAM_IDが期限切れになると、ユーザーは再度ログインを要求されます。
モバイル3-leggedシナリオを実装する場合は、Oracle Access ManagementコンソールのモバイルOAuthサービス・クライアントの構成ページに移動して、認可コード権限タイプを有効にします。アプリケーションは、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』に記載されているモバイル3-leggedフローを実装する必要があります。
モバイルOAuthサービス3-leggedシナリオを使用するアプリケーションでは、モバイル・ブラウザ(「サーバー側シングル・サインオン資格証明コレクション・オプションの理解」を参照)を使用して、資格証明を収集する必要があります。Oracle Access Managementコンソールを使用して認証タイプを指定するには、モバイルOAuthサービスのサービス・プロファイル構成ページを開いて、「モバイル・サービスの設定」で「承認サービス保護」のオプションを選択します。次の各項では、これらのオプションについて説明します。
OAM認証またはサード・パーティのアクセス管理
OAM認証またはサード・パーティのアクセス管理を使用している場合、Access Manager (またはサード・パーティのアクセス管理製品)がユーザー認証を処理します。ブラウザを介したログインをサポートするOAM認証方式は、いずれもオプションです。Access ManagerではOAM_ID Cookieを使用するSSOがサポートされているため、このフローでは外部ブラウザ(「外部ブラウザによる方法」を参照)を使用する必要があります。認証後、ユーザー・トークンがサーバー側デバイス・ストアに格納されます。
Oracle Access Managementではセッション同期がサポートされており、後から2-leggedフローでOAMトークンを取得できます。たとえば、最初のアプリケーションが、3-leggedフローを使用してサーバーに登録します。次に、2番目のアプリケーションが、最初のアプリケーションにより確立された既存のセッションを使用して2-legged登録を完了します。このように、3-leggedフロー・セッションでは、最初のアプリケーション登録中に作成されたセッションと同じセッションを使用することにより、2-leggedフローを使用する追加のアプリケーションを登録できます。
JWT認証
JWT認証は、モバイル・アプリケーション用にMobile and Socialで提供される認証メカニズムです。この場合、Mobile and Socialは、ユーザー・ログイン用のユーザー・インタフェースをホストします。これは、ユーザー認証用に構成済のユーザー・ストアを使用して、認証用のユーザー名とパスワードを受け入れます。ユーザー・ストアは、Mobile and Social (つまりOracle Access Management)で構成できます。「OAuthサービス」プロファイルの「ユーザー・ストア」にある「ユーザー・オーセンティケータ」を使用して構成します。
前述のように、JWTユーザー認証は、埋込みブラウザを使用するシングル・サインオンをサポートする唯一の認証タイプです。(同じモバイル・デバイス上で複数のアプリケーションを使用する必要がない場合は、OAM認証またはサード・パーティ認証で十分です。)JWT認証には外部ブラウザを使用することもできますが、Mobile and Socialがデバイス・ストア内のシングル・サインオンのためにユーザー・トークンをチェックするときに、アプリケーションからブラウザに切り替えたり、ブラウザからアプリケーションに戻したりする必要があります。
ソーシャル認証
ソーシャル認証を使用すると、アプリケーション・ユーザーはFacebookやTwitterなどのソーシャル・アイデンティティ・プロバイダを使用して認証できます。このタイプの認証には、Oracle Access Managementソーシャル・アイデンティティ・サービス(Mobile and Socialの一部)が必要です。ソーシャル認証を使用する場合、Oracle Access Managementサーバーはユーザーを認証のためにソーシャル・アイデンティティ・プロバイダにリダイレクトします。シングル・サインオンを使用する場合、外部ブラウザが必要です。認証後、ユーザー・トークンがサーバー側デバイス・ストアに格納されます。ソーシャル認証は、3-leggedフローでのみサポートされています。
モバイルOAuthサービス2-leggedシナリオを使用するアプリケーションでは、ユーザー名/パスワード・ベースのOAM認証またはIDS (ディレクトリ・サーバー)に制限されますが、ネイティブのiOSおよびAndroidユーザー・インタフェース使用して、ユーザー資格証明を収集する必要があります。
外部ブラウザに切り替えることにより、サポートされている通常の認証スキーム(OAMユーザー認証、サード・パーティ認証、JWTユーザー認証など)を使用できます。
モバイル3-leggedシナリオとは異なり、モバイル2-leggedシナリオでは、サーバー側シングル・サインオン機能を無効にするように選択できます。これを無効にするには、モバイルOAuthサービスのサービス・プロファイル構成ページを開き、「サーバー側のシングル・サインオンの有効化」オプションをクリアします。(WLSTを使用してサーバー側SSOを設定することもできます。)
サーバー側SSOが有効になっている場合、サーバーがクライアントにかわってユーザー資格証明を収集し、SSOを提供します。その他のアプリケーション(つまり、同じデバイス・プロファイルを共有するアプリケーション)は、初回起動時にサーバーに登録する必要があります。アプリケーション登録のたびにユーザーの認証を要求したり、ユーザーの操作なしでバックグラウンドで自動的に登録されるように設定することもできます。「サービス・プロファイル」ページでmsAlwaysShowLogin属性を構成して、目的の動作を選択します。
サービス・プロファイル属性msAlwaysShowLoginがtrueに設定されている場合、ユーザーはネイティブ・アプリケーションでユーザー名とパスワードを入力して、アプリケーションを登録し、クライアント・トークンを取得する必要があります。
この属性がfalseに設定されている場合、サーバーがサーバー側ユーザー・トークンを使用してアプリケーションを自動的に登録します。
登録後は、デバイス上のアプリケーションからアクセス・リクエストが送信されると、通常、サーバーがクライアント・トークンを提供してアクセスを許可します。(Oracle Adaptive Access Managerルールがアクティブになっている場合など、ユーザーがすぐにアクセス権を取得できない場合もあります。)
サーバー側SSOが無効になっている場合、クライアントがユーザー資格証明を収集し、さらにSSOを提供する必要があります。最初のアクセス試行で、ユーザーはネイティブ・アプリケーションにユーザー名とパスワードを入力して、デバイスを登録します。サーバーがユーザー・トークンを返し、それがデバイスにローカルに格納されます。デバイスのアプリケーションから行われる以降のアクセス・リクエストでは、格納されたユーザー・トークンを使用してアプリケーションを登録し、アクセス権を取得する必要があります。
モバイル2-leggedシナリオでは、Oracle Access ManagementコンソールのモバイルOAuthサービス・クライアントの構成ページに移動して、リソース所有者権限タイプを有効にします。アプリケーションは、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』に記載されているモバイル2-leggedフローを実装する必要があります。次の各項では、SSOオプションの概要について説明します。
(外部または埋込みの)モバイル・ブラウザを使用するユーザーが、保護されたWebリソースにアクセスする必要がある場合、OAMに対する認証にMobile and Social Servicesを使用するネイティブ・アプリケーションがすでにデバイスにインストールされていれば、そのネイティブ・アプリケーションがWebアプリケーションにかわってデバイスを登録し、ユーザーにサインオンを要求することなくリソースにアクセスできます。
このシングル・サインオン方法では、OAMサーバーのリリース11.1.2.3で追加されたOAuth Mobile SSOサーブレットを使用します。構成ステップは、「SSOサーブレット認証のためのモバイルOAuthの構成」を参照してください。
ネイティブ・アプリケーションおよび外部ブラウザで実行されるアプリケーションを使用する方法としては他に、OAuthサービスREST APIを使用してネイティブ・アプリケーションに2-leggedフローを実装する方法もあります。
サーバー側SSOは有効にすることも無効にすることもできます。ネイティブ・アプリケーションがデバイスとユーザーを登録し、OAMトークンを交換してOAM_ID Cookie (OAMマスター・トークン)を取得します。ネイティブ・アプリケーションが外部ブラウザを起動してOAM_ID Cookieを挿入できるため、外部ブラウザを使用してWebゲートで保護されたリソースにアクセスするユーザーは、毎回ログインを要求されることがありません。2-leggedフローの実装の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
