連合ポータル ガイド

SAML による WSRP セキュリティの確立

この章では、それぞれのドメインで実行される WebLogic Portal プロデューサとコンシューマのセキュリティ レルムのコンフィグレーション方法について説明します。章の最初の部分では、プロデューサとコンシューマが共に WebLogic Portal 9.x ドメインで実行されている場合に必要なコンフィグレーションについて説明します。章の次の部分では、ドメインが混在している場合、すなわち、プロデューサとコンシューマが WebLogic Portal 8.1x ドメインまたは 9.x ドメインのいずれかで実行されている場合について説明します。

この章の内容は以下のとおりです。

WebLogic Portal 9.x ドメイン間の SAML セキュリティ

この節では、プロデューサとコンシューマが、別々の WebLogic Portal 9.x ドメイン間で実行されている場合にカスタム SAML トークンを使って WSRP セキュリティをコンフィグレーションする手順について説明します。この節で説明する手順を使用して、カスタム SAML トークンが必要とされるプロダクション システムのセキュリティをコンフィグレーションします。

この節では、次のトピックについて説明します。

概要

図 15-1 に示すように、一般的なシナリオでは、コンシューマ アプリケーションとプロデューサ アプリケーションは別々の WebLogic Portal 9.x ドメインで実行されます。

デフォルトで WebLogic Portal では、WSRP 用のデフォルトのセキュリティ トークン タイプとして SAML が指定されます。デモンストレーション環境または開発環境下では、これ以上、コンフィグレーションを行う必要はありません。しかし、プロダクション環境の場合は、この節で説明する SAML コンフィグレーションを実行することをお勧めします。

SAML コンフィグレーションの設定例

この節では、プロデューサとコンシューマが別々の WebLogic Portal 9.x ドメインで実行されている連合ポータル アプリケーションの例を示します。この例は、これらのドメイン間での SAML セキュリティのコンフィグレーション方法を説明する際のベースとなります。

図 15-2 に示すポータルには、左側にローカル ポートレット、右側にリモート (プロキシ) ポートレットが表示されています。このローカル ポートレットは、ログイン ポートレットです。ユーザのログインが正常に実行されると、プロデューサ ポートレットにユーザの名前が表示されます。ただし、SAML セキュリティのコンフィグレーションが適切でない場合は、ユーザがポータルにログインしたときにエラー結果が表示されます。

図 15-2 から分かるように、ユーザがログインする前にはプロキシ ポートレットにエラーは表示されません。ユーザがログインを試行して初めて、SAML メッセージが送信され、エラーが発生します。

チェックポイント : この節では、プロデューサとコンシューマが別々の WebLogic Portal ドメインで実行されている連合ポータルの例を説明しました。以下の節では、コンシューマから送信される SAML トークンをプロデューサが受け入れるようにコンシューマとプロデューサをコンフィグレーションする方法について説明します。

コンシューマのコンフィグレーション

前の節で示されたエラーを訂正するには、コンシューマとプロデューサの両方のコンフィグレーションが必要とされます。この節では、コンシューマのコンフィグレーションについて説明します。

キーの生成

この節では、keytool ユーティリティを使用してコンシューマでキーを生成する方法について説明します。keytool ユーティリティは、Sun Microsystems が配布している Java ユーティリティで、プライベート キーと証明書を管理することができます。keytool の詳細については、Sun Microsystems の Web サイトを参照してください。

キーのエクスポート

コンシューマ サーバからキーをエクスポートします。図 15-4 に示すように、キーの生成に使用したのと同じコマンド ウィンドウの同じディレクトリで、-export オプションを使用して keytool コマンドを実行します。たとえば、次のコマンドを使用すると、testalias.der という名前のキー ファイルが生成されます。

keytool -export -keypass testkeypass -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias testalias -file testalias.der

コンシューマのセキュリティ レルムの変更

この節では、生成したキーを使用するようにコンシューマをコンフィグレーションする手順について説明します。

チェックポイント : この時点で、コンシューマ上の SAML 資格マッパー プロバイダは、生成したキーストアを使用するようにコンフィグレーションされています。ここで、ログイン ポートレットへログインしようとすると、図 15-15 に示すように、エラーを受信します。この理由は、コンシューマから送信された新しいキーをプロデューサが認識しないためです。次の手順では、コンシューマから送信されたキーを受け入れるようにプロデューサをコンフィグレーションします。

プロデューサのコンフィグレーション

この節では、プロデューサのコンフィグレーション方法について説明します。そのためには、SAML アサータに証明書をインポートし、アサーティング パーティのプロパティをコンフィグレーションします。

証明書のインポート

アサーティング パーティのプロパティのコンフィグレーション

コンフィグレーションのテスト

WebLogic Portal 8.1x ドメインと 9.x ドメイン間の SAML セキュリティ

WebLogic Portal 9.x を使用して開発されたプロデューサ アプリケーションとコンシューマ アプリケーションは、WebLogic Portal 8.1x を使用して開発されたプロデューサおよびコンシューマと互換性があります。つまり、WebLogic Portal 9.x を使用して開発したポータルは、WebLogic Portal 8.1x ドメインにデプロイされたポートレットを使用できます。同じように、WebLogic Portal 9.x プロデューサでエクスポーズしたポートレットは、8.1x コンシューマによって使用できます。図 15-26 に、これら 2 つの使用例の概要を示します。

この節では、これらの両方の使用例について説明します。この章の内容は以下のとおりです。

9.x コンシューマと 8.1x プロデューサ間の SAML セキュリティ

この節では、WebLogic Portal 9.x コンシューマと 8.1x プロデューサ間の SAML ベース セキュリティの互換性を実現する方法について説明します。この概要を図 15-27 に示します。

