ユーザ管理ガイド
![]() |
![]() |
![]() |
![]() |
ユーザ、グループ、および追加プロパティ (住所、電子メール アドレス、電話番号など) の既存ストアがある場合は、統合ユーザ プロファイルを作成すると、既存ストアのユーザ プロパティを WebLogic Portal 環境で使用できます。WebLogic Portal 環境では、統合ユーザ プロファイルを使用して、プロパティ値の取得と編集、パーソナライゼーション、委託管理、および訪問者の資格の設定を実行できます。
この章では、統合ユーザ プロファイルとは何か、どのような場合に使用し、どのような場合に使用しないかについて説明します。
注意 : ここでは、「ユーザ ストア」と「データ ストア」という用語を使用しています。ユーザ ストアには、ユーザとグループ、および追加プロパティを格納できます。データ ストアは、必ずしもユーザとグループを格納する必要のないストアです。プロパティだけを格納することもできます。
ここでは、統合ユーザ プロファイルとは何であり、どのような働きをするものなのかについて、例を示して説明します。
新しいポータル アプリケーションを作成し、そのアプリケーションにユーザがログインできるようにするとします。ユーザは WebLogic 環境の外部にある RDBMS ユーザ ストアに格納されているものとします。この場合、WebLogic Server (ポータル アプリケーションのドメイン サーバ インスタンス) を RDBMS システムに接続すると、ユーザは、ユーザ名とパスワードが WebLogic Server に格納されている場合と同様に、ポータル アプリケーションにログインできます。RDBMS ユーザ ストアを通して認証を提供することのみが目的の場合は、この処置だけでよく、統合ユーザ プロファイルは不要です。
ここでは、RDBMS ユーザ ストアに電子メールと電話番号の情報 (プロパティ) が格納されていて、ポータル アプリケーションでそれらのプロパティにアクセスしたいとします。この場合は、コードから追加プロパティへのアクセスを可能にする、RDBMS ユーザ ストア用の統合ユーザ プロファイルを作成する必要があります。
技術的に説明すると、統合ユーザ プロファイルは、LDAP サーバやデータベースなどの外部データ ストアに格納されているプロパティ値を WebLogic Portal に読み込めるようにするために作成するステートレス セッション Bean (および関連クラス) です。統合ユーザ プロファイルを使用して外部データ ストアに接続すると、ポータル JSP タグ、コントロール、および WebLogic Portal API を使用して外部データ ストアからユーザ プロパティを取得できます。さらに、WebLogic Administration Portal に外部プロパティを表示し、外部プロパティを使用してパーソナライゼーション、訪問者の資格、および委託管理に関するルールを定義することもできます。
外部ユーザ ストアに追加プロパティが格納されているかどうかにかかわらず、WebLogic Server に接続した外部ユーザとグループには、WebLogic Portal に設定されたデフォルト ユーザ プロパティ値が自動的に割り当てられます。このとき、統合ユーザ プロファイルは使用されません。WebLogic Administration Portal を使用して、WebLogic Portal のデフォルトのユーザ プロパティ値を変更できます。それらの値は、WebLogic Portal の RDBMS データ ストアに Portal スキーマを使用して格納されます。
統合ユーザ プロファイル、外部ユーザ ストア、および WebLogic 環境の関係を次の図に示します。
ユーザ プロファイルはセキュリティ レルムではありません。したがって認証の機能はありません。外部ユーザ ストアそのものでもありません。ユーザ プロファイルは、外部ユーザ ストアのプロパティを読み込めるようにする接続 (ステートレス セッション Bean と関連クラス) です。
外部データ ストア用の統合ユーザ プロファイルは、次のいずれかを実行する場合に作成します。
次の場合は、外部データ ストア用の統合ユーザ プロファイルを作成する必要はありません。
ここでは、外部ユーザ ストアのユーザ プロパティまたはグループ プロパティにアクセスするための、統合ユーザ プロファイル (UUP) の作成に関するガイドラインと手順を説明します (概要については、「統合ユーザ プロファイルの概要」を参照)。
UUP を作成して外部ソースからユーザ データを取得するには、以下の作業を行います。
外部ソースのデータを取り込むには、com.bea.p13n.property.EntityPropertyManager リモート インタフェースのメソッドを実装するステートレス セッション Bean を最初に作成する必要があります。EntityPropertyManager は、プロパティ データの永続性と、プロファイル レコードの作成および削除を処理するセッション Bean 用のリモート インタフェースです。デフォルトでは、EntityPropertyManager は外部プロパティへの読み取り専用アクセスを提供します。
さらに、このステートレス セッション Bean にホーム インタフェースと実装クラスを含める必要があります。次に例を示します。
MyEntityPropertyManager
extends com.bea.p13n.property.EntityPropertyManager
MyEntityPropertyManagerHome
extends javax.ejb.EJBHome
作成する実装クラスは、EntityPropertyManagerImpl クラスを拡張できます。唯一の要件は、作成する実装クラスが MyEntityPropertyManager リモート インタフェースの有効な実装であることです。次に例を示します。
MyEntityPropertyManagerImpl extends
com.bea.p13n.property.internal.EntityPropertyManagerImpl
MyEntityPropertyManagerImpl extends
javax.ejb.SessionBean
新しい EJB について推奨されるガイドラインを次に示します。
作成した JAR ファイルをデプロイする前に、次の節に示す手順を実行します。
「ユーザ タイプ」は、ProfileType 名と特定の ProfileManager とのマッピングです。このマッピングは UserManager EJB デプロイメント記述子で行います。
新しく作成した EntityPropertyManager EJB のデータにアクセスするには、次のいずれかを実行する必要があります。
ProfileManager は、EntityPropertyManager EJB が取得するプロファイル値へのアクセスを管理するステートレス セッション Bean です。ProfileManager は、デプロイメント記述子内のマッピング文に基づいてデータを検索します。たとえば、ProfileManager が、「PersonalData」プロパティ セットに含まれる「DateOfBirth」プロパティの値を求める要求を受信したとします。ProfileManager は、デプロイメント記述子内のマッピング文を使用して、どの EntityPropertyManager EJB にデータが格納されているかを判別します。
UserProfileManager の既存のデプロイメントを使用してユーザ プロファイルを管理する場合は、次の手順に従って、デプロイメントのコンフィグレーションを変更します。
ほとんどの場合、作成した UUP をデプロイするにはこの方法を使用します。この方法の一例は、LDAP プロパティを取得するためのカスタム EntityPropertyManager のデプロイメントである LdapPropertyManager です。LdapPropertyManager のクラスは、p13n_ejb.jar にパッケージ化されます。UserProfileManager EJB のデプロイメント記述子は、「ldap」プロパティ セットを LdapPropertyManager にマップするようにコンフィグレーションされます。UserProfileManager は、p13n_ejb.jar でデプロイされます。
<!-- map all properties in property set ldap to ldap server -->
<env-entry>
<env-entry-name>PropertyMapping/ldap</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>LdapPropertyManager</env-entry-value>
</env-entry>
この要素の下に、プロパティ セットをカスタム EntityPropertyManager にマップする <env-entry> 要素を追加します。次の例のようになります。
<!-- map all properties in UUPExample property set to MyEntityPropertyManager -->
<env-entry>
<env-entry-name>PropertyMapping/UUPExample</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>MyEntityPropertyManager</env-entry-value>
</env-entry>
<!-- an ldap property manager -->
<ejb-ref>
<ejb-ref-name>ejb/LdapPropertyManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.property.EntityPropertyManagerHome</home>
<remote>com.bea.p13n.property.EntityPropertyManager</remote>
</ejb-ref>
この要素の下に、前の手順で使用した名前に ejb/ を付加した名前と一致する EJB への参照をマップする <ejb-ref> 要素を追加します。次の例のようになります。
<!-- an example property manager -->
<ejb-ref>
<ejb-ref-name>ejb/MyEntityPropertyManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>examples.usermgmt.MyEntityPropertyManagerHome</home>
<remote>examples.usermgmt.MyEntityPropertyManager</remote>
</ejb-ref>
ホーム クラス名とリモート クラス名は、カスタム EntityPropertyManager EJB の JAR ファイル内にあるクラスと一致します。
<env-entry>
<env-entry-name>Creator/Creator1</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>MyEntityPropertyManager</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>Remover/Remover1</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>MyEntityPropertyManager</env-entry-value>
</env-entry>
これは、ユーザ プロファイル レコードを作成または削除するときにカスタム EntityPropertyManager を呼び出すよう、UserProfileManager に指示します。「Creator1」と「Remover1」という名前は、任意です。すべての Creator と Remover は、UserProfileManager がユーザ プロファイルを作成または削除するときに反復処理されます。Creator および Remover の値は、カスタム EntityPropertyManager の ejb-ref-name から ejb/ プレフィックスを削除したものと一致します。
<weblogic-enterprise-bean>
<ejb-name>UserProfileManager</ejb-name>
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>ejb/EntityPropertyManager</ejb-ref-name>
<jndi-name>${APPNAME}.BEA_personalization.EntityPropertyManager</jndi-name>
</ejb-reference-description>
カスタム EntityPropertyManager の ejb-ref を JNDI 名にマップする ejb-reference-description を追加します。この JNDI 名は、カスタム EntityPropertyManager の JAR ファイルの weblogic-ejb-jar.xml で割り当てた名前に一致する必要があります。次の例のようになります。
<weblogic-enterprise-bean>
<ejb-name>UserProfileManager</ejb-name>
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>ejb/EntityPropertyManager</ejb-ref-name>
<jndi-name>${APPNAME}.BEA_personalization.EntityPropertyManager</jndi-name>
</ejb-reference-description>
<ejb-reference-description>
<ejb-ref-name>ejb/MyEntityPropertyManager</ejb-ref-name>
<jndi-name>${APPNAME}.BEA_personalization.MyEntityPropertyManager</jndi-name>
</ejb-reference-description>
文字列置換変数 ${APPNAME} に注意してください。WebLogic EJB コンテナは、JNDI 名のスコープがエンタープライズ アプリケーションになるようにアプリケーション名を自動的に置き換えます。
<module>
<ejb>UUPExample.jar</ejb>
</module>
<Cache Name="UUPExampleCache" TimeToLive="60000"/>
これで、新しい統合ユーザ プロファイルを使用する準備が整いました。WebLogic Administration Portal を使用してユーザを作成することができます。「UUPExample」プロパティ セットが変更されるときに UUP の実装が使用されます。UserManager で createUser("bob", "password") または createUser("bob", "password", null) を呼び出すと、次に示すいくつかの処理が行われます。
デフォルトの ProfileManager (UserProfileManager) ではなく、新しくコンフィグレーションした ProfileManager をデプロイしてユーザ プロファイルを管理する場合は、次の手順に従ってデプロイメントのコンフィグレーションを変更します。ほとんどの場合、このデプロイメント方法を使用する必要はありません。複数のユーザ タイプをサポートする必要があり、それぞれのユーザ タイプで異なる ProfileManager のデプロイメント (ProfileType に基づいてプロパティ セットを異なるカスタム EntityPropertyManagers にマップできるデプロイメント) が必要な場合にのみ、この方法を使用します。
この方法の例として、customer.jar 内のカスタム CustomerProfileManager のデプロイメントがあります。CustomerProfileManager は、「CustomerProperties」プロパティ セット内のプロパティに対して、カスタム EntityPropertyManager (CustomerPropertyManager) を使用するようにコンフィグレーションされます。p13n_ejb.jar 内の UserManager EJB は、「WLCS_Customer」という ProfileType を ProfileManager のカスタム デプロイメントである CustomerProfileManager にマップするようにコンフィグレーションされます。
新しい ProfileManager をコンフィグレーションしてデプロイするには、次の手順に従います。
さらに、UserProfileManager のホーム インタフェースとリモート インタフェースを独自のパッケージングに対応させて再パッケージ化する場合は、独自のインタフェースを使用してホーム インタフェースとリモート インタフェースを拡張できます (例 : examples.usermgmt.MyProfileManagerHome、examples.usermgmt.MyProfileManager)。
プロパティ セットをカスタム EntityPropertyManager にマップする <env-entry> 要素を作成する必要があります。PropertyMapping の名前に ejb/ を付加した名前に一致する EJB への参照をマップする <ejb-ref> 要素も作成する必要があります。カスタム EntityPropertyManager のホーム クラス名とリモート クラス名は、カスタム EntityPropertyManager EJB の JAR ファイル内にあるクラスと一致します。
また、作成した EntityPropertyManager の実装で、プロファイル レコードの作成と削除を処理する場合は、Creator エントリと Remover エントリも追加する必要があります。それによって、ユーザ プロファイル レコードを作成または削除するときはカスタム EntityPropertyManager を呼び出すよう、新しい ProfileManager に指示します。
注意 : Creator と Remover の名前のサフィックスである「Creator1」と「Remover1」は、任意です。すべての Creator と Remover は、作成した UserProfileManager がユーザ プロファイルを作成または削除するときに反復処理されます。Creator および Remover の値は、カスタム EntityPropertyManager の <ejb-ref-name> から ejb/ プレフィックスを削除したものと一致します。
<ejb-ref>
<ejb-ref-name>ejb/ProfileType/UUPExampleUser</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.usermgmt.profile.ProfileManagerHome</home>
<remote>com.bea.p13n.usermgmt.profile.ProfileManager</remote>
</ejb-ref>
<ejb-ref-name> は ejb/ProfileType/ で始まり、UserManager の createUser() メソッドの引数であるプロファイル タイプとして使用する名前で終わる必要があります。
<weblogic-enterprise-bean>
<ejb-name>MyProfileManager</ejb-name>
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>ejb/EntityPropertyManager</ejb-ref-name>
<jndi-name>${APPNAME}.BEA_personalization.EntityPropertyManager</jndi-name>
</ejb-reference-description>
<ejb-reference-description>
<ejb-ref-name>ejb/PropertySetManager</ejb-ref-name>
<jndi-name>${APPNAME}.BEA_personalization.PropertySetManager</jndi-name>
</ejb-reference-description>
<ejb-reference-description>
<ejb-ref-name>ejb/MyEntityPropertyManager</ejb-ref-name>
<jndi-name>${APPNAME}.BEA_personalization.MyEnitityPropertyManager</jndi-name>
</ejb-reference-description>
</reference-descriptor>
<jndi-name>${APPNAME}.BEA_personalization.MyProfileManager</jndi-name>
</weblogic-enterprise-bean>
カスタム EntityPropertyManager 用の <ejb-ref> を JNDI 名にマップする <ejb-reference-description> を作成する必要があります。この JNDI 名は、カスタム EntityPropertyManager の JAR ファイルの weblogic-ejb-jar.xml で割り当てた名前に一致する必要があります。
文字列置換変数 ${APPNAME} に注意してください。WebLogic Server EJB コンテナは、JNDI 名のスコープがエンタープライズ アプリケーションになるようにアプリケーション名を自動的に置き換えます。
<transaction-isolation>
<isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
<method>
<ejb-name>MyProfileManager</ejb-name>
<method-name>*</method-name>
</method>
</transaction-isolation>
<module>
<ejb>UUPExample.jar</ejb>
</module>
<Cache Name="UUPExampleCache" TimeToLive="60000"/>
変更した p13n_ejb.jar とカスタム EntityPropertyManager EJB の JAR アーカイブがエンタープライズ アプリケーションのルート ディレクトリにあることを確認し、WebLogic Server を起動します。
これで、新しい統合ユーザ プロファイルを使用する準備が整いました。WebLogic Administration Portal を使用してユーザを作成することができます。「UUPExample」プロパティ セットが変更されるときに UUP の実装が使用されます。UserManager デプロイメント記述子で ejb/ProfileType/UUPExampleUser という <ejb-ref> を使用して ProfileType をマップしたのは、この理由のためです。
次に、UserManager で createUser("bob", "password", "UUPExampleUser") を呼び出すと、次に示すいくつかの処理が行われます。
WebLogic Portal には、LDAP サーバからプロパティを取得するためのデフォルト統合ユーザ プロファイルが用意されています。LDAP サーバからプロパティを取得するための LDAP 統合ユーザ プロファイルを実装するには、ここに示す手順を実行します。
LdapRealm セキュリティ レルムと、LDAP からユーザ プロパティを取得するための LdapPropertyManager 統合ユーザプロファイル (UUP) は、互いに独立しています。両者はコンフィグレーション情報を共有せず、いずれか一方をもう一方と組み合わせて使用する場合の要件もありません。セキュリティ レルムはユーザ プロファイルとは無関係です。セキュリティ レルムはユーザとパスワードのデータ、ユーザとグループの関連付け、およびグループとグループの関連付けを提供します。ユーザ プロファイルはユーザとグループのプロパティを提供します。パスワードはプロパティではありません。
LDAP サーバからユーザ プロファイルを取得するには、次の手順を実行済みであることを確認してください。
<!-- Ldap Property Manager
To use this, uncomment it here as well as in weblogic-ejb-jar.xml. Configure the LDAP connection and settings using the env-entry values (see descriptions below).Do not forget to uncomment the ejb-link and method-permission tags for the LdapPropertyManager.An easy way to ensure you don't miss anything is to search for "ldap" (case-insensitive) here AND in weblogic-ejb-jar.xml. Search from the beginning to the end of the file.
-->
<!-- <ejb-link>LdapPropertyManager</ejb-link> -->
<ejb-link>EntityPropertyManager</ejb-link>
<!--
<method>
<ejb-name>LdapPropertyManager</ejb-name>
<method-name>*</method-name>
</method>
-->
<weblogic-enterprise-bean>
<ejb-name>LdapPropertyManager</ejb-name>
<enable-call-by-reference>True</enable-call-by-reference>
<jndi-name>${APPNAME}.BEA_personalization.LdapPropertyManager</jndi-name>
</weblogic-enterprise-bean>
<method>
<ejb-name>LdapPropertyManager</ejb-name>
<method-name>*</method-name>
</method>
LDAP サーバのプロパティを WebLogic Administration Portal に表示し、パーソナライゼーション、委託管理、および訪問者の資格に関するルールの定義に使用できるようにするには、ldap.usr と呼ばれるユーザ プロパティ セットを作成し、そのプロパティ セット内に、表示する LDAP プロパティと完全に一致する名前のプロパティを作成します。
p13n_ejb.jar 内の LdapPropertyManager EJB では、LDAP スキーマを調べることによって、多値 LDAP 属性と単値 LDAP 属性の判別、複数の userDN または groupDN の許可、および LDAP サーバ内のユーザとグループの SUBTREE_SCOPE 検索を実行できます。詳細は次のとおりです。
多値 LDAP 属性と単値 LDAP 属性の判別では、開発者は LdapPropertyManager EJB の ejb-jar.xml デプロイメント記述子をコンフィグレーションして、プロパティが単値か多値かを判別するときに LDAP スキーマが使用されるように指定できます。
ユーザとグループの SUBTREE-SCOPE を有効にするには、次の手順に従います。
<!-- Flag to specify if LDAP attributes will be determined to be single value
or multi-value via the schema obtained from the attribute.If false,
then the attribute is stored as multi-valued (a Collection) only if it has
more than one value.Leave false unless you intend to use multi-valued LDAP
attributes that may have only one value.Using true adds overhead to check
the LDAP schema.Also, if you use true beware that most LDAP attributes are
multi-value.For example, iPlanet Directory Server 5.x uses multi-value for
givenName, which you may not expect unless you are familiar with LDAP schemas.
This flag will apply to property searches for all userDNs and all groupDNs.-->
<env-entry>
<env-entry-name>config/detectSingleValueFromSchema</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>true</env-entry-value>
</env-entry>
<!-- Value of the name of the attribute in the LDAP schema that is used
to determine single value or multi-value (RFC2252 uses SINGLE-VALUE).
This attribute in the schema should be true for single value and false
or absent from the schema otherwise.The value only matters if
config/detectSingleValueFromSchema is true.-->
<env-entry>
<env-entry-name>config/singleValueSchemaAttribute</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>SINGLE-VALUE</env-entry-value>
</env-entry>
単値を持つ多値 LDAP 属性を使用したルールを記述する場合を除き、config/detectSingleValueFromSchema に true を設定することはお勧めしません。config/detectSingleValueFromSchema = true を使用すると、各属性の LDAP スキーマをチェックするオーバーヘッドが発生します。デフォルト (config/detectSingleValueFromSchema = false) では、属性が複数の値を持つ場合、属性は (Collection 内に) 多値として格納されるだけです。
この機能は、ユーザとグループに対して SUBTREE_SCOPE 検索を使用できる変更も実装します。また、複数のベース userDN と groupDN の指定も可能にします。複数のベース DN は、SUBTREE_SCOPE 検索が有効か無効かに関係なく使用できます。
SUBTREE_SCOPE 検索は、ベース userDN (または groupDN) から始まり、ユーザ名 (またはグループ名) と一致する最初のユーザ (またはグループ) が見つかるまで、そのベース DN のブランチを検索します。
SUBTREE_SCOPE 検索を有効にするには、p13n_ejb.jar.jar 内の ejb-jar.xml でブール設定の config/objectPropertySubtreeScope env-entry に true を設定し、config/userDN env-entry と config/groupDN env-entry の値が SUBTREE_SCOPE 検索を開始するベース DN と等しくなるように設定する必要があります。
たとえば、ou=PeopleA,ou=People,dc=mycompany,dc=com と ou=PeopleB,ou=People,dc=mycompany,dc=com にユーザが存在する場合、config/userDN に ou=People,dc=mycompany,dc=com を設定すれば、ユーザ検索は "People" ou から始まり、それぞれのブランチ (ou="PeopleA" と ou="PeopleB") に進み、これらのユーザのプロパティを LDAP サーバから取得できます。
LDAP サーバでは、ベース userDN (またはベース groupDN) のブランチに重複するユーザ (またはグループ) を作成しないでください。たとえば、LDAP サーバでは、uid="userA" のユーザを PeopleA ブランチと PeopleB ブランチの両方に作成できる場合があります。この場合、p13n_ejb.jar.jar の LdapPropertyManager は、最初に検索された userA のプロパティ値を返します。
SUBTREE_SCOPE 検索が提供する柔軟性が必要な場合を除き、この変更を有効にしない (config/objectPropertySubtreeScope に true を設定しない) ことをお勧めします。
SUBTREE_SCOPE 検索に代わる方法として、複数のベース DN をコンフィグレーションして、config/objectPropertySubtreeScope の設定は false のままにしておく方法があります (この方法は、ベース DN が複数かどうかには関係ありません)。ベース DN のブランチより下位は検索されないので、各ベース DN はユーザ (またはグループ) が格納されている DN である必要があります。検索は、最初に一致するユーザ (またはグループ) が見つかるまで、ベース DN 間を循環します。
新しい ejb-jar.xml デプロイメント記述子は詳細なコメント付きであり、複数の DN、複数の usernameAttribute (または groupnameAttribute)、および objectPropertySubtreeScope フラグの設定方法を説明しています。
![]() ![]() |
![]() |
![]() |