| Oracle® Fusion Middleware Oracle Adaptive Access Manager開発者ガイド 11gリリース2(11.1.2) B71697-01 |
|
 前 |
 次 |
Juniper Networks Access SSL VPNとOracle Adaptive Access Managerとの統合により、企業は、厳密なマルチファクタ認証と高度なリアルタイム不正行為防止機能を備えたリモート・アクセス制御ソリューションを実装して、企業のアプリケーションにセキュアにアクセスすることができます。
この章では、Juniper Secure Access(SA)の統合に対応するOAAMの構成方法について説明します。内容は次のとおりです。
ネットワーク・セキュリティ信頼ゾーンで保護されたエンタープライズ・リソースにアクセスするには、すべてのリモート・アクセスのセキュアなゲートウェイであるSSL VPNにアクセスする必要があります。
Juniper SAは、リモートおよびモバイルの従業員、顧客、パートナがいつでも、どこでも企業のリソースとアプリケーションにセキュアにアクセスできるための一連のSSL VPNアプライアンスです。
Oracle Adaptive Access Manager 11gは、強力かつデプロイの容易なリスク・ベース認証、フィッシング対策、およびマルウェア対策の各種機能を駆使して最重要のオンライン・ビジネス・アプリケーションを保護します。
SAML(Security Assertion Markup Language)は、セキュリティ・ドメイン間で認証および権限データを交換するためのXMLベースのオープン標準です。
この統合では、リソースへのアクセスを制御するJuniper SAは認証時にOAAMを使用して、ユーザー認証中のリスクを最小限に抑え、セキュリティを強化します。ソリューションの組合せによって、認証時の不正行為とリスクの検出が可能になり、それに応じて、Challenge、Block、その他のアクションなどのOAAM機能を使用してユーザーを強力に認証します。Juniper SAは、Security Assertion Markup Language(SAML)を使用してユーザー認証と権限データを交換できるように構成されます。
図18-1に、Juniper SAとOAAM間の高レベルのフローを示します。認証フローの詳細は、第18.2.1項「認証フロー」を参照してください。
2つの統合ユースケースは、Juniper SSL VPNで認証およびパスワードを忘れた場合のフローに対応するためのOAAMの統合に重点を置いています。
OAAMは、認証時の不正行為とリスクの検出、およびChallenge、Blockやその他のアクションなど、厳密な認証機能の提供に使用します。ユーザーが認証されない場合に認証順序が遂行できるようにユーザーをOAAMにリダイレクトすることによって、認証が達成されます。
OAAMを使用して、パスワード・リセット認証を実現します。パスワードを忘れた場合のフローでは、ユーザーは、チャレンジ質問に正しく回答した後で自分のパスワードをリセットできます。
次のプロセスでは、OAAMで認証フローが実現される場合に、Juniper SAによって保護されているWebアプリケーションまたはURLにユーザーがログインする方法を説明しています。
ユーザーは、Juniper SAにより保護されているWebアプリケーションまたはURLにアクセスしようと試みます。Juniper SAはSAMLを使用するように構成されています。
Juniper SAは、ユーザーが認証されているかどうかを検出します。認証されている場合は、ユーザーはWebアプリケーションに進むことができます。
認証されていない場合、ユーザーはOAAMサーバーにリダイレクトされます。OAAMサーバーはOAAMログイン・ページを表示し、ユーザーIDを入力するようにユーザーに促します。
資格証明コレクションの一部としてユーザーIDが入力されると、OAAMは認証前チェックポイントを評価して、ユーザーをブロックする必要があるかどうかを検証します。次に、OAAMはユーザーが認証パッドを登録しているかどうかを確認します。登録済の場合は、登録された認証パッドが表示され、登録済でない場合は、汎用テキスト・パッドが表示されます。
OAAMサーバーは認証パッドのあるパスワード・ページを表示し、パスワードを入力するようユーザーに促します。
パスワードが入力されると、OAAMはOracle Platform Security Services(OPSS)を使用して、そのパスワードをユーザー・ストアと照合します(ユーザー・ストアにはLDAP、Active Directory、またはその他の認証プロバイダが使用できます)。OPSSは、Javaアプリケーションに対応する標準ベースの、ポータブルな、統合されたエンタープライズ級のセキュリティ・プラットフォームです。
OAAMでは、デバイス識別プロセスを実行してデバイスの識別も行われます。
資格証明が正しくない場合は、エラー・ページが表示されて、資格証明を再入力するようユーザーに要求します。
資格証明が正しい場合は、認証後チェックポイントが評価されます。チェックポイントの結果に基づき、OAAMはユーザーにチャレンジするか、ユーザーをブロックします。
認証後の結果がALLOWの場合は、ユーザーを登録する必要があるかどうかが判別されます。登録のタイプに基づいて、登録ページが順次に表示されます。
登録とは、アカウントを新規に開く場合など、ユーザーに情報を求めるイベントからなる登録プロセスのことです。登録プロセスでは、ユーザーは質問、イメージ、フレーズ、およびデプロイメントでOTPがサポートされている場合にはOTP(電子メールや電話など)を登録するように求められます。
認証後の結果がCHALLENGEであり、ユーザーが1つ以上のチャレンジ・メカニズムにすでに登録されている場合、OAAMはユーザーにチャレンジします。チャレンジに回答できる場合、ユーザーは次のステップに送られます。
認証が成功した後、OAAMはユーザー・ストアからユーザー属性を取得し、そのユーザー属性に基づいてSAMLアサーションを作成し、それに署名して、そのアサーションをJuniper SAのリダイレクションURLにポストします。Juniper SAはアサーションを使用して検証し、ユーザーが要求したターゲット・ページまたはWebアプリケーションにユーザーをログインします。
認証後チェックポイントの結果がBLOCKの場合、ユーザーはブロックされ、アクセスを試みたWebアプリケーションにアクセスできなくなります。
次のプロセスでは、ユーザーがすべてのチャレンジ質問に正しく回答した後でパスワードをリセットする方法について説明します。
このユースケースでは、パスワードを忘れた場合のフローに対応するOAAMとJuniper SAとの統合に重点を置いています。
ユーザーは、Juniper SAにより保護されているWebアプリケーションまたはURLにアクセスしようと試みます。Juniper SAはSAMLを使用するように構成されています。
Juniper SAは、ユーザーが認証されているかどうかを検出します。認証されている場合、ユーザーはWebアプリケーションに進むことができます。
認証されていない場合、ユーザーはOAAMサーバーにリダイレクトされます。
OAAMサーバーはOAAMログイン・ページを表示し、ユーザーIDを入力するようにユーザーに促します。
ユーザーIDが入力されると、OAAMは認証前チェックポイントを評価して、ユーザーをブロックする必要があるかどうかを確認します。次に、OAAMはユーザーが認証パッドを登録しているかどうかを確認します。ブロックの必要が確認された場合は、登録された認証パッドが表示され、確認されない場合は、汎用テキスト・パッドが表示されます。
OAAMサーバーは認証パッドのあるパスワード・ページを表示し、パスワードを入力するようユーザーに促します。
ユーザーは、「パスワード忘れ」リンクをクリックします。
OAAMサーバーは、「パスワード忘れ」チェックポイントを実行して、パスワードを忘れた場合のフローを開始します。
結果に基づいて、OAAMサーバーはユーザーにチャレンジするか、ユーザーをブロックします。
チャレンジに正しく回答できた場合、ユーザーは新規パスワードを入力するよう促されます。
次に、OAAMはユーザー・ストアをコールしてパスワードを更新します。
さらに、ユーザー・ストアからユーザー属性を取得し、SAMLアサーションを作成し、それに署名して、そのアサーションをJuniper SAのリダイレクションURLにポストします。
Oracle Adaptive Access ManagerとJuniper SSLを統合してOracle Adaptive Access Managerの認証フローとパスワードを忘れた場合のフローを使用するには、この項の手順を参照してください。
表18-1に、Oracle Adaptive Access ManagerとJuniper SAとの統合を構成する高レベルのタスクの概要を示します。
表18-1 統合ステップ
| 番号 | タスク | 情報 |
|---|---|---|
|
1 |
前提条件をレビューします。 |
詳細は、前提条件を参照してください。 |
|
2 |
認証プロバイダを構成します。 |
詳細は、「認証プロバイダの構成」を参照してください。 |
|
3 |
サーバー・プロパティをインポートします。 |
詳細は、「OAAM管理コンソールを使用したSAML構成関連サーバー・プロパティのインポート」を参照してください。 |
|
4 |
証明書またはトラストを設定します。 |
詳細は、「アサーションの署名に対する証明書の設定」を参照してください。 |
|
5 |
Oracle Platform Security Servicesを認証用に構成します。 |
詳細は、「Oracle Platform Security Services (OPSS)の統合用の構成」を参照してください。 |
|
6 |
統合プロパティを変更します。 |
詳細は、「OAAM管理コンソールを使用した統合プロパティの変更」を参照してください。 |
|
7 |
Juniper SSLの構成 |
詳細は、「Juniper SSLの構成」を参照してください。 |
この章のタスクを開始する前に、次の点に留意してください。
Juniper SAとOAAMサーバーのノードでシステム・クロックを同期化しておく必要があります。Juniper SAのシステム・クロックとOAAMサーバーのクロック間で時間を同期化する必要があります。Juniper SAシステム・クロックの時間がOAAMサーバーのクロックよりも進まないようにする必要があります。
Oracle WebLogicは必須です。WebLogicのバージョンについては、現在の動作保証マトリクスを確認してください。現在、この統合はOracle WebLogicのみのOAAM 11gでテスト済です。
この統合は、SAML 1.1バージョンに実装されています。
WebLogicでは、認証プロバイダを使用してユーザーまたはシステム・プロセスのアイデンティティを指定します。認証プロバイダは、そのアイデンティティ情報を記憶したり、システムの各種コンポーネントに転送したり、必要に応じて(サブジェクトを通して)使用可能にすることもあります。
WebLogicの組込みLDAP、AD(Active Directory)、その他の認証プロバイダをアイデンティティ・ストアとして使用できます。
認証プロバイダを構成するには、次の手順を実行します。
Oracle WebLogic管理コンソールにWebLogic管理者としてログインします。たとえば、次のようになります。
http://hostname:7001/console
デフォルトのポートは7001です。
左ペインの「ドメイン構造」セクションから「セキュリティ・レルム」を選択します。
「セキュリティ・レルム」ページの「サマリー」で、構成中のレルムの名前をクリックします。たとえば、「myrealm」をクリックします。
「myrealmの設定」ページが表示されます。
「プロバイダ」タブをクリックして、「認証」サブタブを表示します。
「DefaultAuthenticator」を選択して、組込みLDAPを使用します。その他のアイデンティティ・ストアに関しては、適切なプロバイダを選択してください。たとえば、Active Directoryには「AD Authenticator」を選択します。
「DefaultAuthenticator」が最初の位置に表示されるように、プロバイダを並べ替えます。
「並替え」をクリックし、「認証プロバイダの並替え」ページを表示します。
「DefaultAuthenticator」を選択し、矢印ボタンを使用してそれをリストの最初に移動させます。
「OK」をクリックして、変更を保存します。
組込みLDAPを使用している場合は、次の手順を実行する必要があります。
Oracle WebLogic管理コンソールで、左ペインの「ドメイン構造」の「base_domain」をクリックします。
「セキュリティ」タブをクリックします。
「組込みLDAP」タブをクリックします。
「マスター優先」オプションを選択します。
「保存」をクリックします。
WebLogic管理サーバーおよび管理対象サーバーを再起動します。
SAML構成関連プロパティをインポートして、OAAMデータベースに追加されるようにします。
SAML構成関連プロパティをインポートするには、次の手順を実行します。
Oracle管理コンソールにセキュリティ管理者としてログインします。たとえば、次のようになります。
http://hostname:port/oaam_admin
ナビゲーション・ペインで、「環境」ノードの下の「プロパティ」をクリックします。
「プロパティ」ページで「プロパティのインポート」をクリックして、統合用にサーバー・プロパティをインポートします。
IDM_ORACLE_HOME/oaam/initディレクトリで「saml_properties.zip」を参照し、「オープン」をクリックし、「インポート」をクリックします。
インポートが完了すると、プロパティが正常にインポートされたことが表示されます。
「完了」をクリックして、インポートを完了します。
これによって、統合に必要なプロパティがインポートされます。第18.3.7項「OAAM管理コンソールを使用した統合プロパティの変更」で、環境に応じてこれらのプロパティを変更します。
認証局(CA)は、サード・パーティやその他のエンティティ(ユーザー、データベース、管理者、クライアント、サーバーなど)のアイデンティティを証明する信頼できる第三者機関です。認証局は、当事者の識別情報を検証し、秘密鍵で署名された証明書を付与します。
Juniper SAとOAAM間で信頼の証明書を設定するには、以降の各項に説明する手順を実行します。
最初に、証明書の秘密鍵を作成します。この秘密鍵を作成するには、次の手順を実行します。
作業ディレクトリをセキュリティ・プロパティのディレクトリMW_HOME/jdk160_18/jre/lib/securityに変更します。
keytoolというキーおよび証明書管理ユーティリティを使用して、秘密鍵を作成します。cacertsをキーストアとして使用して、次のコマンドを入力します。
keytool -genkey -keyalg rsa -validity 1825 -keysize 2048 -alias OAAMCert -keystore cacerts -storepass changeit
証明書の詳細を入力します。
出力の例は次のとおりです。
What is your first and last name? [Unknown]: ag-oracle-oaam What is the name of your organizational unit? [Unknown]: Juniper What is the name of your organization? [Unknown]: Juniper What is the name of your City or Locality? [Unknown]: Sunnyvale What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=ag-oracle-oaam, OU=Juniper, O=Juniper, L=Sunnyvale, ST=CA, C=US correct? [no]: yes
|
注意: 通常、証明書の |
プロンプトが表示されたら、キーストアのパスワードを入力します。
Enter key password for <OAAMCert>
(RETURN if same as keystore password):
Re-enter new password:
このパスワードは、統合用にあとで必要になるので覚えておいてください。
秘密鍵と自己署名証明書を作成した後で、keytoolコマンドを使用して証明書署名リクエスト(CSR)を生成します。
作業ディレクトリをMW_HOME/jdk160_18/jre/lib/securityに変更します。
次のコマンドを実行して、証明書リクエストを作成します。
keytool -certreq -alias OAAMCert -file server.csr -keystore cacerts -storepass changeit
この例では、server.csrというファイルに証明書リクエストを作成しました。
証明書署名リクエスト(CSR)を認証局に送信して、デジタル証明書を取得します。認証局から証明書が発行されます。発行された証明書と、リクエストを署名したルートCA証明書を受信する必要が生じる場合もあります。
テストとして、独自の認証局として行動して証明書に署名することができます。本番シナリオでは、認証局からの証明書を使用する必要があります。
本番シナリオでは、第18.3.5.4項「独自の認証局として行動」をスキップして、第18.3.5.5項「自分のキーストアに証明書をインポート」に進み、外部認証局から証明書をインポートします。
テストの目的で、独自の認証局として行動して証明書に自己署名することができます。次の手順を1つずつ実行して、証明書の自己署名を設定します。この設定を行うには、後続の例に従って実行します。
証明書の管理、または証明書リクエストの作成に使用するマシンに、パッケージOpenSSLをインストールする必要があります。OpenSSLは、SSL(Secure Sockets Layer)プロトコルのオープン・ソースの実装です。OpenSSLは基本的な暗号機能を実装し、ユーティリティ関数を提供します。
必要なディレクトリを作成するには、次の手順を実行します。
すべての証明書ファイルが保持されるディレクトリを作成します。デフォルトのディレクトリは/etc/pki/tls/です。ルートとして次のコマンドを発行し、専用のディレクトリを作成します。
# mkdir -m 0755 /etc/pki_jungle
次のコマンドを発行して、認証局のディレクトリを作成します。
# mkdir -m 0755 \ /etc/pki_jungle/myCA \ /etc/pki_jungle/myCA/private \ /etc/pki_jungle/myCA/certs \ /etc/pki_jungle/myCA/newcerts \ /etc/pki_jungle/myCA/crl
説明:
myCAは、自分の認証局のディレクトリです。
myCA/privateは、秘密鍵が配置されるディレクトリです。すべての秘密鍵に制限的な権限を設定して、ルートのみ、またはサーバー実行の権限を持つユーザーのみが秘密鍵を読み込めるようにします。認証局の秘密鍵が盗まれると、最悪の結果が生じる可能性があります。
myCA/certsディレクトリは、サーバー証明書が配置される場所です。
myCA/newcertsディレクトリは、OpenSSLがPEM(暗号化されていない)フォーマットおよびcert_serial_number.pemフォーム(07.pemなど)で作成された証明書を入れる場所です。OpenSSLにはこのディレクトリが必要なため、必ず作成してください。
myCA/crlは、証明書取消リストが配置される場所です。
デフォルトのOpenSSL構成ファイル(openssl.cnf)を/etc/pki/tlsから自分の認証局のディレクトリにコピーして、それにopenssl.my.cnfという名前を付けるには、ルートとして次のコマンドを発行します。
# cp /etc/pki/tls/openssl.cnf /etc/pki_jungle/myCA/openssl.my.cnf
このファイルはすべてのユーザーにとって読取り可能である必要がないため、次のコマンドを発行してその属性を変更できます。
# chmod 0600 /etc/pki_jungle/myCA/openssl.my.cnf
次のコマンドを発行して、OpenSSLのデータベースとして使用できるファイルを作成します。
# touch /etc/pki_jungle/myCA/index.txt
次のコマンドを発行して、次の証明書のシリアル番号を持つファイルを作成します。
# echo '01' > /etc/pki_jungle/myCA/serial
証明書をまだ作成していないため、それを「01」に設定します。
初期構成の完了後に、他の証明書リクエストや秘密鍵に署名するために自分の認証局の証明書として使用できる自己署名証明書を生成できるようになります。
自分の認証局のディレクトリに変更します。
ルートとしてOpenSSLコマンドを発行します。
# cd /etc/pki_jungle/myCA/
これはOpenSSLの構成ファイル(openssl.my.cnf)の保存場所であるため、この場所ですべてのOpenSSLコマンドを発行する必要があります。
次に、自分の認証局の証明書と秘密鍵を作成します。ルートとして次のコマンドを発行します。
# openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825
これによって、5年間有効なデフォルトのCA拡張を持つ自己署名証明書が作成されます。
自分の認証局の秘密鍵に対してパスフレーズの入力を促すプロンプトが表示されたら、厳密なパスフレーズを設定します。
プロンプトが表示されたら、証明書リクエストに組み込まれる情報を指定します。認証局に関する情報は、次に示す例に類似しています。
Country Name (2 letter code) [GB]:GR State or Province Name (full name) [Berkshire]:Greece Locality Name (eg, city) [Newbury]:Thessaloniki Organization Name (eg, company) [My Company Ltd]:My Network Organizational Unit Name (eg, section) []:My Certificate Authority Common Name (eg, your name or your server's hostname) []:server.example.com Email Address []:whatever@server.example.com
次の2つのファイルが作成されます。
certs/myca.crt: これは自分の認証局の証明書であり、パブリックに使用可能で、すべてのユーザーが読取り可能なファイルです。
private/myca.key: これは自分の認証局の秘密鍵です。これはパスフレーズで保護されていますが、ルートのみが読み取れるようにアクセスを制限する必要があります。
自分の認証局の秘密鍵はパスフレーズで保護されていますが、ルートのみが読み取れるようにアクセスを制限する必要があります。これを実行するには、次のコマンドを発行します。
# chmod 0400 /etc/pki_jungle/myCA/private/myca.key
証明書の管理にカスタム・ディレクトリを使用しているため、/etc/pki_jungle/myCA/openssl.my.cnfを変更する必要があります。
テキスト・エディタでルートとしてopenssl.my.cnfを開き、次のセクション(35行目あたり)を検索します。
_________________________________________________________
[ CA_default ]
dir = ../../CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several certificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
#crlnumber = $dir/crlnumber # the current crl number must be
# commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
カスタム・ディレクトリ、カスタム認証局キー(秘密鍵)、および証明書に適合するようにパス値を変更し、変更内容を保存します。
__________________________________________________________ [ CA_default ] dir = . # <--CHANGE THIS certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt #unique_subject = no new_certs_dir = $dir/newcerts certificate = $dir/certs/myca.crt # <--CHANGE THIS serial = $dir/serial #crlnumber = $dir/crlnumber crl = $dir/crl.pem private_key = $dir/private/myca.key # <--CHANGE THIS RANDFILE = $dir/private/.rand x509_extensions = usr_cert _____________________________________________________________
次に、証明書リクエストに署名し、サーバーの証明書を生成します。これを行うには、次の手順を実行します。
まず、次のコマンドを発行して、server.csrを自分の認証局のディレクトリにコピーします。
# cp server.csr /etc/pki_jungle/myCA/
次のコマンドを発行して、自分の認証局のディレクトリに変更します。
# cd /etc/pki_jungle/myCA/
さらに、次のコマンドを発行して、証明書リクエストに署名します。
# openssl ca -config openssl.my.cnf -policy policy_anything -out certs/server.crt -infiles server.csr
リクエストに署名するために、認証局の秘密鍵を指定します。openssl.my.cnfファイルでpolicy_anythingの意味を確認できます。要するに、Country、StateまたはCityに関するフィールドは、自分の認証局の証明書と一致している必要がありません。
これらの手順が完了すると、次の2つのファイルが新規に作成されます。
certs/server.crt.
これはサーバーの証明書であり、パブリックに使用可能にすることができます。
newcerts/01.pem
これは同じ証明書ですが、ファイル名として証明書のシリアル番号が使われています。これは必要ありません。
これで証明書リクエスト(server.csr)は不要になったため、これを削除します。
SSL VPNは、このサーバー証明書の公開鍵をインポートして、OAAMから送信されたメッセージを復号化する必要があります。
ルートCA証明書をインポートした後で、認証局により発行された証明書をインポートする必要があります。ルート証明書の名前はmyca.crtであり、発行された証明書の名前はserver.crtです。
証明書をキーストアにインポートするには、次の手順を実行します。
作業ディレクトリをMW_HOME/jdk160_18/jre/lib/securityに変更します。
次のkeytoolコマンドを使用して、ルート証明書をキーストアにインポートします。
keytool -importcert -alias rootCA -file myca.crt -keystore cacerts -storepass changeit
前述の構文の各要素は次のとおりです。
aliasは、ルートCA証明書の別名を表します。
rootCA -fileは、ルートCA証明書が含まれているファイルの名前を表します。
keystoreは、キーストアの名前を表します。
テキスト・エディタでserver.crtを開き、BEGIN CERTIFICATEタグとEND CERTIFICATEタグの間のコンテンツ以外のすべてを削除します。
次のkeytoolコマンドを使用して、発行された証明書をキーストアにインポートします。
keytool -importcert -alias OAAMCert -file server.crt -keystore cacerts -storepass changeit
前述の構文の各要素は次のとおりです。
aliasは証明書の別名を表します。これは、「証明書の秘密鍵の作成」で割り当てられた秘密鍵の別名と同じである必要があります。
server.crtは、証明書が含まれているファイルの名前を表します。
keystoreは、キーストアの名前を表します。
<OAAMCert>に対するキー・パスワードを入力します。
証明書の返信はキーストアにインストールされています。
|
注意: 別名がリクエスト作成時に使用したものと同じであることを確認します。 |
Oracle Platform Security Services(OPSS)では、企業の製品開発チーム、システム・インテグレータ(SI)および独立系ソフトウェア・ベンダー(ISV)に、Java Standard Edition(Java SE)およびJava Enterprise Edition(Java EE)のアプリケーション向けに標準ベースで移植可能な企業向け統合セキュリティ・フレームワークを提供します。OPSS抽象レイヤーが認証に使用されます。認証の構成はWebLogicで実行する必要があります。OPSSの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
OAAMがインストールされているマシン上で、WebLogic_Domain/config/fmwconfigに移動します。
jps-config.xmlをバックアップします。
JPS、config.xmlを開きます。
タグ</jpsContexts>を閉じる前に、次のJPSコンテキストを追加します。
<!-- This context is used for OAAM Juniper Integration --> <jpsContext name="idcontext"> <serviceInstanceRef ref="user.authentication.loginmodule"/> <serviceInstanceRef ref="idstore.ldap"/> <serviceInstanceRef ref="credstore"/> <serviceInstanceRef ref="keystore"/> <serviceInstanceRef ref="policystore.xml"/> <serviceInstanceRef ref="audit"/> </jpsContext>
ファイルを保存して終了します。
|
注意: ファイルを保存した後で、XMLエディタを使用してすべてのタグが正しいことを確認する必要が生じることがあります。インターネット・エクスプローラでこのファイルを開いて、タグが抜けていないか確認することもできます。変更が正しい場合は、インターネット・エクスプローラでファイルを正常に開くことができます。 |
これらの変更では再起動が必要なため、WebLogic管理サーバー、OAAM管理サーバー、OAAM管理対象サーバーを停止および起動してください。
統合の確立に必要なSAML構成プロパティを定義するには、次の手順を実行します。
OAAM管理コンソールにログインします。
「プロパティ」をダブルクリックして、プロパティ・ページを開きます。
「名前」フィールドに「oracle.saml*」と入力し、「検索」をクリックして統合プロパティを検索します。
「検索結果」で、変更するプロパティをクリックします。
「プロパティ」タブでプロパティの値を変更して、「保存」をクリックします。
統合の一環としてインポートされた、変更の必要のあるプロパティが表18-2「SAML統合プロパティ」に表示されます。
表18-2 SAML統合プロパティ
| プロパティ | 説明 |
|---|---|
|
oracle.saml.integration.version |
統合に使用されるSAMLバージョン 使用可能な値は デフォルト値は Juniper SAでもSAML2.0をサポートしています。 使用するSAMLのバージョンを決定する必要があります。 |
|
oracle.saml.target.default.url |
SAMLアサーションが成功したことをJuniper SAで検証された後にユーザーが移動するターゲットURL(ホームページ) 例: |
|
oracle.saml.keystore |
アサーションの署名に必要な証明書を格納するためのキーストアのフルパス。この例では、次のようになります。
|
|
oracle.saml.keystore.password |
キーストアのパスワード |
|
oracle.saml.keystore.certalias |
アサーションに使用する証明書の別名 |
|
oracle.saml.keystore.privatekeypassword |
秘密鍵のパスワード |
|
oracle.saml.redirect.post.url |
SAMLアサーションがポストされるURL 例: |
|
oracle.saml.set.attributes |
アサーションの一環として追加の属性をJuniper SAに送信する必要があるかどうかを指定します。 指定可能な値は デフォルト値は |
|
oracle.saml.user.attributes |
アサーションの一環として追加する必要のある属性のリスト このプロパティは、 |
|
oracle.saml.attribute.namespace |
アサーションに使用するネームスペースの名前。デフォルト値は SAML1.1の場合のみ。 |
|
oracle.saml.nameidformat |
SAMLアサーションで使用する デフォルト値は |
|
oracle.saml.nameidattribute |
SAMLアサーションでユーザーを識別する デフォルト値は
|
|
oracle.saml.issuer.url |
SAMLの発行者のURL これは、OAAM認証サーバーが実行しているマシンです。 例: |
この統合用にJuniperを構成するには、次の処理を行う必要があります。
Juniper SA構成の詳細は、次のサイトで入手可能な『Juniper Networks Secure Access管理ガイド』を参照してください。
http://www.juniper.net/techpubs
Juniper SAに認証サーバーを作成する必要があります。これを行うには、次の手順を実行します。
Juniper SSL VPN管理コンソールにログインします。
Juniper管理コンソールの左ペインで「Authentication」メニューを開き、「Auth.」をクリックします。
「New」ドロップダウン・リストから「SAML Server」を選択し、「New Server」をクリックします。
次のダイアログが表示されます。
表18-3の値を使用して、認証サーバーを定義します。
表18-3 認証サーバーの作成
| パラメータ | 詳細 | 値 |
|---|---|---|
|
Server Name |
SAMLServerの名前 |
OAAM SAML 1.1 表示されている値と同じものを入力します。 |
|
SAML Version |
認証サーバーのSAMLバージョン |
1.1 表示されている値と同じものを入力します。 |
|
Source Site Inter-Site Transfer Service URL |
OAAMサーバーのエントリURL。これは、認証のためにユーザーがリダイレクトされる場所です。 |
例: @ 環境に応じて、ホストとポートを指定してください。 |
|
User Name Template |
認証されたユーザーを識別する、値の抽出に使用されるテンプレート |
表示されている値と同じものを入力します。また、' |
|
Allowed Clock Skew (minutes) |
アサーションに許容されるクロックの偏り。 |
表示されている値と同じものを入力します。 |
|
SSO Method |
SAMLに使用するSSOメソッド |
|
|
Response Signing Certificate |
レスポンスの署名に使用される証明書。 |
これは、認証局から取得した証明書です。手順「証明書を自分のキーストアにインポート」で、同じ証明書をキーストアにインポートしました。 |
サーバー証明書(たとえば、第18.3.5.4.6項「証明書リクエストの署名」で作成したserver.crt)をインポートします。
「Save Changes」をクリックして、変更を保存します。
認証レルムでは、サインインするためにユーザーが満たす必要のある条件が指定されます。レルムは、認証リソースのグループで構成されます。
SAMLのユーザー・レルムを作成するには、次の手順を実行します。
Juniper管理コンソールの左ペインで「Users」メニューを開き、「User Realms」をポイントして「New User Realm」をクリックします。
名前を「OAAM SAML 1.1 User Realm」と指定します。
前の手順でこのユーザー・レルムの認証サーバーとして作成された認証サーバー「OAAM SAML 1.1」を選択します。
変更を保存します。
新規に作成されたユーザー・レルムが表示されます。
Juniper管理コンソールの左ペインで「Users」メニューを開き、「User Realms」をポイントして「OAAM SAML 1.1 User Realm」をクリックします。
OAAM SAML 1.1. User Realmで「Role Mapping」タブをクリックして、1つ以上のロール・マッピング・ルールを構成します。
Juniper SAで、認証のためにOAAMにリダイレクトされるのに必要なURLを定義するサインイン・ポリシーを作成します。
サインイン・ポリシーを作成するには、Juniper管理コンソールで「Authentication」メニューを開き、「Signing In」をポイントして「Sign-in Policies」をクリックします。
「New URL」をクリックし、表示された「Sign-in URL」フィールドで、URLとして「*/OAAM11/」と入力します。
「Sign-in」ページで、「Default Sign-in Page」を選択します。
認証レルムに対して、前に作成した「OAAM SAML 1.1 User Realm」を選択します。
「Save Changes」をクリックして、それが有効になっていることを確認します。
必要なコンポーネントをすべて構成した後で、次の手順としてログイン・フローとパスワードを忘れた場合のフローをテストします。後続の手順に従って、OAAMとJuniper SAが正常に統合されたことを検証します。
ログイン・フローのテスト
Webブラウザを開いて、ターゲットのリソースURL、またはJuniperにより保護されている保護リソースURLに移動します。
Juniper管理コンソールにログインしたWebブラウザのインスタンスまたはウィンドウがないことを確認します。
ターゲット/保護されたリソースURLは、OAAM管理コンソールで指定されたoracle.saml.target.default.urlプロパティの値です。
OAAMサーバー・ログイン・ページが表示されます。
ログイン・プロセスを完了してください。
Juniperサインイン・ページが表示され、ユーザー名と、ブックマークおよびリソースへのリンクを示したサインイン・ページが表示されます。
パスワードを忘れた場合のフローのテスト
Webブラウザを開いて、ターゲットのリソースURL、またはJuniperにより保護されている保護リソースURLに移動します。
Juniper管理コンソールにログインしたWebブラウザのインスタンスまたはウィンドウがないことを確認します。
ターゲット/保護されたリソースURLは、OAAM管理コンソールで指定されたoracle.saml.target.default.urlプロパティの値です。
OAAMサーバー・ログイン・ページが表示されます。
ユーザー名を入力して、「続行」をクリックします。
「パスワード」ページで、「パスワード忘れ」リンクをクリックします。
チャレンジ質問またはOTPに回答します。
チャレンジに正しく回答した後、ユーザーはパスワードを変更して、Juniperサインイン・ページにログインできるようになります。
OAAM側で統合をデバッグするには、次の手順に従ってデバッグ・ログを有効にします。
Oracle Enterprise Manager Fusion Middleware Controlにログインします。たとえば、次のようになります。
http://host.domain.com:7001/em/
Fusion Middleware Controlの使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
「WebLogicドメイン」ノードを開き、OAAMサーバーをクリックします。
右クリックして「ログ」を選択し、「ログ構成」を選択して、OAAMサーバーのログ構成を開きます。
デフォルト・ロギングがFINERレベルに設定されます。
ログ・レベルをNOTIFICATION:1(INFO)に変更します。さらに、「コンポーネントの再起動後もログ・レベル状態を維持」を選択します。「適用」ボタンをクリックして、変更を保存します。
デバッグ・ログは次の場所にあります。
MW_HOME/user_projects/domains/YOURDOMAIN/servers/oaam_server/logs/oaam_server-diagnostic.log
この項では、Oracle Adaptive Access ManagerとJuniper SSLを統合した環境で生じる可能性のある一般的な問題と、その解決方法について説明します。
表示される可能性のあるエラー・メッセージの詳細は、この項に加えて、Oracle Fusion Middlewareエラー・メッセージ・リファレンスを参照してください。
その他のトラブルシューティング・リソースの詳細は、第28.1項「My Oracle Supportを使用したその他のトラブルシューティング情報」を参照してください。
Juniper SAとOAAMサーバーのシステム・クロックが同期化していることを確認します。Juniper SAシステム・クロックがOAAMサーバーのクロックよりも進まないようにする必要があります。Juniperアプリケーションの日付と時刻をリセットするには、『Juniper Networks Secure Access管理ガイド』を参照してください。次のJuniper Technical Documentation Webサイトにアクセスできます。
OAAMフローの完了後に、ユーザーが保護されたリソースにリダイレクトされず、WebサイトにInvalidCryptoExceptionが表示されます。
Juniper管理コンソールに、次のようなログが表示されます。
Logs(Juniper admin->Log/monitoring->Events): ERR24377 : Caught a SAML exception 'InvalidCryptoException' while verifying response. Error: SAMLSignedObject::verify() failed to validate signature value.
原因
正しい証明書がJuniperに存在しません。
解決策
サーバー証明書(たとえば、server.crt)がJuniperにアップロードされていることを確認します。第18.3.8.1項「SAML 1.1認証サーバーの作成」を参照してください。
OAAMにパスワードを入力した後、次のメッセージが表示されます。
There has been an error reaching your destination
次の例外がOAAMサーバー・ログ・ファイル(oaam_server_server1.log)に表示されます。
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:429)
at jsp_servlet.__samlsubmit._jspService(__samlsubmit.java:96)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:416)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:326)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
原因
SAMLレスポンスに署名の失敗がありました。
解決策
次のプロパティが正しい値に設定されていることを確認します。
詳細は、表18-2「SAML統合プロパティ」を参照してください。
| プロパティ | 説明 |
|---|---|
|
oracle.saml.keystore |
アサーションの署名に必要な証明書を格納するためのキーストアのフルパス。この例では、次のようになります。
|
|
oracle.saml.keystore.password |
キーストアのパスワード |
|
oracle.saml.keystore.certalias |
アサーションに使用する証明書の別名 |
|
oracle.saml.keystore.privatekeypassword |
秘密鍵のパスワード |
保護されたリソースにアクセスすると、次のエラー・メッセージが表示されます。
There has been an error reaching destination
原因
OAAMのエントリ・ポイントURLが、Juniperに正しく設定されていません。
解決策
ブラウザでURLを確認してください。https://OAAM_HOST:OAAM_PORT/oaam_server/juniperLoginPage.jspに設定されていない場合は、この正しい値に変更する必要があります。
次の手順を実行します。
Juniper管理コンソールにログインします。
左ペインで「Auth servers」をクリックします。
OAAMに対応しているサーバーを選択します。たとえば、OAAMサーバーです。
「Source Site Inter-Site Transfer Service URL」を次の値に設定します。
https://<OAAM_HOST>:<OAAM_PORT>/oaam_server/juniperLoginPage.jsp
変更を保存します。
