| 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 |
|
|
前 |
次 |
サービス・プロバイダは、クライアント・アプリケーションで使用可能なバックエンド・サービスごとに定義します。
これにより、Mobile and Socialサーバーが定義済のバックエンド・サービス・プロバイダとインタフェース接続する方法を構成します。提供しているサービスに応じて、使用可能なサービス・プロバイダ・オプションの1つまたは2つを構成するだけでよい場合があります。たとえば、認証サービスのみを提供する場合、「ユーザー・プロファイル・サービス・プロバイダ」や「認可サービス・プロバイダ」を定義する必要はありません。
サービス・プロバイダを定義するには、次の各トピックについて理解を深める必要があります。
認証サービス・プロバイダを使用すると、Mobile and Socialはトークン交換によるバックエンド認証サービスを使用してユーザー、クライアント・アプリケーションおよびアクセス権を認証できます。
認証と検証の成功時に、トークンがクライアント・アプリケーションに返される場合があります。サポートされる認証タイプは、次のとおりです。
Access Managerと一緒にインストールした場合、Mobile and SocialはJSON Web Token (JWT)とAccess Manager (OAM)トークンをサポートします。
Access Managerと一緒にイントールしていない場合は、JSON Web Token (JWT)型のみがサポートされます。
ノート:
Webゲートを使用するMobile and Socialのデプロイの詳細は、「Mobile and Socialのデプロイメント制約」を参照してください。
次の各トピックでは、認証サービス・プロバイダについて説明します。
Mobile and Socialでは、リストされている認証サービスに対して事前構成済の認証サービス・プロバイダが用意されています。
詳細は、表49-1を参照してください。
トークン・タイプ(Access ManagerとJWT)ごとに、Mobile and Socialでは「すぐに使用できる」個別のモバイルおよび非モバイル(またはデスクトップ)サービス・プロバイダ構成が提供されます。個別の構成は、それぞれを各アクセス・モードのニーズに最も合わせて最適化できるようにするために提供されています。モバイル・デバイスは、モバイル・サービス・プロバイダを使用する必要がありますが、非モバイル・デバイスは、モバイル・サービス・プロバイダと非モバイル・サービス・プロバイダの両方を使用できます(適切な入力を提供している場合)。
モバイル・サービス・プロバイダは、クライアント登録ハンドルを使用して、モバイル・デバイスを登録します。これに対して、非モバイル・サービス・プロバイダは、クライアント・トークンを使用して、非モバイル・デバイスを認証します。Mobile and Socialのクライアント・トークン機能は無効にできますが、クライアント登録ハンドル機能は無効にできません。
表49-1 事前構成済の認証サービス・プロバイダ
| 認証サービス | Mobile and Socialサービス・プロバイダ名 | 説明 |
|---|---|---|
Access Manager |
OAMAuthentication |
デスクトップ・デバイスを使用しているユーザーが、Access Managerを使用して認証を受けるための事前構成済サポートを提供します。 このサービス・プロバイダは、クライアント・トークンを発行できますが、モバイル・デバイスの登録はできません。 次のJavaクラスがこのサービス・プロバイダを実装します: oracle.security.idaas.rest.provider.token.OAMSDKTokenServiceProvider |
Mobile Access Manager |
MobileOAMAuthentication |
モバイル・デバイスを使用しているユーザーが、Access Managerを使用して認証を受けるための事前構成済サポートを提供します。 このサービス・プロバイダは、ユーザーの認証時におけるクライアント登録ハンドルを使用した新しいデバイスの登録をサポートしています。 次のJavaクラスがこのサービス・プロバイダを実装します: oracle.security.idaas.rest.provider.token.MobileOAMTokenServiceProvider |
JSON Web Token |
JWTAuthentication |
非モバイル・アプリケーションを使用しているユーザーが、JSON Web Token形式を使用して認証を受けるための事前構成済サポートを提供します。JSON Web Tokenは、HTTP認可ヘッダーなど、領域に制約がある環境に適したコンパクトなトークン形式です。 このサービス・プロバイダは、クライアント・トークンを発行できますが、クライアント登録ハンドルを使用した新しいデバイスの登録はできません。 次のJavaクラスがこのサービス・プロバイダを実装します: oracle.security.idaas.rest.provider.token.JWTTokenServiceProvider |
Mobile JSON Web Token |
MobileJWTAuthentication |
モバイル・デバイスを使用しているユーザーが、Mobile JSON Web Token形式を使用して認証を受けるための事前構成済サポートを提供します。 このサービス・プロバイダは、クライアント登録ハンドルを使用した新しいデバイスの登録をサポートしています。 次のJavaクラスがこのサービス・プロバイダを実装します: oracle.security.idaas.rest.provider.token.MobileJWTTokenServiceProvider |
JWT-OAMトークン・プロバイダ |
JWTOAMAuthentication |
軽量で継続時間の長いJWTトークンをOAMトークンと交換できるようにします。OAMトークンによりクライアントはSSOリソースおよびOAMリソースにアクセスできます。このプロバイダを使用して、非モバイル・アプリケーションを使用するユーザーは、継続時間の長い有効なJWTトークンがあれば、資格証明の提示なしで新しいOAMトークンを取得できます。 |
モバイルJWT-OAMトークン・プロバイダ |
MobileJWTOAMAuthentication |
軽量で継続時間の長いJWTトークンをOAMトークンと交換できるようにします。OAMトークンによりクライアントはSSOリソースおよびOAMリソースにアクセスできます。このプロバイダを使用して、モバイル・アプリケーションを使用するユーザーは、継続時間の長い有効なJWTトークンがあれば、資格証明なしで新しいOAMトークンを取得できます。 |
Social Identity Web Token |
InternetIdentityAuthentication |
Mobile and Socialサービスを使用するアプリケーションがソーシャル・アイデンティティ(たとえば、Google、Facebook、Twitterなど)から認証結果を受け入れるための事前構成済サポートを提供します。 このサービス・プロバイダは、クライアント登録ハンドルを使用した新しいデバイスの登録をサポートしています。ユーザーがアイデンティティ・プロバイダを使用して認証を受けた後、このサービス・プロバイダによって、要求側のクライアント・アプリケーションにユーザー・トークンが発行されます。このユーザー・トークンによって、ユーザーはそのデバイスのクライアント登録ハンドルを取得できます。 このサービスではJSON Web Tokenサービスと同じJavaクラスを使用しますが、それは追加された2つの名前と値の属性のペアで構成されます。 次のJavaクラスがこのサービス・プロバイダを実装します: oracle.security.idaas.rest.provider.token.JWTTokenServiceProvider |
使用するデプロイメントに応じて、1つ以上の継続時間の長いOAMトークンよりも、1つの継続時間の長いJWTトークンが必要な場合があります。JWTトークンは、軽量であるため、長時間の保持に適したトークンです。
JWT-OAMトークン交換機能を使用すると、ユーザー名およびパスワードでユーザーが認証され、JWTトークン、OAMユーザー・トークンおよびOAMマスター・トークンが取得されます。OAMトークンの継続時間と比較して、JWTトークンの継続時間が大幅に長くなるように構成できます。OAMトークンの有効期限が切れた場合は、クライアントはまだ有効な継続時間の長いJWTトークンを使用して、再度OAMトークンを取得します。
OAMトークンがあれば、モバイル・クライアントおよび非モバイル・クライアントはAccess Managerにより保護されたリソースにアクセスできます。JWTトークンのOAMトークンとの交換は、ユーザーにとってメリットがあります。有効期限の切れたトークンと取り替える新しいOAMトークンを、資格証明の提示なしで取得できるからです。
追加されたセキュリティ対策として、Mobile and Socialでは、OAMトークンを取得するためにJWTユーザー・トークンを使用する場合に、ユーザーにPINなどの追加の資格証明を入力することを要求できます。
「JWTトークンをOAMトークンと交換するためのユーザー資格証明の使用」を参照してください。
認証サービス・プロバイダを編集または削除できます。
パネルでサービス・プロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。
追加されたセキュリティ対策として、Mobile and Socialでは、OAMトークンを取得するためにJWTユーザー・トークンを使用する場合に、ユーザーにPINなどの追加の資格証明を入力することを要求できます。
ユーザーPIN要件を有効にするには、TokenExchangeInput属性の構成時に表49-5の説明のように、JWT_UT+CREDパラメータを指定します。
この機能を使用するには、ユーザーのPINまたは他の資格証明がディレクトリ・サーバーのユーザー・エントリに存在している必要があります。Mobile and Socialでは、資格証明の値を制限していません。ユーザーによって送信される資格証明の値をユーザー・エントリに存在する値で検証するのみです。セキュリティ上の理由から、ユーザー資格証明は、ハッシュ属性として保存される必要があります。
この構成を動作させるために必要なステップは、「JWT-OAMおよびPINトークン・サービス・プロバイダを使用するためのOAMの構成」を参照してください。
JWT-OAMおよびPINトークン・サービス・プロバイダを使用するようにOAMを構成できます。
構成するには、次のようにします。
ディレクトリ・サーバーを開いて、PIN属性のLDAPスキーマを拡張します。LDAPスキーマの変更後、新しいユーザーの追加、およびPIN値を持つように既存のユーザーの変更を行うことができるようになります。
OAMコンソールを使用して、PIN属性を使用するために拡張した外部LDAPサーバー用に新しいIdentityStoreを作成します。
OAMコンソールにログインし、ウィンドウの上部にある「構成」をクリックします。
「ユーザー・アイデンティティ・ストア」をクリックします。
「作成」ボタンをクリックして、OAM IDストアに新しいIdentityStoreを作成します。
詳細は、図49-3を参照してください。
図49-3 OAMコンソールによるIdentityStoreの作成
新しいアイデンティティ・ストア用の新しいOAM認証モジュールを追加します。
OAMコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「プラグイン」セクションの「作成」(+)ドロップダウン・メニューから、「カスタム認証モジュールの作成」を選択します。
「一般」タブで、名前(たとえば、PINBasedUserPlugin)を入力します。
「ステップ」タブで、次の値を入力します。
ステップ名: UI
プラグイン名: UserIdentificationPlugIn
プラグイン・パラメータ:
- KEY_LDAP_FILTER: (&(uid={KEY_USERNAME})(pin={cred}))
- KEY_IDENTITY_STORE_REF: OUDIdentityStore (このステップを実行するために、このデータ・ストアを最初に追加する必要があります。)
- KEY_SEARCH_BASE_URL: ou=users,dc=ngam,dc=oracle,dc=com
「ステップ編成」タブで、「最初のステップ」メニューからUIを選択します。
新しい認証スキームを追加します。
OAMコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「Access Manager」セクションの「作成」(+)ドロップダウン・メニューから、「認証スキームの作成」を選択します。
フォームに次のように入力します。
名前: PINBasedUserAuthNScheme
認証レベル: 3
チャレンジ・メソッド: FORM
認証モジュール: 前のステップで作成した認証モジュール(たとえば、PINBasedUserPlugin)を選択します。
新しい認証スキームを使用するために、認証ポリシーを変更します。
OAMコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「Access Manager」セクションで、「アプリケーション・ドメイン」をクリックします。
「IAM Suite」ドメインを見つけて、「OICTokenExchangePolicy」ポリシーを開きます。
「認証スキーム」ドロップダウン・メニューから、「PINBasedUserAuthNScheme」を選択します。
(モバイル) JWTOAMAuthenticationProviderを構成します。
OAMコンソールで、ウィンドウの上部にある「モバイル・セキュリティ」をクリックします。
「Mobile and Socialサービス」をクリックします。
「MobileJWTOAMAuthentication」サービス・プロバイダを編集のために開きます。
「アイデンティティ・ディレクトリ・サービス名」ドロップダウン・メニューから、ステップ2で作成したIdentityStoreを指すディレクトリ・サービスを選択します。
デスクトップ(非モバイル)・サービスが必要な場合、ステップaおよびbを繰り返して、JWTOAMAuthenticationプロバイダを構成します。
アプリケーション・プロファイルを作成します。
OAMコンソールで、ウィンドウの上部にある「モバイル・セキュリティ」をクリックします。
「Mobile and Socialサービス」をクリックします。
「アプリケーション・プロファイル」セクションで、「作成」ボタンをクリックして、新しいアプリケーション・プロファイル(mobileapp1など)を作成します。
MobileServiceDomainを更新します。
OAMコンソールで、ウィンドウの上部にある「モバイル・セキュリティ」をクリックします。
「Mobile and Socialサービス」をクリックします。
「サービス・ドメイン」セクションで、「MobileServiceDomain」ドメインを見つけて編集のために開きます。
「アプリケーション・プロファイル」セクション(サブタブ)で、前のステップで作成したアプリケーション・プロファイルを追加します(mobileapp1)。
「サービス・プロファイル」サブタブをクリックしてこれを開き、「認証サービス」をMobileJWTOAMAuthenticationに変更します。
認可サービス・プロバイダを使用すると、接続されているアプリケーションのかわりにバックエンド・アイデンティティ・サービスが認可を決定できます。
次の各トピックでは、認可サービス・プロバイダについて説明します。
認可サービス・プロバイダを編集または削除できます。
パネルでサービス・プロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。
ユーザー・プロファイル・サービス・プロバイダを使用すると、アプリケーションでディレクトリ・サーバーを問合せおよび更新できます。
次に示すように、LDAP準拠の多数のディレクトリ・サーバーがサポートされています。
Microsoft Active Directory
Novell eDirectory
Oracle Directory Server Enterprise Edition
Oracle Internet Directory
Oracle Unified Directory
Oracle Virtual Directory (Oracle Internet Directoryテンプレートを使用)
OpenLDAP
IBM Tivoli Directory Server (OpenLDAPテンプレートを使用)
WebLogic Server Embedded LDAP
Mobile and Socialには、組織で使用可能な、または独自に作成可能な事前構成済ユーザー・プロファイル・サービス・プロバイダが含まれています。ユーザー・プロファイル・サービス・プロバイダを作成するには、まず、アイデンティティ・ディレクトリ・サービス・プロファイルを作成する必要があります。アイデンティティ・ディレクトリ・サービス(IDS)は、Access Managerが複数のアイデンティティ・データ・ストアにアクセスするために使用する柔軟なサービスです。アイデンティティ・ディレクトリ・サービスの詳細は、「アイデンティティ・ディレクトリ・サービスのユーザー・アイデンティティ・ストアの管理」を参照してください。
次の各項では、ユーザー・プロファイル・サービス・プロバイダについて詳細に説明します。
ユーザー・プロファイル・サービス・プロバイダを編集または削除できます。
パネルでサービス・プロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。
自分または他の管理者が作成しておいたユーザー・プロファイル・サービス・プロバイダを編集する際に、アイデンティティ・ディレクトリ・サービス接続についてユーザー・プロファイル・サービス・プロバイダのその他の構成プロパティが表示されます。
ユーザー・プロファイル・サービス・プロバイダのその他の構成プロパティは次のとおりです。
名前: このユーザー・プロファイル・サービス・プロバイダの名前。
説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。
属性
ユーザー・プロファイル・サービス・プロバイダの属性と値を追加または削除します。
詳細は、表49-8を参照。
ノート:
通常、LDAP属性の名前には大文字と小文字の区別はありませんが、Oracle Identity Governance Framework (IGF)と通信する場合、LDAP属性の名前は大文字と小文字が区別されます。
表49-9 ユーザー・プロファイル・サービス・プロバイダのデフォルト属性の名前と値
| 名前 | デフォルト値 | ノート |
|---|---|---|
|
false |
サポートされる値は、accessControl機能を有効化する場合の |
|
|
accessControlを有効化している場合は、ユーザーが存在するかどうかを確認するためにadminGroupの識別名(DN)を指定します。 |
|
|
サポートされている値は、ユーザーがaccessControl機能について彼または彼女のプロファイルを編集できるかどうかに応じて |
|
true |
サポートされる値は、proxyAuth機能を有効化する場合の この属性は、Mobile and Socialの新規インストールには含まれていません。管理者はこのプロパティを追加できます。 |
アイデンティティ・ディレクトリ・サービス
名前: ユーザー・プロファイル・サービス・プロバイダを1つ以上のディレクトリ・サーバーに接続するアイデンティティ・ディレクトリ・サービス・プロファイル。アイデンティティ・ディレクトリ・サービスの詳細は、次を参照してください。
「アイデンティティ・ディレクトリ・サービスのユーザー・アイデンティティ・ストアの管理」を参照してください。
デフォルトのアイデンティティ・ディレクトリ・サービスのいずれか(userroleまたはidxuserroleのいずれか)を選択すると、構成値の表示や編集はできなくなります。
管理者が作成したアイデンティティ・ディレクトリ・サービス接続を選択すると、構成値を必要に応じて表示および編集できるようになります。
関係構成
アイデンティティ・ディレクトリ・サービスの対応する列にアクセスするために使用するURIセグメントを入力します。新しい関係を追加するには「追加」を、構成済の関係を削除するには「削除」を使用します。
アクセスURI - アイデンティティ・ディレクトリ・サービスの対応するデータ列にアクセスするために使用するURIセグメントを入力します。たとえば、memberOfがアクセスURIである場合は、
http://host:port/.../idX/memberOf
が、ID idXを持つエンティティの関連エンティティにアクセスするためのURIです。
アイデンティティ・ディレクトリ・サービスの関係 - 「アクセスURI」セグメントによってアクセスされるディレクトリ・サービス関係を選択します。アイデンティティ・ディレクトリ・サービスが、事前構成済のUserProfileアイデンティティ・プロバイダではない場合、「アイデンティティ・ディレクトリ・サービス」構成セクションの「関係」タブで関係を構成できます。(UserProfileサービス・プロバイダに対してはアイデンティティ・ディレクトリ・サービス関係を構成できません。)
エンティティURI属性 - Mobile and Socialサーバーから送信されるURIレスポンスで使用されるJSON属性名を入力します。たとえば、指定されているエンティティURI属性がperson-uriである場合、URIレスポンスは次のようになります。
{ {"person-uri":uriY1, ...}, {"person-uri":uriY2, ...}, ... }
ここで、 uriY1およびuriY2は、関連エンティティのそれぞれにアクセスするための直接URIです。
再帰型をリクエストするスコープ - 関係検索で、ネストされたレベルの属性を取得するには、スコープ属性値をスコープ問合せパラメータとともに使用します。再帰的に関連エンティティにアクセスするには、使用する値を入力します。Mobile and Socialのデフォルト構成では、toTopとallの2つのスコープ属性値が使用されます。「再帰型をリクエストするスコープ」の値が属性値allである場合、次のREST URIの例が使用されてリクエストが実行されます。
http://host:port/.../idX/reports?scope=all
この例では、URIによって、ID idXを持つエンティティに関連するエンティティが、それに続いて関連しているエンティティすべてとともに返されます。
