![]() ![]() ![]() ![]() |
この章では、それぞれのドメインで実行される WebLogic Portal プロデューサとコンシューマのセキュリティ レルムのコンフィグレーション方法について説明します。章の最初の部分では、プロデューサとコンシューマが共に WebLogic Portal バージョン 9.2 と以降のドメインで実行されている場合に必要なコンフィグレーションについて説明します。章の次の部分では、ドメインが混在している場合、すなわち、プロデューサとコンシューマが WebLogic Portal 8.1x ドメインまたは 9.2 と以降のドメインのいずれかで実行されている場合について説明します。
この節では、プロデューサとコンシューマが、別々の WebLogic Portal バージョン 9.2 と以降のドメイン間で実行されている場合にカスタム SAML トークンを使って WSRP セキュリティをコンフィグレーションする手順について説明します。この節で説明する手順を使用して、カスタム SAML トークンが必要とされるプロダクション システムのセキュリティをコンフィグレーションします。
注意 : | デフォルトでは、以前のコンフィグレーションが存在しない場合、WebLogic Portal 9.2 と以降のドメイン間では共通のキーを共有します。そのため、この節で説明するコンフィグレーション手順を経ることなく、デモンストレーションまたはテスト用に、ユーザ認証を必要とする連合ポータルを簡単に作成することができます。 |
警告 : | 前の「注意」で説明したデフォルトのキーをプロダクション環境で使用しないでください。このデフォルト設定を使用すると、どのコンシューマもプロデューサへ接続できるようになります。 |
図 15-1 に示すように、一般的なシナリオでは、コンシューマ アプリケーションとプロデューサ アプリケーションは別々の WebLogic Portal 9.2 と以降のドメインで実行されます。
デフォルトで WebLogic Portal では、WSRP 用のデフォルトのセキュリティ トークン タイプとして SAML が指定されます。デモンストレーション環境または開発環境下では、これ以上、コンフィグレーションを行う必要はありません。しかし、プロダクション環境の場合は、この節で説明する SAML コンフィグレーションを実行することをお勧めします。
この節では、プロデューサとコンシューマが別々の WebLogic Portal 9.2 と以降のドメインで実行されている連合ポータル アプリケーションの例を示します。この例は、これらのドメイン間での SAML セキュリティのコンフィグレーション方法を説明する際のベースとなります。
図 15-2 に示すポータルには、左側にローカル ポートレット、右側にリモート (プロキシ) ポートレットが表示されています。このローカル ポートレットは、ログイン ポートレットです。ユーザのログインが正常に実行されると、プロデューサ ポートレットにユーザの名前が表示されます。ただし、SAML セキュリティのコンフィグレーションが適切でない場合は、ユーザがポータルにログインしたときにエラー結果が表示されます。
図 15-2 から分かるように、ユーザがログインする前にはプロキシ ポートレットにエラーは表示されません。ユーザがログインを試行して初めて、SAML メッセージが送信され、エラーが発生します。
チェックポイント : この節では、プロデューサとコンシューマが別々の WebLogic Portal ドメインで実行されている連合ポータルの例を説明しました。以下の節では、コンシューマから送信される SAML トークンをプロデューサが受け入れるようにコンシューマとプロデューサをコンフィグレーションする方法について説明します。
前の節で示されたエラーを訂正するには、コンシューマとプロデューサの両方のコンフィグレーションが必要とされます。この節では、コンシューマのコンフィグレーションについて説明します。
ヒント : | 新たにキーを生成するときは必ず、キーストアをクラスタ全体にコピーする必要があります。 |
この節では、keytool ユーティリティを使用してコンシューマでキーを生成する方法について説明します。keytool ユーティリティは、Sun Microsystems が配布している Java ユーティリティで、プライベート キーと証明書を管理することができます。keytool の詳細については、Sun Microsystems の Web サイトを参照してください。
注意 : | デフォルトで、コンシューマは、サーバがその SSL キーに使用するキーストアを備えています。デフォルトのキーストアの名前は DemoIdentity.jks です。別のキーストアを使用する場合は、使用中のキーストアを変更してください。 |
WEBLOGIC_HOME/server/lib
ディレクトリに移動します。 testalias
という名前のキーが生成されます。
keytool -genkey -keypass testkeypass -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -keyalg rsa -alias testalias
サンプルの keytool コマンドで使用されるオプションは次のとおりです。
コンシューマ サーバからキーをエクスポートします。図 15-4 に示すように、キーの生成に使用したのと同じコマンド ウィンドウの同じディレクトリで、-export
オプションを使用して keytool コマンドを実行します。たとえば、次のコマンドを使用すると、testalias.der
という名前のキー ファイルが生成されます。
keytool -export -keypass testkeypass -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias testalias -file testalias.der
この節では、生成したキーを使用するようにコンシューマをコンフィグレーションする手順について説明します。
ヒント : | セキュリティ レルムは、ユーザ、グループ、セキュリティ ロール、セキュリティ ポリシー、セキュリティ プロバイダなど、WebLogic リソースの保護のために使用されるメカニズム用のコンテナです。WebLogic Server ドメイン内では複数のセキュリティ レルムを保持できますが、デフォルトの (アクティブな) レルムとして設定できるのは 1 つに限られます。デフォルトのレルム名は myrealm です。 |
serverIP
は、コンシューマ アプリケーションが動作しているサーバの IP アドレスで、port
は、サーバのポート番号です。次に例を示します。
ヒント : | SAML 資格マッパー プロバイダは、SAML セキュリティ アサーションのプロデューサとして機能します。これにより、シングル サインオンでの SAML の使用について WebLogic Server がソース サイトとして機能できるようになります。 |
http://www.bea.com/demoConsumer
ヒント : | [デフォルト生存時間] を 120 秒に、[資格キャッシュ最小有効生存時間] を 10 秒に、[デフォルト生存時間のオフセット] を 0 に設定することを推奨します。次に、[管理] タブを選択して、リライイング パーティのコンフィグレーションで、[アサーション生存時間のオフセット] をコンシューマとプロデューサのクロック時間の差 (コンシューマの時間からプロデューサの時間を引いた時間) に設定します。 |
チェックポイント : この時点で、コンシューマ上の SAML 資格マッパー プロバイダは、生成したキーストアを使用するようにコンフィグレーションされています。ここで、ログイン ポートレットへログインしようとすると、図 15-15 に示すように、エラーを受信します。この理由は、コンシューマから送信された新しいキーをプロデューサが認識しないためです。次の手順では、コンシューマから送信されたキーを受け入れるようにプロデューサをコンフィグレーションします。
ヒント : | 図 15-16 に示すように、ポータルを右側にスクロールすると、「The SAML token is not valid」というエラー メッセージを確認できます。 |
この節では、プロデューサのコンフィグレーション方法について説明します。そのためには、SAML アサータに証明書をインポートし、アサーティング パーティのプロパティをコンフィグレーションします。
testailias.der
) をプロデューサにコピーします。このファイルは、対象となるマシンの任意のディレクトリに置くことができます。 testalias
になります。 ヒント : | プロデューサのデフォルトの WSRP キー用に WsrpDefault アサーティング パーティが設定されています。コンシューマとプロデューサ アプリケーションが同じサーバで実行されている場合は、コンシューマの WSRP キーがプロデューサによって受け入れられます。このため、プロダクション環境にあるアプリケーションについては、WsrpDefault パーティを削除することをお勧めします。 |
demoConsumer
」と入力します。
WebLogic Portal 9.2 と以降のバージョンを使用して開発されたプロデューサ アプリケーションとコンシューマ アプリケーションは、WebLogic Portal 8.1 を使用して開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 9.2 と以降のバージョンを使用して開発したポータルは、WebLogic Portal 8.1x ドメインにデプロイされたポートレットを使用できます。同じように、WebLogic Portal 9.2 と以降のプロデューサでエクスポーズしたポートレットは、8.1x コンシューマによって使用できます。図 15-26 に、これら 2 つの使用例の概要を示します。
この節では、これらの両方の使用例について説明します。この章の内容は以下のとおりです。
この節では、WebLogic Portal 9.2 と以降のバージョン コンシューマと 8.1x プロデューサ間の SAML ベース セキュリティの互換性を実現する方法について説明します。この概要を図 15-27 に示します。
ヒント : | デフォルトでは、両側でコンフィグレーションの変更がない場合、9.2 と以降のバージョン コンシューマと 8.1x プロデューサ間で WSRP が機能します。つまり、9.2 と以降のバージョン コンシューマは、コンフィグレーションの変更なしで、8.1x プロデューサからのポートレットを使用できます。ただし、9.2 と以降のバージョン コンシューマ用に独自のキーを使用する場合は、この節で概説する手順に従う必要があります。 |
図 15-28 に示すポータルには、左側にローカル ポートレット、右側にリモート (プロキシ) ポートレットが表示されています。リモート ポートレットは 8.1x プロデューサでデプロイされます。このローカル ポートレットは、ログイン ポートレットです。SAML セキュリティが適切にコンフィグレーションされる前にユーザがログインすると、返される名前は null になります。
以下の節では、プロデューサに送信された SAML アサーションの署名が可能なキーを使ったコンシューマのコンフィグレーション方法について説明します。基本的なタスクは、次のとおりです。
この節では、keytool ユーティリティを使用してコンシューマでキーを生成する方法について説明します。keytool ユーティリティは、Sun Microsystems が配布している Java ユーティリティで、プライベート キーと証明書を管理することができます。keytool の詳細については、Sun Microsystems の Web サイトを参照してください。
WEBLOGIC_HOME/server/lib
ディレクトリに移動します。 consumer92key
という名前のキーが生成されます。
keytool -genkey -alias consumer92key -keystore wsrpKeystore.jks -storepass password -keypass consumer92pass
サンプルの keytool コマンドで使用されるオプションは次のとおりです。
wsrp-consumer-security-config.xml
をコピーします。Workshop for WebLogic でこれを行うには、マージ済みプロジェクト ビューを開き、コンシューマ Web アプリケーションの WEB-INF ディレクトリにあるこのファイルを検索します。ファイルを右クリックし [プロジェクトにコピー] を選択します。J2EE 共有ライブラリからのファイルのコピーの詳細については、『プロダクション業務ガイド』および『ポータル開発ガイド』を参照してください。 WEB-INF
ディレクトリにある wsrp-consumer-security-config.xml
ファイルを編集します。<consumer-name>
要素を wsrpConsumer
から別の任意の名前に変更します。たとえば、次のように変更します。
<consumer-name>wsrpConsumer<consumer-name>
<consumer-name>consumer9x<consumer-name>
チェックポイント : ここで、もう一度、リモート ポートレットにログインしようとすると、図 15-30 に示すように、エラーを受信します。このエラーの原因は、コンシューマから送信されたキーをプロデューサが見つけられないことによります。次は、コンシューマ ドメイン用にセキュリティ レルムをコンフィグレーションします。
http://
servername
:
portnumber
/console
servername
はサーバの IP 名で、portnumber
はサーバのポート番号です。次に例を示します。
ヒント : | PKI (公開鍵基盤) を使用すると、データを交換する際に、信頼された機関を使用して公開とプライベートの暗号キーの組み合わせを取得し、共有することができます。詳細については、WebLogic Server のドキュメントの「資格マッピング プロバイダのコンフィグレーション」を参照してください。 |
ヒント : | リモート リソース属性を空白のままにしておくと、資格がすべてのプロデューサによって受け入れられます。プロデューサを指定する場合は、このダイアログに適切な情報を入力してください。 |
consumerName
は、以前に wsrp-consumer-security-config.xml
ファイルに入力したコンシューマ名です (この名前の後には 2 つのアンダースコア文字が続きます)。
この例での [ローカル ユーザ] の正しい値は consumer9x__81_COMPAT
になります。
consumer92key
になります。consumer92pass
になります。consumer92__81_COMPAT
を示します。 keytool
ユーティリティを使用して、以前に作成したキーをエクスポートします。次の一連の手順では、このキーを使用して WebLogic Portal 8.1x プロデューサをコンフィグレーションします。次に例を示します。
keytool -export -alias consumer92key -keystore wsrpKeystore.jks -storepass password -keypass consumer92pass -file consumer92.der
チェックポイント : 上記の手順では、SAML アサーションに署名するためのキーにコンシューマ consumer92
を関連付けました。ここで、リモート ポートレットにログインしようとした場合、前に表示されたエラーは表示されません。つまり、コンシューマは、現在、キーに適切に関連付けられています。ただし、この時点では、ログイン後、図 15-34 に示すように、ユーザ名は null
になります。これは、このコンシューマがプロデューサでまだ認識されていないためです。次の一連の手順は、WebLogic Portal 9.2 と以降のバージョン コンシューマのキーを受け入れるように WebLogic Portal 8.1x プロデューサをコンフィグレーションする方法を示しています。
ヒント : | WebLogic Portal 9.2 と以降のバージョン プロデューサと WebLogic Portal 8.1x プロデューサの動作には重要な違いがあります。WebLogic Portal 9.2 と以降のバージョン プロデューサが、コンシューマが送信しているメッセージを確認できない場合は、エラーを受信しますが、WebLogic Portal 8.1x プロデューサが、コンシューマが送信しているメッセージを確認できない場合、プロデューサはこの状況を無視し、匿名ユーザを使って処理を続行します。さらに、8.1x コンシューマが 9.2 と以降のバージョン プロデューサに検証不可能なメッセージを送信した場合は、同様にプロデューサはこの状態を無視し、匿名ユーザを使って処理を続行します。 |
この節では、WebLogic Portal 8.1x プロデューサのコンフィグレーション方法について説明します。そのためには、キーをプロデューサのキーストアへインポートします。
BEA_HOME/weblogic81/user_projects/domains/portalDomain
keytool -import -keystore wsrpKeystore.jks -file c:\consumer92.der -storepass password -alias consumer9x -keypass consumer92pass
注意 : | alias 引数は、コンシューマでキーを作成したときに使用したコンシューマ名に一致していなければなりません。この例での名前は、consumer9x になります。 |
プロデューサ サーバの再起動後は、コンシューマ アプリケーションでもう一度、リモート ポートレットをテストすることができます。図 15-35 に示すように、ポータルにログインすると、今回はリモート ポートレットが、ユーザがログインしたと認識していることがわかります。
上記の例は、WebLogic Portal 9.2 と以降のバージョン コンシューマと WebLogic Portal 8.1x プロデューサ間の SAML セキュリティのコンフィグレーション方法を示したものです。次の例では、反対に WebLogic Portal 8.1x コンシューマと WebLogic Portal 9.2 と以降のバージョン プロデューサ間の SAML セキュリティのコンフィグレーションを示します。
この節では、WebLogic Portal 8.1x コンシューマと 9.2 と以降のバージョン プロデューサ間のセキュリティの互換性を実現する方法について説明します。この概要を図 15-36 に示します。
この節では、8.1x プロデューサのコンフィグレーション方法について説明します。基本的な手順には、キーの生成と WebLogic Administration Portal での WSRP コンシューマ セキュリティ サービスのコンフィグレーションが含まれます。
この節では、keytool ユーティリティを使って、コンシューマでキーを生成する方法について説明します。Sun Microsystems が配布している Java ユーティリティである keytool は、プライベート キーと証明書を管理することができます。keytool の詳細については、Sun Microsystems の Web サイトを参照してください。
BEA_HOME/weblogic81/user_projects/domains/portal
keytool -genkey -keystore wsrpKeystore.jks -alias consumer8xkey -storepass password -keypass consumer8xpass
サンプルの keytool コマンドで使用されるオプションは次のとおりです。
http://localhost:7001/
applicationName
/login.jsp
applicationName
は WebLogic Portal コンシューマ アプリケーションの名前です。
keytool -export -alias consumer8xkey -keystore wsrpKeystore.jks -file consumer81.der
この節では、プロデューサのコンフィグレーション方法について説明します。そのためには、コンシューマの証明書を含むようにプロデューサの PKI 資格マッピングをコンフィグレーションする必要があります。
keytool -import -keystore wsrpKeystore.jks -file consumer81.der -alias consumer8xkey -keypass consumer8xpass
ヒント : | PKI (公開鍵基盤) を使用すると、データを交換する際に、信頼された機関を使用して公開とプライベートの暗号キーの組み合わせを取得し、共有することができます。詳細については、WebLogic Server のドキュメントの「資格マッピング プロバイダのコンフィグレーション」を参照してください。 |
ヒント : | フィールドを空白のままにしておくと、すべてのコンシューマに対して資格が認識されます。資格を特定のコンシューマに限定する場合は、必要な情報を入力できます。 |
consumerName
__81_COMPAT
」と入力する。consumerName
はコンシューマの名前です。この例での名前は、consumer8x
です。 consumer8xkey
です。 consumer81pass
です。
図 15-43 はダイアログの入力を示しています。
コンフィグレーションをテストするには、コンシューマ ポータルにログインします。図 15-45 に示すように、ユーザ名 weblogic
がプロキシ ポートレットに表示されます。これは、ユーザがプロデューサへのログインに成功したことを示しています。
名前マッパーは、ユーザ名を別のユーザ名にマッピングするクラスです。名前マッパーは、プロデューサとコンシューマで同一のユーザに対して異なる名前が設定されている場合に使用します。この節では、コンシューマとプロデューサの両方における名前マッパー クラスの記述およびコンフィグレーション方法について説明します。
プロデューサまたはコンシューマで名前マッピング クラスを使用する場合の基本的な手順は次のとおりです。
WebLogic Portal は、2 つのユーザ名マッピング インタフェースを備えています。
コンシューマにこのインタフェースを実装して、コンシューマのユーザ名を新しい名前にマッピングします。例については、「コンシューマでの SAMLCredentialNameMapper の実装」を参照してください。
プロデューサにこのインタフェースを実装して、コンシューマから送信されたユーザ名をプロデューサのユーザ名にマッピングします。例については、「プロデューサでの SAMLIdentityAssertionNameMapper の実装」を参照してください。
コンシューマで SAMLCredentialNameMapper を実装して、コンシューマでの名前マッピングを提供します。コード リスト 15-1 は、SAMLCredentialNameMapper の実装例を示しています。
mapSubject() メソッドはサブジェクト (ユーザ) を取得して、SAMLNameMapperInfo オブジェクトを返します。このメソッドは、ユーザ名をテストして、そのユーザ名を新しいユーザ名に置き換えるためのロジックを提供します。次に、このユーザ名が SAMLNameMapperInfo オブジェクトによって返され、その後、プロデューサに渡されます。
このインタフェースの詳細については、「Javadoc」を参照してください。
package com.bea.wsrp.qa.security;
import java.util.Collection;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.security.SubjectUtils;
import weblogic.security.providers.saml.SAMLCredentialNameMapper;
import weblogic.security.providers.saml.SAMLNameMapperInfo;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.WLSGroup;
public class CustomSAMLNameMapperImpl implements SAMLCredentialNameMapper {
private String nameQualifier = null;
public CustomSAMLNameMapperImpl (){ }
/************ SAMLCredentialNameMapper 実装**************/
public synchronized void setNameQualifier(String nameQualifier)
{
this.nameQualifier = nameQualifier;
}
public SAMLNameMapperInfo mapName (String name, ContextHandler handler)
{
return new SAMLNameMapperInfo(nameQualifier, name, null);
}
public SAMLNameMapperInfo mapSubject (Subject subject, ContextHandler handler)
{
// プロバイダは null サブジェクトをチェックします。
Set groups = subject.getPrincipals(WLSGroup.class);
String userName = null;
userName = SubjectUtils.getUsername(subject);
if (userName == null || userName.equals("")) {
System.out.println("mapSubject: Username string is null or
empty, returning null");
return null;
}
if (userName.equals("testUser"))
{
userName = "testUser_Mapped";
}
// マッピング情報を返します。
return new SAMLNameMapperInfo(nameQualifier, userName, groups);
}
}
プロデューサで SAMLIdentityAssertionNameMapper を実装して、名前マッピングを提供します。コード リスト 15-2 は、SAMLIdentityAssertionNameMapper の実装例を示しています。この例では、ユーザがコンシューマに testUser_Mapped
としてログインします。この場合、名前マッパー クラスがプロデューサでそのユーザ名を取得し、ユーザは testUser_Producer
としてログインします。
mapNameInfo() メソッドは、コンシューマから SAMLNameMapperInfo オブジェクトを取得します。このオブジェクトには、ユーザがコンシューマでのログインに使った名前が含まれます。このメソッドは、コンシューマから取得したユーザ名をテストして、そのユーザ名をプロデューサ上のユーザ名に置き換えるためのロジックを提供します。
このインタフェースの詳細については、「Javadoc」を参照してください。
package com.bea.wsrp.qa.security;
import java.util.Collection;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.security.SubjectUtils;
import weblogic.security.providers.saml.SAMLIdentityAssertionNameMapper;
import weblogic.security.providers.saml.SAMLNameMapperInfo;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.WLSGroup;
public class CustomSAMLNameMapperImpl implements SAMLIdentityAssertionNameMapper
{
private String nameQualifier = null;
public CustomSAMLNameMapperImpl (){ }
/************ SAMLIdentityAssertionNameMapper 実装**************/
public String getGroupAttrName ()
{
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAME;
}
public String getGroupAttrNamespace ()
{
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAMESPACE;
}
public Collection mapGroupInfo(SAMLNameMapperInfo info, ContextHandler handlr)
{
return info.getGroups();
}
public String mapNameInfo(SAMLNameMapperInfo info, ContextHandler handler)
{
String userName = info.getName();
if (userName == null || userName.equals("")) {
System.out.println("mapNameInfo: Username string is null or
empty, returning null");
return null;
}
if (userName.equals("testUser_Mapped"))
{
userName = "testUser_Producer";
}
return userName;
}
}
マッパー クラスをプロデューサで実装するか、コンシューマで実装するかにかかわらず、マッパー クラスはサーバのクラスパスに含まれていなければなりません。サーバのクラスパスにクラスを追加する方法については、WebLogic Server トピックの「クラスパスへの起動クラスおよび停止クラスの追加」に関する説明を参照してください。
マッパー クラスをプロデューサやコンシューマのセキュリティ レルムに追加するには、WebLogic Server Administration Console を使用する必要があります。
プロデューサにマッパー クラスを追加するには、次の手順に従います。
com.bea.wsrp.qa.security.CustomSAMLNameMapperImpl
プロデューサにマッパー クラスを追加するには、次の手順に従います。
ヒント : | リライイング パーティのコンフィグレーションの詳細については、WebLogic Server トピックの「リライイング パーティのコンフィグレーション」に関する説明を参照してください。 |
com.bea.wsrp.qa.security.CustomSAMLNameMapperImpl
コンシューマから送信されたユーザ名をプロデューサが認識しない場合、自動的に新規ユーザを作成するようにプロデューサをコンフィグレーションできます。この機能は、コンシューマ アプリケーションからログインする可能性があるすべてのユーザに対して、プロデューサでユニークなユーザ名を手動で作成しないようにする場合に便利です。この機能は、前述のとおり、コンシューマの SAML トークンを認識するようにプロデューサがコンフィグレーションされている場合に限り使用することができます。
仮想ユーザを許可するようにプロデューサをコンフィグレーションするには、次の手順を実行します。
![]() ![]() ![]() |