| 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 |
|
前 |
次 |
この章では、OAuthサービスの用途と機能について説明します。内容は次のとおりです。
OAuthサービスを使用することで、Access Manager環境で、オープン・スタンダードであるOAuth 2.0 Web認可プロトコルを組織に実装できます。OAuthにより、クライアントは、他のユーザー(リソース所有者)に属するAccess Managerの保護されたリソースにアクセスできます。
OAuthサービスを使用することで、組織は新規または既存のAccess Manager環境にOAuth 2.0を実装し、OAuthクライアントがOAuth 2.0フローを使用してAccess Managerで保護されているリソースにアクセスできるようになります。OAuthクライアントは、組織で作成および制御されるアプリケーションまたはサービスか、Access Managerで保護されているリソースにアクセスする必要のある別の組織で作成および制御されるアプリケーションまたはサービスのいずれかです。
|
注意: ユーザーがクラウドベースのアイデンティティ・サービスからの資格証明を使用して保護されているリソースにログインできるようにするOAuthフローの使用の詳細は、第41.6.3項「OAuthを使用したアクセス・トークンの取得」を参照してください。 |
次の各項では、OAuthサービスについて詳細に説明します。
OAuthは、あらゆるタイプのクライアント(モバイル・アプリケーションや他のサービスを含む)とWeb上の別のサービス間のトークン化された認証およびアクセス制御を提供する際の推奨方法となったオープン・スタンダードなWeb認可プロトコルです。Oracle Access Management OAuthサービスは、IETF OAuthワーキング・グループによって開発されたOAuth 2.0仕様を実装しています。OAuthにより、クライアントは、別のユーザー(リソース所有者)に属しているリモート・サーバーのリソースにアクセスできるようになります。最も一般的なOAuth認可フローでは、クライアントはユーザーの資格証明とは異なる一連の資格証明を発行されます。中間認可サービスは、ユーザーのリソースをホストするクライアントおよびサービスと直接相互作用し、ユーザーがクライアントにその資格証明を開示しないようにします。
OAuth仕様は次の4つのロールを定義します。
リソース所有者: 保護されているリソースへのアクセス権を付与することが可能な個人またはエンティティ。
リソース・サーバー: 保護されているリソースをホストするサーバー。リソース・サーバーは、アクセス・トークンを使用して保護されているリソースのリクエストを受け入れ、応答可能である必要があります。
クライアント: リソース所有者のかわりに、リソース所有者の認可を使用して、保護されているリソースのリクエストを作成するアプリケーション。
認可サーバー: リソース所有者を正常に認証し、認可を取得した後で、クライアントにアクセス・トークンを発行するサーバー。1つの認可サーバー・インスタンスが、複数のリソース・サーバーによって受け入れられるアクセス・トークンを発行できます。
OAuth仕様は、リソース・サーバーと認可サーバー間の相互作用に特別な要件を課していません。リソース・サーバーは、アクセス・トークンを使用して保護されているリソースのリクエストを受け入れ、応答可能であることのみ必要です。
OAuthサービスは、次のコンポーネントで構成されます。
サーバー・コンポーネント: Oracle Access Managementの一部として管理します。サーバー・コンポーネントは、Access Managerとともに、認可サービスおよびOAuthトークン・サービスを提供します。サーバーは、クライアント、リソース所有者およびリソース・サーバーと相互作用します。サーバー・コンポーネントは、クライアントおよびリソース・サーバーを登録し、トークン・ライフサイクル管理を管理する場所です。
ユーザー・プロファイル・サービス: OAuth 2.0認可をサポートし、クライアントがバックエンド・ディレクトリ・サーバーと相互作用して、個人、グループおよび関係エンティティ上でユーザー・プロファイルREST操作を実行できるようにします。
承認管理サービス: OAuthユーザー承認レスポンスを格納および追跡します。
OAuthサービスは、3-legged OAuth、2-legged OAuth、およびOAuthクライアントがモバイル・デバイスに存在する場合の拡張セキュリティをサポートします。
3-legged OAuth認可
OAuth 3-legged認可では、リソース所有者は、OAuthリソース・サーバーに格納されているリソースにアクセスするために、OAuth対応クライアント(リクエスト・サイト)にアクセス権を付与します。Oracle Access Management認可サーバーは、リソース所有者のアイデンティティを検証し、承認が必要な場合は、所有者に承認フォームを提供します。この認証スキームの3番目の脚は、ユーザーがクライアント・アクセス権を付与または拒否するステップです。
2-legged OAuth認可
OAuth 2-legged認可では、OAuthクライアントはリソースにアクセスすることが事前に承認されています。このアレンジは、サービス対サービスのモデルに適合し、特に、リクエスト・サービスおよびリソース・サービスが密接なパートナシップを持ち、リソース所有者の承認が想定されるか、必要とされない場合に特に適しています。
モバイルOAuth
Oracle Access Management OAuthサービスは、OAuthクライアントがモバイル・デバイスに存在する場合は、拡張セキュリティ・サポートを提供します。この拡張セキュリティ・サポートは、OAuth 2.0仕様で定義されたベースライン・セキュリティ対策に追加されたものです。モバイル・デバイスでは、OAMサーバー上の認可エンドポイントがモバイル・アプリケーションと相互作用する前に、OAuthクライアントがクライアント検証コードを取得する必要があります。また、OAMサーバー・コンポーネントは、HTTPSを介してトークンの一部を送信し、Apple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)のいずれかを使用してプッシュ通知により他の部分を送信して、特定のデバイスにインストールされた特定のアプリケーションにトークンの配信を制限できます。Mobile OAuthシングル・サインオンにより、デバイス上の複数のモバイル・アプリケーションが、クライアントではなく、サーバー上に存在する同じユーザー・セッションを共有できます。
SDKサポート
OAuthサービス・アプリケーション開発用のSDKは、このリリースには含まれていません。AndroidデバイスおよびiOSデバイス用のSDKと、Java仮想マシン(JVM)用のSDKが含まれています。
モバイル・セキュリティにブラウザを使用するアプリケーションは、モバイルOAuth認可フローを使用します。このフローでは、ユーザー・セッションはサーバー上で作成され、Cookieを使用してブラウザで維持されます。アクセス・トークンを除いて、サーバーはOAAMデバイス・ハンドルやOAAMセッション・ハンドル、ユーザー・トークンなどのセキュリティ・マテリアルをモバイル・デバイスに送信せず、それをサーバー側デバイス・ストアに格納します。アクセス・トークンは、クライアントに送信され、サーバー側デバイス・ストアに格納されて、検証およびライフ・サイクル管理に提供されます。
モバイルOAuth認可フローを使用するクライアント・アプリケーションは、組織がモバイルOAuthクライアントの管理に使用するOAuthアイデンティティ・ドメインでOAuthサービスに登録する必要があります。このフローでは、サーバーの認可エンドポイントがモバイル・アプリケーションと相互作用する前に、クライアントが事前認可クライアント検証コードを取得することも必要です。有効な場合、HTTPSを介して追加のクライアント検証コードの一部を送信し、Apple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)のいずれかを使用してプッシュ通知を介して他の部分を送信することにより、サーバーはより確実に特定のデバイスにインストールされた特定のアプリケーションと通信できます。
このフローは、ユーザー承認管理をサポートしています。承認管理が有効な場合、クライアント・アプリケーションは、ユーザーに、Access Managerに登録するためのアプリケーションのリクエストを受け入れるか拒否するよう求めます。
|
注意: OAMコンソールの「OAuthサービス」の下で、モバイルOAuth認可フローを使用するブラウザベースのアプリケーションを登録します。 |
モバイルOAuth認可フローを詳細に説明する図は、第45.3.3項「モバイルOAuth認可の理解」を参照してください。
OAuthサービスには、HTTPSリクエストを受け取り、応答する3つの認証エンドポイント、認可エンドポイント、トークン・エンドポイントおよびプッシュ・エンドポイントがあります。各エンドポイントは、クライアントがOAuth認証リクエストの作成に使用するURLです。
認可エンドポイント: クライアントはリソース所有者から認可を取得して、リクエストされたリソースにアクセスするために認可エンドポイントを使用します。エンドポイントは、ユーザー・エージェントをリダイレクトし、リソース所有者にログインしてアクセス・リクエストに承認するよう求めます。クライアント・アプリケーションは認可エンドポイント・リクエストを開始します。このエンドポイントは、HTTPSリクエストを受け入れ、入力パラメータおよびヘッダー(ある場合)を検証して、リダイレクトURIに認可コードを追加し、最後にそのURLにクライアントをリダイレクトします。このエンドポイントのURIの最後は常にauthorizeです。例:
http(s)://<host>:<port>/ms_oauth/oauth2/endpoints/<yourOauthServiceName>/authorize
トークン・エンドポイント: クライアント・アプリケーションは認可付与またはリフレッシュ・トークンをアクセス・トークンと交換するために、トークン・エンドポイントと相互作用します。クライアントはリフレッシュ・トークンを使用して、新しいアクセス・トークンを取得します。このエンドポイントのURIの最後は常にtokenです。例:
http(s)://<host>:<port>/ms_oauth/oauth2/endpoints/<yourOauthServiceName>/token
プッシュ・エンドポイント: Mobile OAuthクライアント・アプリケーションは、認可コードの一部や、Apple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)サービスのいずれかを使用して送信されるクライアント・トークン、アクセス・トークンおよびリフレッシュ・トークンの一部(構成によって異なる)を取得するために、プッシュ・エンドポイントと相互作用します。
ユーザー認証失効エンドポイント: リソースの所有者(エンド・ユーザー),は、ブラウザベースの認可エンドポイント・フローを使用してクライアント・アプリケーションを認証および認可し、このエンドポイントを使用してクライアント・アプリケーションに対する認証を失効させます。例:
http(s)://<host>:<port>/ms_oauth/oauth2/ui/<yourOauthServiceName>/showrevokeconsent
OAuthサーバーを構成する際には、サーバーがクライアントに認可資格証明を返すことが可能な少なくとも1つのクライアント・リダイレクトURIを提供することも必要です。
クライアント・リダイレクトURI: OAuthサーバーは、クライアント・プロファイルで構成されたURIと正確に一致する場合、リクエストで指定されたURIを使用して、クライアントに認可資格証明を返します。
OAuthサービスは、クライアントがリフレッシュ・トークンを使用して同じまたはより狭いスコープの追加のアクセス・トークンを取得できるように構成できます。オフライン・スコープは、クライアントがオフラインの場合にリフレッシュ・トークンにアクセス・トークンを発行するスコープです。サーバーは、クライアントがリソース・サーバー構成で定義されているオフライン・スコープをリクエストする場合にリフレッシュ・トークンを発行します。詳細は、第46.4.5.3項「OAuthリソース・サーバーの構成ページの理解」を参照してください。
クライアントはリフレッシュ・トークンを使用するように構成することも必要です。リフレッシュ・トークン設定の詳細は、第46.4.2.3項「OAuthサービス・プロファイルの構成ページの理解」および第46.4.3.3項「OAuth Webクライアントの構成ページの理解」を参照してください。
組織内の開発者は、外部ブラウザか埋込みブラウザを使用して、クライアント・アプリケーションにモバイル・セキュリティを実装できます。この項では、様々な方法を簡単に説明します。
外部ブラウザによる方法
この方法では、クライアント・アプリケーションは外部ブラウザに切り替え、そこでユーザー認証およびユーザー承認管理のロジックを実行します。共有のブラウザCookieは、ユーザー・セッションを維持し、複数のアプリケーション間でシングル・サイオンを提供するために使用されます。外部ブラウザは、OAM SSOユーザー認証およびサード・パーティSSOユーザー認証を含む、通常のWebシンブル・サインオン・メカニズムを使用します。外部ブラウザを使用することのデメリットは、アプリケーション・コンテキストがブラウザとアプリケーション間で切り替わるときに発生する画面のちらつきです。
埋込みブラウザによる方法
この方法は、埋込みブラウザを使用して、アプリケーションと外部ブラウザ間でアプリケーション・コンテキストを切り替えるときに発生する画面のちらつきをなくします。ただし、ブラウザCookieは、複数のアプリケーション間で共有できないため、通常のWebシングル・サインオン・メカニズムは使用できません。かわりに、OAMでは、シングル・サインオンに独自のWebユーザー認証を使用します。
OAMおよびサード・パーティSSOユーザー認証の理解
モバイルOAuthクライアント・アプリケーションは、関係クライアント・アプリケーションが外部ブラウザを使用して実装される場合に、OAM SSOユーザー認証またはサード・パーティSSOユーザー認証のいずれかを使用できます。外部ブラウザはそのセキュリティCookieを共有できるため、複数のモバイルおよびWebクライアントが同時にOAMまたはサード・パーティSSOのいずれかを使用できます。
JWT SSOユーザー認証の理解
埋込みブラウザは、ユーザーが同じモバイル・デバイス上の複数のアプリケーションにログインする必要がある場合は、OAMまたはサード・パーティSSOユーザー認証を使用できません。かわりに、JWTユーザー・セッション・トークンが使用され、ユーザー・セッションとともにデバイスIDを使用してシングル・サインオンが確立されます。(同じモバイル・デバイス上で複数のアプリケーションを使用できる必要がない場合は、OAM SSOまたはサード・パーティSSOで十分です。)
Oracle Access Managementでは、ユーザー認証時にJWTユーザー・セッション・トークンを生成し、このトークンによりシングル・サインオン・ユーザー・セッションの基礎が形成されます。JWTユーザー・セッションは、サーバー側デバイス・ストアに格納および維持されるため、同じデバイス上で実行されている複数のモバイル・クライアント・アプリケーションは、JWTユーザー・セッション・トークンを共有できます。
この項では、OAuthサービスの概念およびトランザクション・フローについて詳しく説明します。
OAuth 3-legged認可では、リソース所有者は、クライアントにリソース・サーバーに格納されているリソースにアクセスする権限を付与します。認可サーバーは、リソース所有者のアイデンティティを検証し、承認が必要な場合は承認フォームを提供します。テキストの後の図45-1は、このプロセスを示しています。
リソース所有者(ユーザー)が、クライアント・アプリケーションがリソース所有者に属する別のサイト上の保護されているリソースにアクセスすることを必要とするユーザー・エージェント(ブラウザなど)のアクションを起動します。
クライアント・アプリケーションは認可サーバーの認可エンドポイントを起動して、OAuthフローを開始します。クライアント・アプリケーションは、そのクライアント識別子、リクエストされたスコープ、およびアクセスが許可または拒否されると認可サーバーがユーザー・エージェントをダイレクトするリダイレクションURIを送信します(手順10を参照)。
OAuth認可サービスはリソース所有者の資格証明を要求するため、認可サービスは、リソース所有者のパスワード資格証明をリクエストするようにユーザー・エージェントをリダイレクトします。
Access Managerは、ユーザー・ログインUIを表示し、リソース所有者にユーザー名とパスワードを求めます。認可サーバーはAccess Managerによって提供されるすべての認証スキームをサポートします。
リソース所有者はユーザー名とパスワードを入力します。
Access Managerは、ログインを検証し、ユーザー・エージェントを認可サービスにリダイレクトします。
認可サービスは、認可コードをクライアントに送信する前に、リソース・サーバーでユーザーの承認が必要であると判断します。
認可サービスは、ユーザー承認フォームを表示します。
ユーザーはリクエストを承認します。
認可サービスは、手順2のリダイレクションURIを使用してクライアントに認可コードを返します。
クライアントは、トークン・エンドポイントにPOSTリクエストの認可コードを送信し、OAuthアクセス・トークンをリクエストします。リクエストを作成する際に、クライアントは認可サーバーを使用して認証します。クライアントには検証用に認可コードを取得するために使用するリダイレクションURIが含まれます。
クライアント・タイプがクライアント資格証明を必要とする場合、OAuthサービスはクライアント資格証明を認証し、認可コードを検証して、受信したリダイレクションURIが手順10でクライアントをリダイレクトするために使用するURIに一致していることを確認します。
OAuthサービスは、リソース・サーバーの構成およびユーザー承認の詳細に基づいてリクエストされたスコープを検証します。
OAuthサービスは、次の権限タイプのクライアントにアクセス・トークンを返します。
認可コード
リソース所有者の資格証明
クライアント資格証明
JWTトークンをサポートする拡張権限タイプ
リフレッシュ・トークンは、クライアントがリフレッシュ・トークン・リクエストを送信すると、アクセス・トークンとともに返される場合もあります。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
クライアントはリソース・サーバーにアクセス・トークンを提供します。
リソース・サーバーは認可サーバーのトークン・エンドポイントにリクエストを送信して、アクセス・トークンを検証します。アクセス・トークンは標準のJWTトークンであるため、リソースはトークン自体を検証することもできます。
アクセス・サービスは、トークン検証レスポンスをリソース・サーバーに戻します。
リソース・サーバーは、リクエストされたリソースをクライアントに返します。
OAuth 2-legged認可では、ユーザー承認手順は必要ありません。認可サーバーは、クライアントにリクエスト・トークンを返し、クライアントはそれを使用してアクセス・トークンをリクエストします。リクエスト・トークンは事前に認可されているため、認可サーバーのトークン・サービスはクライアントにアクセス・トークンを返します。
Oracle Access Management OAuthサービスは、OAuthクライアントがモバイル・デバイスに存在する場合は、拡張セキュリティ・サポートを提供します。モバイル・アプリケーションは、OAuthサービスを使用する前にOAMに登録する必要があり、各登録はデバイス上のアプリケーションに固有です。登録に続いて、モバイル・デバイス上のOAuthクライアントは、OAM認可エンドポイントがモバイル・アプリケーションと相互作用する前に、クライアント検証コードを取得する必要があります。追加された注意事項として、OAMサーバー・コンポーネントは、HTTPSまたはHTTPを介してトークンの一部を送信し、Apple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)のいずれかを使用してプッシュ通知により他の部分を送信することによって、トークンの配信を特定のデバイスにインストールされた特定のアプリケーションに制限できます。
この項で詳述されるユーザー・フローは、Oracle Access Managementがモバイル・クライアントによる認証時に実行する追加の相互作用を示しています。次の図に、このプロセスを示します。
リソース所有者がモバイルOAuthクライアント・アプリケーションを開きます。
OAM管理者はモバイルOAuthクライアントとしてこのクライアント・アプリケーションをすでに登録しています。
モバイルOAuthクライアントは、OAuthサーバーにクライアントIDとデバイス・トークンを送信し、クライアント検証コードをリクエストします。
OAuthサーバーはHTTPSまたはHTTPを介してクライアント検証コードの半分を返します。
この動作は、「OAuthサービス・プロファイル構成」ページの「モバイル・サービスの設定」セクションで構成できます。
セキュリティ・レベルが「詳細」に設定される場合、すべてのコードおよびトークンはHTTPおよびプッシュ通知の両方を使用して返されます。
セキュリティ・レベルが「混合」に設定される場合、登録関連のコードおよびトークンはHTTPおよびプッシュ通知の両方を使用して返されますが、アクセス・トークンはHTTPのみを介して送信されます。
セキュリティ・レベルが「標準」に設定される場合、すべてのコードおよびトークンはHTTPのみを介して送信されます。
モバイルOAuthクライアントが、OAuthサーバーのプッシュ・エンドポイントからクライアント検証コードの残りの半分をリクエストします。
プッシュ・エンドポイントは、モバイル・デバイスがiOSデバイスかAndroidデバイスかによって、Apple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)サービスにリクエストを送信します。
APNSまたはGCMサービスは、モバイル・クライアント・アプリケーションにクライアント検証コードの残りの半分を送信します。
モバイルOAuthクライアントはクライアント検証コードおよびデバイス・トークンを送信して、OAuthサーバーから認可コードをリクエストします。
OAuthサーバーはAccess Managerにリダイレクトします。
Access Managerは、ユーザーがログインできるように、ログイン・ページをユーザー・エージェントに送信します。
リソース所有者はユーザーIDとパスワードを入力します。
Access Managerは、ログインを検証し、OAuth認可サービスにリダイレクトします。
OAuthサーバーはデバイスを登録するためユーザーの承認を得るように構成されます。(「OAuthサービス・プロファイル構成」ページで「クライアント登録にはユーザー承認が必要」オプションが無効である場合、サーバーは、登録前にユーザーの承認を求めません。)
承認ページがリソース所有者に送信されます。
リソース所有者は承認を提供(または拒否)します。
OAuthサーバーはOracle Adaptive Access Manager (OAAM)プラグインを確認して、追加の認証手順が必要かどうかを判断します。
プラグインは、追加のチャレンジ質問が必要であると判断します。
OAAMチャレンジ質問がリソース所有者に送信されます。
リソース所有者は、チャレンジ質問の回答を提供し、その回答はOAAMプラグインに送信されます。
OAAMプラグインはチャレンジ質問の回答を検証します。
OAuthサーバーはモバイル・リダイレクトURIを使用して、モバイル・アプリケーションがクライアント・トークンをリクエストする必要がある認可コードの半分を返します。
モバイルOAuthクライアントはOAuthサーバーのプッシュ・エンドポイントから認可コードの残りの半分をリクエストします。
プッシュ・エンドポイントは、APNSまたはGCMサービスにリクエストを送信します。
モバイル・クライアント・アプリケーションは、APNSまたはGCMサービスから認可コードの残りの半分を受け取ります。
モバイル・クライアント・アプリケーションは、クライアント・トークンをリクエストする準備として認可コードをアセンブルします。
認可コードを検証した後で、モバイルOAuthクライアントはそのコードを使用して、OAuthサーバーのトークン・エンドポイントからクライアント・トークンの最初の半分をリクエストします。
トークン・エンドポイントは、モバイル・クライアントにクライアント・トークンの最初の半分を返します。
モバイル・クライアントは、OAuthサーバーのプッシュ・エンドポイントからクライアント・トークンの残りの半分をリクエストします。
APNSまたはGCMサービスは、モバイル・クライアント・アプリケーションにクライアント・トークンの残りの半分を送信します。
モバイル・クライアントは、クライアント・トークンをリフレッシュ・トークンとともにアセンブルします。クライアントは、リフレッシュ・トークンを使用して、新しいクライアント・トークンをリクエストできます。
モバイル・クライアントは、次の手順を完了して、アクセス・トークンをリクエストする準備をします。
クライアントはOAuthサーバーからクライアント検証コードをリクエストし、受信します(手順2から5を参照)。
クライアントは、OAuthサーバーから認可コードの最初の部分をリクエストし、受信します(手順6、手順10-13および手順19を参照)。
リソース所有者は、ユーザー・セッションが有効なままである場合は、ログインする必要はありません(手順7-9)。
ユーザーの承認は、クライアントがアクセスをリクエストしているリソース・サーバー・スコープに基づいて要求される場合があります。
OAAMプラグインはそのチャレンジを繰り返しません(手順14-18)。
クライアントは認可コードの残りの部分をリクエストします(手順20-21を参照)。
APNSまたはGCMサービスは、アクセス・トークンの認可コードの残りの半分を返します。
クライアントは、アクセス・トークン・リクエストの準備として認可コードをアセンブルします。
モバイル・クライアントは、クライアント・トークンおよびアクセス・トークン認可コードを送信して、アクセス・トークンをリクエストします。
トークン・エンドポイントは、クライアントにアクセス・トークンを送信します。この動作は、「OAuthサービス・プロファイル構成」ページの「モバイル・サービスの設定」セクションで「セキュリティ・レベル」設定が「詳細」、「混合」または「標準」のどれに設定されているかによって異なります。
モバイルOAuthクライアントは、リソース・サーバーにアクセス・トークンを送信して、保護されているリソースへのアクセスをリクエストします。
リソース・サーバーはOAuthトークン・サービスを使用してアクセス・トークンを検証します。リソース・サーバーはトークンをローカルに検証することもできます。証明書が正しく構成されている場合は、JWTトークン署名がリソース・サーバーで検証されます。
OAuthトークン・サービスはリソース・サーバーにレスポンスを送信します。
リソース・サーバーはモバイル・クライアントにリクエストされたリソースを送信します。
