| Oracle Identity Managerベスト・プラクティス・ガイド リリース9.0.3 E05088-01 |
|
 戻る |
 次へ |
この章では、ユーザーがOracle Identity Managerにログインする際に、Oracle Access Managerを使用してユーザーの認証および認可を管理する方法について説明します。
この章では、次の内容について説明します。
|
注意: この章では、JBossをアプリケーション・サーバーとして統合で使用する方法について説明しますが、WebSphere、WebLogic、またはOracle Identity Managerでサポートされる他のJ2EEアプリケーション・サーバーにOracle Identity Managerがデプロイされる場合にも同じ構成手順が適用されます。 |
Oracle Access ManagerとOracle Identity Managerを統合すると、すべての顧客アプリケーションおよびプロセスに対するアイデンティティ管理にセキュアなWebベースのインフラストラクチャが提供されます。Oracle Identity Managerは、E-BusinessネットワークにデプロイされたOracle Identity Manager、エンタープライズ・リソースおよび他のドメイン間のアイデンティティおよびアクセス管理を統合します。Oracle Access Managerは、インターネット・アプリケーション間の顧客、パートナおよび従業員のアイデンティティを管理するため基盤となります。これらのユーザー・アイデンティティはセキュリティ・ポリシーと組み合され、Webでのやり取りを保護します。
この統合により、次の機能がOracle Identity Manager実装に追加されます。
Oracle Access Managerの認証、認可および監査: Oracle Identity Manager用のサービスです。
Oracle Access Managerシングル・サインオン: 単一ドメイン内または複数ドメイン間のOracle Identity Managerおよび他のOracle Access Managerによって保護されるリソースに対するものです。
Oracle Access Manager認証スキーム: 次のスキームにより、Oracle Identity Managerにシングル・サインオンが提供されます。
Basic: ユーザーは、Webサーバーによって表示されるウィンドウにユーザー名およびパスワードを入力する必要があります。
この方法は、SSLにリダイレクトできます。
フォーム: この方法は、Basicチャレンジ・メソッドに似ていますが、ユーザーはカスタムHTMLフォームに情報を入力します。
作成したフォームにユーザーが指定する必要がある情報を選択できます。
X.509証明書: SSLによるX.509デジタル証明
ユーザーのブラウザは証明書を指定する必要があります。
統合Windows認証（IWA）: ユーザーは、デスクトップにログインしてInternet Explorer（IE）ブラウザを開き、Oracle Access Managerによって保護されるWebリソースをリクエストしてシングル・サインオンを完了するとき、Oracle Access Manager認証とIWA間の相違に気づきません。
カスタム: Oracle Access Managerの認証プラグインAPIを使用して、認証の追加フォームを組み込むことができます。
セッション・タイムアウト: Oracle Access Managerを使用すると、ユーザー・セッションが有効である時間を設定できます。
Oracle Access Managerアイデンティティ・システムを使用する機能: このシステムには、ユーザー・プロファイルを登録および更新するためのユーザー・セルフサービス、Portal Inserts、委任管理、ワークフローなどのアイデンティティ管理機能があります。アイデンティティ・システムのデータは、カスタム・データ・テンプレートおよびワークフローを使用してバックエンド・アプリケーションに送信できます。
Oracle Identity Managerには2つの認証メカニズムがあります。
デフォルト・モード: Oracle Identity Managerは、資格証明の検証およびセッションの維持を管理します。
シングル・サインオン・モード: Oracle Identity Managerは、渡されるHTTPヘッダー変数を探します。
ヘッダー変数には、Oracle Identity ManagerユーザーのユーザーIDが入力されている必要があります。
Oracle Identity ManagerでのOracle Access Managerシングル・サインオンにより、次のことが実現します。
J2EEアプリケーション・サーバーの手前にHTTPサーバーをデプロイすること
HTTPサーバーをリバース・プロキシとしてデプロイすること
WebGateをHTTPサーバーにデプロイすること
Oracle Access Managerで使用されるLDAPディレクトリに格納される属性値をヘッダー変数に移入すること
シングル・サインオン・モードの認証を使用するように、Oracle Identity Managerを構成すること
図6-1に、Oracle Identity ManagerとOracle Access Manager間のシングル・サインオンのアーキテクチャを示します。
ユーザーがWebブラウザから管理およびユーザー・コンソールにアクセスします。WebGateがユーザーのHTTPリクエストを捕捉し、obSSOCookieの有無をチェックします。Cookieが存在しないまたは期限が切れている場合、ユーザーは資格証明をチャレンジされます。Oracle Access Managerが資格証明を検証し、ユーザーが認証されると、WebGateはリクエストされたリソースにユーザーをリダイレクトしてOracle Identity Managerにリクエストされたヘッダー変数を渡します。Oracle Identity Managerは、認証のかわりにHTTPヘッダー変数を読み取るように構成されており、HTTPヘッダーを読み取って変数に格納された値をログイン済ユーザーとして使用します。
プロセスの概要: Oracle Identity Managerでのシングル・サインオン
ユーザーが管理およびユーザー・コンソールにアクセスしようとします。
HTTPサーバーにデプロイされたWebGateがリクエストを捕捉します。
WebGateは、アクセス・サーバーをチェックして、リソース（Oracle Identity ManagerのURL）が保護されているかどうかを判断します。
アクセス・システムのセキュリティ・ポリシーには、認証スキーム、認可ルールおよび認証および認可の成功または失敗に基づいて許可された操作が指定されています。
有効なセッションが存在せず、リソースが保護されている場合、WebGateはユーザーに資格証明を求めます。
資格証明が検証されると、Oracle Access Managerはリソースのセキュリティ・ポリシーに定義されたアクションを実行し、Oracle Identity ManagerユーザーIDにマップされたHTTPヘッダー変数を設定します。
有効なセッションCookieが存在し、ユーザーがリソースへのアクセスを許可されると、WebGateはリクエストされたOracle Identity Managerリソースにユーザーをリダイレクトします。
管理およびユーザー・コンソールは、HTTPヘッダー変数を読み取り、その値をログイン済ユーザーとして設定します。
管理およびユーザー・コンソールは、アプリケーション・ページを生成し、Oracle Identity Managerで実行されるその後の認証チェックを保留します。
次のタスクを完了して統合のための環境を準備します。
タスクの概要: 統合のための環境の準備
サポートされるディレクトリ・サーバーをベンダーの指示に従ってインストールします。
ディレクトリ・サーバーをLDAPリポジトリとして使用して、Oracle Access Managerをインストールおよび構成します。
Oracle Identity Manager J2EEアプリケーション・サーバーがHTTPサーバーによってプロキシされていることを確認します。
ベンダーの指示に従って、Cookieを許可するようにWebブラウザを構成します。
Oracle Identity Manager用にOracle Access Managerを設定します。
詳細は、「Oracle Identity Manager用のOracle Access Managerシングル・サインオンの設定」を参照してください。
次の手順では、HTTPサーバーでのWebGateの設定およびOracle Identity Managerでのシングル・サインオンのためのOracle Access Managerの構成について説明します。
フォームベースの認証は、ASCII文字またはASCII以外の文字を使用するログインに対して構成できます。ブラウザの制限により、Basic認証スキームはASCIIログイン資格証明のみを受け入れます。
|
関連資料: Oracle Access Managerでの認証および認可の構成方法の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
HTTPサーバーでWebGateを設定する手順
サポートされるLDAPサーバーを使用して、サポートされるプラットフォームにOracle Access Managerをインストールおよび構成します。
詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
WebGateをOracle Identity Manager HTTPサーバーにインストールします。
WebGateは、HTTPサービスをサポートするアプリケーション・サーバー（BEA Weblogicなど）に対してインストールしないでください。アプリケーション・サーバーがJBoss、IBM WebSphereまたはBEA Weblogicの場合は、Apache、iPlanet、Oracle HTTP ServerなどのHTTPサーバーをインストールします。
HTTPサーバーを構成して、ユーザー・リクエストをJ2EEアプリケーション・サーバーに、Oracle Identity Managerからのレスポンスをユーザーに転送するようにします。
Oracle Access Managerでシングル・サインオンを構成する手順
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクをクリックし、「ポリシー・ドメインの作成」をクリックします。
ポリシー・ドメインと、Oracle Identity ManagerのURLへのアクセスを制限するポリシーを作成します。
アクセス・システム・コンソールで、Oracle Identity Managerのホスト識別子を定義します。
「ポリシー・マネージャ」リンクをクリックし、Oracle Identity Managerポリシー・ドメインのリンクをクリックして「リソース」タブを選択し、Oracle Access Managerで保護するリソースを定義します。
「認可ルール」タブを選択し、Oracle Identity ManagerのURLにアクセスできる認証済ユーザーを決定する認可ルールを定義します。
「デフォルト・ルール」タブを選択します。
「認証ルール」サブタブが選択されています。
Basic Over LDAPなどの認証ルールを定義します。
「アクション」サブタブを選択し、認可に成功した場合にカスタムHTTPヘッダー変数を設定する認可アクションを定義します。
ヘッダー変数には、Oracle Identity ManagerユーザーIDにマップされている値を入力する必要があります。
「ポリシー」タブを選択して「追加」をクリックし、Oracle Identity Managerポリシー・ドメインにアクセス・ポリシーを定義し、そのポリシーにOracle Identity ManagerのURLリソースを追加します。
次の手順では、Oracle Access Managerと統合するためにOracle Identity Managerを設定する方法について説明します。
Oracle Identity Managerに対してシングル・サインオンを構成する手順
アプリケーション・サーバーを正常に停止します。
プレーン・テキスト・エディタを起動し、次のファイルを開きます。
<XL_HOME>\xellerate\config\xlconfig.xml
次のシングル・サインオン構成（シングル・サインオンなしのデフォルト設定）を探します。
<web-client> <Authentication>Default</Authentication> <AuthHeader>REMOTE_USER</AuthHeader> </web-client>
次のようにして、シングル・サインオン構成を編集します。
<SSO_HEADER_NAME>をシングル・サインオン・システムで構成された適切なヘッダーで置き換えます。
<web-client>
<Authentication>SSO</Authentication>
<AuthHeader><SSO_HEADER_NAME></AuthHeader>
</web-client>
ASCII以外の文字のログインによるシングル・サインオンを有効化するには、ASCII以外のヘッダー値をデコードするデコード・クラス名を含める必要があります。次のようにデコード・クラス名を追加してシングル・サインオン構成を編集します。
<web-client>
<Authentication>SSO</Authentication>
<AuthHeader><SSO_HEADER_NAME></AuthHeader>
<AuthHeaderDecoder>com.thortech.xl.security.auth.CoreIDSSOAuthHeaderDecoder</AuthHeaderDecoder>
</web-client>
<SSO_HEADER_NAME>をシングル・サインオン・システムで構成された適切なヘッダーで置き換えます。
アプリケーション・サーバーおよびWebサーバー構成を変更してシングル・サインオンを有効化します。
詳細は、アプリケーション・サーバーおよびWebサーバーのベンダーのドキュメントを参照してください。
アプリケーション・サーバーを再起動します。
管理およびユーザー・コンソールは、JBoss、BEA Weblogic、IBM WebSphereなどのJ2EEアプリケーション・サーバーで稼働します。アクセス・ゲートは、これらのアプリケーション・サーバーに直接インストールできません。Apache、Oracle HTTP Server、iPlanetなどのWebサーバーは、これらのアプリケーション・サーバーの手前にデプロイできます。アクセス・ゲートをWebサーバーにデプロイして、リクエストをOracle Identity Managerアプリケーションにルーティングし、レスポンスをユーザーに転送するようにWebサーバーを構成することができます。
JBossなどのアプリケーション・サーバーの場合、mod_jkプラグインまたはJBossプラグインという追加プラグインをWebサーバーにデプロイする必要があります。mod_jkプラグインは、Apache Tomcat WebサイトのTomcatコネクタ・セクションから取得できます。公開時点でのURLは次のとおりです。
http://tomcat.apache.org/download-connectors.cgi
Apache HTTPサーバーをJBoss用プロキシとして構成する手順
Oracle Access ManagerでサポートされるApache HTTPサーバーのバージョンをダウンロードおよびインストールします。
最新の安定したバージョンのJakarta（Tomcat）mod_jkプラグインを次のURLからダウンロードします。
http://tomcat.apache.org/download-connectors.cgi
ファイルを抽出して、名前をmod_jk.soに変更します。
このファイルを次のディレクトリにコピーします。
Apache_install_dir\modules
次のテキスト・ファイルをApache_install_dir\confディレクトリに作成します。
mod-jk.conf
workers.properties
uriworkermap.properties
uriworkermap.propertiesおよびworkers.propertiesの名前を変更しないでください。名前を変更すると、構成が機能しなくなることがあります。これらのファイルの場所は、worker_fileとworker_mount_fileの2つのレジストリ・キーの下に定義されます。これらのファイルは、HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\version_numberにあります。
次の構成をmod-jk.confファイルにコピーします。
# Load mod_jk module
# Specify the file name of the mod_jk lib
LoadModule jk_module modules/mod_jk.so
# Where to find workers.properties
JkWorkersFile conf/workers.properties
# Where to put jk logs
JkLogFile logs/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel info
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
# JkOptions indicates to send SSK KEY SIZE
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
# JkRequestLogFormat
JkRequestLogFormat "%w %V %T"
# Mount your applications
JkMount /application/* loadbalancer
# You can use external file for mount points.
# It will be checkded for updates each 60 seconds.
# The format of the file is: /url=worker
# /examples/*=loadbalancer
JkMountFile conf/uriworkermap.properties
# Add shared memory.
# This directive is present with 1.2.10 and
# later versions of mod_jk, and is needed for
# for load balancing to work properly
JkShmFile logs/jk.shm
# Add jkstatus for managing runtime data
<Location /jkstatus/>
JkMount status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
次の構成をworkers.propertiesファイルにコピーします。
# Define the list of workers that will be used # for mapping requests worker.list=loadbalancer # Define node1 worker.node1.port=8009 worker.node1.host=<Put your Identity Manager App Server FQDN name here> worker.node1.type=ajp13 worker.node1.lbfactor=1 worker.node1.local_worker=1 (1) worker.node1.cachesize=10 #Load-balancing behaviour worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1 worker.loadbalancer.sticky_session=1 worker.loadbalancer.local_worker_only=1
次の構成をuriworkermap.propertiesファイルにコピーします。
マッピングは、workers.propertiesファイルに定義されたworker.listエントリに応じて構成します。次の例に示されてはいますが、必ずしもloadbalancerではありません。
# Simple worker configuration file # Mount the servlet context to the ajp13 worker /jmx-console=loadbalancer /jmx-console/*=loadbalancer /web-console=loadbalancer /web-console/*=loadbalancer /xlWebApp=loadbalancer /xlWebApp/*=loadbalancer /Nexaweb=loadbalancer /Nexaweb/*=loadbalancer