図 15-28 に示すポータルには、左側にローカル ポートレット、右側にリモート (プロキシ) ポートレットが表示されています。リモート ポートレットは 8.1x プロデューサでデプロイされます。このローカル ポートレットは、ログイン ポートレットです。SAML セキュリティが適切にコンフィグレーションされる前にユーザがログインすると、返される名前は null になります。

コンシューマのコンフィグレーション

以下の節では、プロデューサに送信された SAML アサーションの署名が可能なキーを使ったコンシューマのコンフィグレーション方法について説明します。基本的なタスクは、次のとおりです。

キーの生成

この節では、keytool ユーティリティを使用してコンシューマでキーを生成する方法について説明します。keytool ユーティリティは、Sun Microsystems が配布している Java ユーティリティで、プライベート キーと証明書を管理することができます。keytool の詳細については、Sun Microsystems の Web サイトを参照してください。

コンシューマの名前の変更

チェックポイント : ここで、もう一度、リモート ポートレットにログインしようとすると、図 15-30 に示すように、エラーを受信します。このエラーの原因は、コンシューマから送信されたキーをプロデューサが見つけられないことによります。次は、コンシューマ ドメイン用にセキュリティ レルムをコンフィグレーションします。

コンシューマのセキュリティ レルムの変更

チェックポイント : 上記の手順では、SAML アサーションに署名するためのキーにコンシューマ consumer92 を関連付けました。ここで、リモート ポートレットにログインしようとした場合、前に表示されたエラーは表示されません。つまり、コンシューマは、現在、キーに適切に関連付けられています。ただし、この時点では、ログイン後、図 15-34 に示すように、username は null になります。これは、このコンシューマがプロデューサでまだ認識されていないためです。次の一連の手順は、WebLogic Portal 9.x コンシューマのキーを受け入れるように WebLogic Portal 8.1x プロデューサをコンフィグレーションする方法を示しています。

WebLogic Portal 8.1x プロデューサのコンフィグレーション

この節では、WebLogic Portal 8.1x プロデューサのコンフィグレーション方法について説明します。そのためには、キーをプロデューサのキーストアへインポートします。

証明書のインポート

コンフィグレーションのテスト

プロデューサ サーバの再起動後は、コンシューマ アプリケーションでもう一度、リモート ポートレットをテストすることができます。図 15-35 に示すように、ポータルにログインすると、今回はリモート ポートレットが、ユーザがログインしたと認識していることがわかります。

まとめ

上記の例は、WebLogic Portal 9.x コンシューマと WebLogic Portal 8.1x プロデューサ間の SAML セキュリティのコンフィグレーション方法を示したものです。次の例では、反対に WebLogic Portal 8.1x コンシューマと WebLogic Portal 9.x プロデューサ間の SAML セキュリティのコンフィグレーションを示します。

8.1x コンシューマと 9.x プロデューサ間の SAML セキュリティ

この節では、WebLogic Portal 8.1x コンシューマと 9.x プロデューサ間のセキュリティの互換性を実現する方法について説明します。この概要を図 15-36 に示します。

基本的な手順は、次のとおりです。

8.1x コンシューマのコンフィグレーション

この節では、8.1x プロデューサのコンフィグレーション方法について説明します。基本的な手順には、キーの生成と WebLogic Administration Portal での WSRP コンシューマ セキュリティ サービスのコンフィグレーションが含まれます。

キーの生成

この節では、keytool ユーティリティを使って、コンシューマでキーを生成する方法について説明します。Sun Microsystems が配布している Java ユーティリティである keytool は、プライベート キーと証明書を管理することができます。keytool の詳細については、Sun Microsystems の Web サイトを参照してください。

9.x プロデューサのコンフィグレーション

この節では、プロデューサのコンフィグレーション方法について説明します。そのためには、コンシューマの証明書を含むようにプロデューサの PKI 資格マッピングをコンフィグレーションする必要があります。

コンフィグレーションのテスト

コンフィグレーションをテストするには、コンシューマ ポータルにログインします。図 15-45 に示すように、ユーザ名 weblogic がプロキシ ポートレットに表示されます。これは、ユーザがプロデューサへのログインに成功したことを示しています。

名前マッパーによる SAML セキュリティの使用

名前マッパーは、ユーザ名を別のユーザ名にマッピングするクラスです。名前マッパーは、プロデューサとコンシューマで同一のユーザに対して異なる名前が設定されている場合に使用します。この節では、コンシューマとプロデューサの両方における名前マッパー クラスの記述およびコンフィグレーション方法について説明します。

プロデューサまたはコンシューマで名前マッピング クラスを使用する場合の基本的な手順は次のとおりです。

名前マッパー クラスの記述

WebLogic Portal は、2 つのユーザ名マッピング インタフェースを備えています。

コンシューマでの SAMLCredentialNameMapper の実装

コンシューマで 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 の実装

プロデューサで 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 を使用する必要があります。

プロデューサへのマッパー クラスの追加

プロデューサにマッパー クラスを追加するには、以下の操作を行います。

コンシューマへのマッパー クラスの追加

プロデューサにマッパー クラスを追加するには、以下の操作を行います。

仮想ユーザの許可

コンシューマから送信されたユーザ名をプロデューサが認識しない場合、自動的に新規ユーザを作成するようにプロデューサをコンフィグレーションできます。この機能は、コンシューマ アプリケーションからログインする可能性があるすべてのユーザに対して、プロデューサでユニークなユーザ名を手動で作成しないようにする場合に便利です。この機能は、前述のとおり、コンシューマの SAML トークンを認識するようにプロデューサがコンフィグレーションされている場合に限り使用することができます。

仮想ユーザを許可するようにプロデューサをコンフィグレーションするには、次の手順を実行します。