Creating and Managing Users

 

BEA WebLogic Personalization Server applications can store personal information about customers and display Web site content or offer other services based on customers' identities. For example, if you store information about the types of mutual funds in which your customer invests (conservative, moderate, aggressive), you can present content, advertisements, and additional fund recommendations that reflect each customer's preference.

The first sections of topic provide background information for the following WebLogic Personalization Server features:

• User and Group Profiles

• Security Realms and User Profiles

• Unified User Profiles

• Anonymous User Profiles

• Platform for Privacy Preferences Project (P3P)

The remaining sections provide instructions for creating and persisting data about your customers:

• Creating and Modifying Groups

• Creating and Modifying Users

• Accessing User and Group Data

• Setting Global Values for a Profile

• Accessing Properties from an LDAP Server

• Incorporating Data from Other External Sources

 

---

User and Group Profiles

A customer profile (or user profile) is a schema that determines which data you collect and store about a customer. Each piece of data in a customer profile is called a customer property. Customer properties can range from statically-defined properties, such as a user's social security number, to dynamically-created and persisted properties, such as Web-site tracking information for a particular user, or user preferences entered from a standard input screen.

Property Inheritance

User and group profiles can both inherit property values through the concept of a successor profile. If a property is requested from a profile, and no value is found for that property, the profile's successor will be queried for the profile. This process will be repeated recursively until either a value is found, or no more successors are found.

There are two types of successors: implicit and explicit.

An implicit successor is one that is set for a profile. For example, you can retrieve a user profile's ProfileWrapper object and call setSuccessor() on it, passing in a group name and a property set name. From that point on, that group will be used as a successor for the user profile when a property belonging to that property set is requested. A profile can have one implicit successor per property set, and one for the default, or null, property set. Properties that are set using a null property set name are are members of the default property set. To se an implicit successor for the default property set, you can call ProfileWrapper.setSuccessor() with null for the property set name argument.

Explicit successors are provided at the time of the property query, as an extra parameter to the getProperty() call. For example, calling getProperty("FooPropertySet", "Bar", "SomeGroup") on a user profile will look for the property called Bar in the FooPropertySet, then in the default property set, and if it is not found in either place it will retrieve the profile for the group called SomeGroup and repeat the search with that profile, and any of its implicit successors. Explicit successors will always be queried before implicit successors.

Users can only have groups as successors, and groups can only have other groups as successors. By default, when you add a group to a group, the parent becomes the child's implicit successor for the default property set. However, since users can belong to multiple groups, it is up to your application to decide which group to set as a user's successor.

The overall property search order, when getProperty( "Foo", "Bar", "SomeGroup" ) is called, is as follows:

1. Look for a property named "Bar" in the "Foo" property set in the current profile.

2. Look for a property named "Bar" in the default property set, in the current profile.

3. Look for a property named "Bar" in the "Foo" property set in the "SomeGroup" profile. (This will start the search recursively in the "SomeGroup" profile.)

4. If there is an implicit successor for the "Foo" property set, look for a property named "Bar" in the "Foo" property set in that successor's profile. (Again, this will start the search recursively in that profile.)

5. If there is an implicit successor for the default property set, look for a property named "Bar" in the "Foo" property set in that successor's profile. (Again, this will start the search recursively in that profile.)

6. If the property is still not found, return the default as defined in the "Foo" property set.

Property Sets and Profiles

User profiles use property sets to organize the properties that they contain. A property set is a convenient way to give a name to a group of properties for a specific purpose; a property set type establishes a set of expectations for how a property set is used.

The sample applications define a property set named CustomerProperties which belongs to the User Profile property set type. CustomerProperties contains around thirty properties for an e-commerce customer, such as First Name, Last Name, Home Phone, Email, and Customer Type.

You create property sets and property definitions in the E-Business Control Center. You use JSP tags, APIs, or other WebLogic Personalization Server services to set the value of a property. WebLogic Personalization Server does not support creating a new property set type.

For more information about property sets, see Creating and Managing Property Sets, in this guide.

 

---

Security Realms and User Profiles

A security realm determines how a user is authenticated and retrieves access control lists for given names. WebLogic Server supports several types of security realms for different environments and security needs.

The default WebLogic Personalization Server realm, wlcsRealm, stores and retrieves user IDs and passwords from the user profiles that are stored in the WebLogic Personalization Server RDMBS repository. (See Figure 8-1.)

Figure 8-1 wlcsRealm and User Properties

 

Alternate Security Realms and User Profiles

You can use other types of security realms to store and retrieve authentication data (user IDs, passwords, ACLs) in sources other than the RDBMS repository. For example, if you already have users and groups defined on a UNIX network, you can use the UNIX Security Realm to authenticate users and groups using UNIX login IDs and passwords.

For a list of the types of security realms that WebLogic Server supports, refer to "Security Fundamentals" in the WebLogic Server Programming WebLogic Security guide. Also refer to the WebLogic Portal Security Guide.

WebLogic Personalization Server provides two session beans, the UserManager and GroupManager, as a single point of entry for creating, editing, and removing user and group data. If you use an alternate security realm, methods in these beans act upon both the realm and the profile manager components to ensure that they stay synchronized.

For example, Figure 8-2 illustrates using the UserManager to create or remove users. A Personalization service uses UserManager to create user IDs and passwords in both the UNIX Realm and the user profile in the RDBMS data repository.

Figure 8-2 Synchronizing Security Realms and User Profiles

 

In general, if you are using APIs to manage user data, use the UserManager and GroupManager methods as opposed to manipulating the security realm directly.

If you use a read-only realm such as LDAP Realm, UserManager and GroupManager cannot create users and groups in the realm. Instead, WebLogic Personalization Server creates user profiles for users and groups from the read-only realm on-the-fly. For example, if a user "joe" exists in your LDAP server and you are running the LDAP realm, the first time Joe's user profile is requested, the UserManager will see that the profile does not exist. It will then verify that Joe exists as a user in the LDAP realm, and will create a new profile record at that point and return it.

If you use a third-party tool to manage user records in an alternate security realm (such as the administration tool that comes with an LDAP server), the UserManager has no way to know when users and groups are removed from the realm. This can result in profile records that belong to users and groups that no longer exist. The User Management Administration Tools provide a means to clean up these leftover records. See the section Deleting User Records That Do Not Exist in the Realm from the Personalization Database.

 

---

Unified User Profiles

WebLogic Personalization Server provides the ability to combine user properties from the WebLogic Personalization Server RDBMS repository with user properties from other data sources, such as an LDAP server into a single Unified User Profile (UUP). With the UUP, developers and system users need not worry about the different underlying data sources of user data. To them there is just one place to go for user information-the user profile. (See Figure 8-3.)

Figure 8-3 UUP That Combines Several Data Sources

 

For information on setting up a Unified User Profile that gathers user properties from an LDAP server, refer to Accessing Properties from an LDAP Server. For information on gathering user properties from other data sources, refer to Incorporating Data from Other External Sources.

 

---

Anonymous User Profiles

Certain scenarios require an unidentified user to be able to use a system. While the unidentified user is using the system, you may need to have a profile for that user in order to set and get properties. For instance, a portal Web site might want to let new users tour the Web site and configure a few things before they actually have an official login name and password. The anonymous user profile allows for a user profile to be created for such a user.

An anonymous user profile can be treated just like a user profile for a known user, but the anonymous user profile only lives for the life of the user session. If the session is terminated without capturing an identity for the user, any profile information accumulated during the life of the anonymous user profile is lost. An anonymous user profile has no successor and will not retrieve default property values from a Property Set.

The anonymous user profile is available only through JSP tags. An anonymous profile is created when a <um:setProperty> or <um:getProperty> JSP tag is used before a <um:getProfile> tag has been called. If during a session a persistent user profile is created for the anonymous user, the <um:createUser> tag can be told to store the values from the anonymous profile into the new user profile. This is done with the saveAnonymous tag parameter set to true, as in:
<um:createUser saveAnonymous="true">.

Note: Campaigns cannot be used with anonymous users. Campaigns require a user ID that has two characteristics: the ID must be associated with a user profile, and that user profile must be saved (persisted). However, the anonymous profile for a user who is not logged in is a runtime profile (not saved), and not associated with a user ID.

Personalization features such as <pz:div> and <pz:contentSelector> JSP tags do work for anonymous users. This is because these features can use a runtime profile without a user ID.

For more information on these tags, see the section "User Management JSP tags" in Personalization Server JSP Tag Library Reference, in this guide.

 

---

Platform for Privacy Preferences Project (P3P)

The Platform for Privacy Preferences Project (P3P) is an emerging industry standard that is designed to provide an automated way to compare consumers' privacy preferences with the privacy practices of the Web sites they visit. It lets Web sites express their privacy practices in a format that can be retrieved automatically and interpreted easily.

The P3P is a work-in-progress by the World Wide Web Consortium (W3C), a global group drawn from industry, academia, and privacy groups as well as public policy organizations. For more information about the World Wide Web Consortium's ongoing P3P effort, visit the P3P site at http://www.w3.org/P3P.

Essentially, P3P compliance means that your Web site presents a privacy policy to the user. As put forth in the P3P specification, a privacy policy is a set of one or more privacy statements that describe what personal user data a Web site will retrieve, and how the data is to be used. The P3P specification currently defines three mechanisms by which a Web site's privacy policy information can be presented to the end user:

• By publishing the policy reference file at a well-known URL.
  For complete information, see the P3P specification, section 2.2.1. http://www.w3.org/TR/P3P/#mechanism_ref

• By injecting a special header in each HTTP response served up by the Web server. For complete information, see the P3P specification, section 2.2.2. http://www.w3.org/TR/P3P/#syntax_ext

• By using an embedded <link> tag in the body of an HTML page.
  For complete information, see the P3P specification, section 2.2.3. http://www.w3.org/TR/P3P/#syntax_link

BEA Systems applauds the efforts of the World Wide Web Consortium and other organizations around the world working to empower users to control the use of their personal information on the Web sites they visit. However, it is important to note that WebLogic Personalization Server does not in any way enforce P3P compliance-that option is left up to the Web site developer.

 

---

Creating and Modifying Groups

This section describes using the WebLogic Portal Administration Tools to complete the following tasks:

• Creating Groups

• Adding Users to Groups

• Removing Users from Groups

• Editing Group Property Values

• Deleting Groups

For information on using JSP tags or APIs to create and modify groups, refer to Personalization Server JSP Tag Library Reference, and to the Javadoc API documentation for the UserManager and GroupManager EJBs.

Creating Groups

Note: The User Management tools do not allow the creation of a group called "everyone," because this is a reserved WebLogic Server group name.

To create groups:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon.

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. On the WebLogic Portal Administration Tools page, click the User Management icon. The User Management Home page appears. (See Figure 8-4.)

   Figure 8-4 User Management Administration Tools Home Page

   
    
    

3. On the User Management Home page, click Create in the Groups banner. The Groups page appears. (Figure 8-5)

   Figure 8-5 The Create a Group Page

   
    

4. Within the Group Hierarchy tree view, expand the hierarchy as needed to display the add icon (+) at the level you wish to add the group. (Figure 8-6)

   Figure 8-6 Expand the Group Hierarchy To Display the Add Icon (+)

   
    

5. Click on the plus sign. The Create a Group page appears.

6. Enter the name of the new group in the Group Name field. (Figure 8-7)

   Figure 8-7 Enter the Name of the New Group

   
    

7. Click Create. A success or failure message appears.

8. Click Back to return to the Create a Group page, or click Create to enter another new group name at the same level (step 6.)

9. On the Create a Group page, click Finished to return to the User Management Home Page.

After you create a group, you can then personalize it by overriding the default property values. (The default property values are set up in the E-Business Control Center. For more information, see Creating and Managing Property Sets, in this guide.)

Adding Users to Groups

To add users to groups:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon.

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. On the WebLogic Portal Administration Tools page, click the User Management icon. The User Management Home page appears. (See Figure 8-4.)

3. On the User Management Home page, click Groups in the Groups banner. The Search for a Group page appears. (Figure 8-8)

   Figure 8-8 Search for a Group Page

   
    

4. To locate the appropriate group, do one of the following:

   1. To locate the group by name, enter the group name in the Group Name field, then click Search.

   2. To locate the group within the Group Hierarchy, navigate the Group Hierarchy tree view.

5. Select the group. The Group Properties view appears. (Figure 8-9)

   Figure 8-9 Group Properties View

   
    

6. Click the add/remove icon (+/-) at the bottom of the page. The Add/Remove Users tool appears. (Figure 8-10)

   Figure 8-10 Add/Remove Users Page

   
    

   To locate a user, do one of the following:

   1. To locate the user by name, enter the username in the Username field, then click Search. The search results appear at the bottom of the page.

   2. To see a list of all users within an alphabetized category, click the appropriate letter corresponding to the first letter of the username. A list of users appear at the bottom of the page.

   3. To see a list of all users in the database, use the wildcard feature. Enter a partial username immediately followed by an asterisk (*). The asterisk is a search return variable.

Note: Only users already entered in the database are available in these lists. To add new users to the database, see Creating Users.

1. Select the username, or a group of names, from the Search Results field. (Figure 8-11)

   Figure 8-11 Use Left-Arrow to Move User Names into a Group

   
    

2. Click the left-to-right directional arrow. The username(s) appears in the Group Search Results field.

3. Click Save to commit the selected name(s) to the Group. You must click Save before beginning a new search.

4. Click Back to return to the Group Properties view.

Note: The search applies to both list boxes.

Removing Users from Groups

To remove users from groups:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon.

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. On the WebLogic Portal Administration Tools page, click the User Management icon. The User Management Home page appears. (See Figure 8-4.)

3. On the User Management Home page, click Groups in the Groups banner. The Search for a Group page appears. (Figure 8-8)

   To locate the appropriate group, do one of the following:

   1. To locate the group by name, enter the group name in the Group Name field, then click Search.

   2. To locate the group within the Group Hierarchy, navigate the Group Hierarchy tree view.

4. Select the group. The Group Properties view appears. (Figure 8-9)

5. Click the add/remove icon (+/-) at the bottom of the page. The Add/Remove Users tool appears. (Figure 8-10)

   To locate a user, do one of the following:

   1. To locate the user by name, enter the username in the Username field, then click Search. The search results appear at the bottom of the page.

   2. To see a list of all users within an alphabetized category, click the appropriate letter corresponding to the first letter of the username. A list of users appear at the bottom of the page.

   3. To see a list of all users in the database, use the wildcard feature. Enter a partial username immediately followed by an asterisk (*). The asterisk is a search return variable.

6. Select the username, or a group of usernames, from the Group Search Results field. (Figure 8-12)

   Figure 8-12 Use Right-Arrow to Move Usernames Out of a Group

   
    

7. Click the right-to-left directional arrow. The username(s) is removed from the Group Users field and appears in Search Results.

8. Click Save to remove the username(s) from the Group.

9. Click Back to return to the Group Properties view.

Editing Group Property Values

To edit group property values:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon.

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. On the WebLogic Portal Administration Tools page, click the User Management icon. The User Management Home page appears. (See Figure 8-4.)

3. On the User Management Home page, click Groups in the Groups banner. The Search for a Group page appears. (Figure 8-8)

   To locate the appropriate group, do one of the following:

   1. To locate the group by name, enter the group name in the Group Name field, then click Search.

   2. To locate the group within the Group Hierarchy, navigate the Group Hierarchy tree view.

4. Select the group. The Group Properties view appears. (Figure 8-9)

5. Select or search for a property set to view for this group. The group's default property values appear if no other property set has been accessed during the tools session.

Note: Default property values are created using the E-Business Control Center. For specific instructions on property set management, see Creating and Managing Property Sets.

1. Click Search. The Edit Default Properties page appears. (Figure 8-13)

   Figure 8-13 Edit Default Properties Page

   
    

2. Click Edit on the appropriate Property bar. The associated Edit Property Values page appears. (Figure 8-14)

   Figure 8-14 Edit Property Values Page

   
    

3. Change the values on the Edit Property Values page.

Note: Non-default property sets and properties that were not configured through the Site Infrastructure tab in the E-Business Control Center are not editable here.

1. Click Save.

2. Click Back to return to the Group Properties view.

3. To edit other properties, return to step 5.

4. If you click the Reset button on the Property bar (instead of Edit as we did in step 7.), the property is set to null for that user. This will have one of three results:

   • First, if the property has a default value, the group will have that default value. Note that the default value is not copied into the group's settings. The group's value is just set to null so that the default value will be returned when getProperty() is called for that property. If the default value changes, calling getProperty() will return the new default value.

   • Second, if the property is defined in a Property Set but does not have a default value, the user will have a null for that property.

   • Third, if the property was dynamically defined (that is, it does not belong to a Property Set), resetting causes that property to be deleted.

Deleting Groups

To delete groups:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon.

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. On the WebLogic Portal Administration Tools page, click the User Management icon. The User Management Home page appears. (See Figure 8-4.)

3. On the User Management Home page, click Groups in the Groups banner. The Search for a Group tool appears. (Figure 8-15)

   Figure 8-15 Search for a Group To Delete

   
    

   1. To locate the group to delete by name, enter the group name in the Group Name field, then click Search. The group name must be entered exactly.

   2. To locate the group to delete within the Group Hierarchy, navigate the Group Hierarchy tree view.

4. Click the X to the right of the group name.

5. A confirmation box appears. (Figure 8-16)

   Figure 8-16 Confirmation Box: Group Successfully Deleted

   
    

6. Click Finished to return to the User Management Home Page.

 

---

Creating and Modifying Users

This section describes using the WebLogic Portal Administration Tools to complete the following tasks:

• Creating Users

• Editing User Property Values

• Deleting Users

• Deleting User Records That Do Not Exist in the Realm from the Personalization Database

For information on using JSP tags or APIs to create and modify users, refer to Personalization Server JSP Tag Library Reference, and to the Javadoc API documentation for the UserManager and GroupManager EJBs.

For information on how customers can create and modify their own user profiles, refer to the Guide to Registering Customers and Managing Customer Services.

Creating Users

Note: The administration tools do not allow the creation of a user with username "system" or "guest", as these are reserved WebLogic Server terms.

To create users:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon. (See Figure 8-17.)

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

   Figure 8-17 User Management Icon on the WebLogic Portal Administration Tools

   
    

2. The User Management Home page appears. (Figure 8-18)

   Figure 8-18 User Management Home Page

   
    

3. On the User Management Home page, click Create in the Users banner. The Create New Users page appears. (Figure 8-19)

   Figure 8-19 Create New Users Page

   
    

4. Enter the username in the Username field.

   Note: Limit username to 25 characters.

5. Enter the password associated with the Username in the Password field.

6. In the Verify Password field, re-enter the password provided in step 5.

   Note: Characters in password fields appear as asterisks.

7. From the User Type list, select a profile type. The user will be an instance of this profile type. This allows the system to access explicit properties in a Unified Profile type, and ensures proper data cleanup when the user is removed.

8. Click Create. The new user appears at the bottom of the page.
   Alternatively, click Back to return to the User Management Home page without creating the new user.

Note: The WLCS RDBMSrealm allows mixed case user creation. (For example: User, user.)

After you create a user, you can then personalize it by overriding the default property values. (The default property values are set up in the E-Business Control Center. For more information, see Creating and Managing Property Sets, in this guide.)

Editing User Property Values

Note: Explicit properties of UUP are only editable from the administration tools if a property set is created that mirrors those properties.

To edit user property values:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon. (See Figure 8-17.)

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. The User Management Home page appears. (Figure 8-18)

3. On the User Management Home page, click Users in the Users banner. The Search for a User tool appears. (Figure 8-20)

   Figure 8-20 Search for a User

   
    

   To locate a user, do one of the following:

   1. To locate the user by name, enter the username in the Username field, then click Search. The search results appear at the bottom of the page.

   2. To see a list of all users within an alphabetized category, click the appropriate letter corresponding to the first letter of the username. A list of users appear at the bottom of the page.

   3. To see a list of all users in the database, use the wildcard feature. Enter a partial username immediately followed by an asterisk (*). The asterisk is a search return variable.

4. Select the user. The User Property view appears.

5. In the drop-down list, select a property set to view for this user.

Note: Default property values are created using the E-Business Control Center. For specific instructions on property set management, see Creating and Managing Property Sets.

1. Click Search. The User Properties view appears. (Figure 8-21)

   Figure 8-21 User Properties View

   
    

2. Click Edit on the appropriate Property bar. The associated Edit Property Values page appears. (Figure 8-22)

   Figure 8-22 Edit Property Values

   
    

3. Change the user's values at the Edit Property Values page.

4. Click Save. A message appears indicating whether or not the edit was successful. Alternatively, click Back to return to the User Properties view without saving your changes.

5. Click Back to return to the User Properties view.

6. Return to step 4 and edit other properties as necessary.

Note: If you click the Reset button on the Property bar (instead of Edit as we did in step 6), the property is set to null for that user. This will have one of three results:

• First, if the property has a default value, the user will have that default value. Note that the default value is not copied into the user's settings. The user's value is just set to null so that the default value will be returned when getProperty() is called for that property. If the default value changes, calling getProperty() will return the new default value.

• Second, if the property is defined in a Property Set but does not have a default value, the user will have a null for that property.

• Third, if the property was dynamically defined (that is, it does not belong to a Property Set), resetting causes that property to be deleted.

Deleting Users

To delete users:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon. (See Figure 8-17.)

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. The User Management Home page appears. (Figure 8-18)

3. On the User Management Home page, click Users in the Users banner. The Search for a User tool appears. (Figure 8-23)

   Figure 8-23 Search for a User to Delete

   
    

   To locate a user, do one of the following:

   1. To locate the user by name, enter the username in the Username field, then click Search. The search results appear at the bottom of the page.

   2. To see a list of all users within an alphabetized category, click the appropriate letter corresponding to the first letter of the username. A list of users appear at the bottom of the page.

   3. To see a list of all users in the database, use the wildcard feature. Enter a partial username immediately followed by an asterisk (*). The asterisk is a search return variable.

4. Click the X to right of the username to delete the user. A confirmation dialog box appears.

5. Click OK to confirm the deletion and return to the Search for Users page.

Deleting User Records That Do Not Exist in the Realm from the Personalization Database

When users are deleted from the realm, they might leave behind orphan profile records in your personalization database. This will only happen if the users are deleted directly from the realm, and not through the UserManager session bean. For example, a user might be deleted from an LDAP realm through the LDAP server's admin tool. To delete user profile records that no longer exist in the realm from the Personalization database:

1. Start the WebLogic Portal Administration Tools for your application. On the Administration Tools home page, click the User Management icon. (See Figure 8-17.)

   For more information, see "WebLogic Portal Administration Tools" in the WebLogic Portal Architectural Overview.

2. n the User Management Home page, click Realm in the Realm banner. The Realm Configuration window appears. (Figure 8-24)

   Figure 8-24 The Realm Configuration Window

   
    

3. Two banners, Groups and Users, are displayed.

4. Click the Cleanup button on the Users banner for a count of orphaned user profile records and an opportunity to delete them.

5. Click the Cleanup button on the Groups banner for a count of orphaned group profile records and an opportunity to delete them. (Figure 8-25)

   Figure 8-25 The Realm Window Offers An Opportunity to Clean Up Orphans

   
    

6. When finished, click Back to return to the Realm Configuration window.

7. Click Finished, to return to the User Management Administration Tools Home page.

 

---

Accessing User and Group Data

Some WebLogic Personalization Server services, such as content selectors, access user and group data without requiring your intervention. If your business needs require additional use of your user and group data, you can do the following:

• Use JSP Tags to Access User and Group Data

• Use APIs to Access User and Group Data

Use JSP Tags to Access User and Group Data

WebLogic Personalization Server provides JSP tag libraries that you can use to access user and group profile information, as well as create and delete users and groups, and manage user-group relationships.

For a complete list of user and group management JSP tags, refer to Personalization Server JSP Tag Library Reference.

Use APIs to Access User and Group Data

The UserManager and GroupManager session EJBs provide user management functionality in a WebLogic Personalization Server-specific context. Services provided by the EJBs include:

• Creating/removing users

• Creating/removing groups

• Adding users to groups/removing users from groups

• Adding groups to groups/removing groups from groups

• Retrieving usernames corresponding to a group

• Retrieving group names corresponding to a user

For a complete list of UserManager and GroupManager services, see the UserManager and GroupManager Javadoc API documentation.

As discussed in Alternate Security Realms and User Profiles, the UserManager and GroupManager are intended as a single entry point to both the security realm and the personalization database. All methods on these session beans delegate to either the realm, the profile components, or both when appropriate. This enables the developer to use a custom security realm implementation and have it integrate seamlessly with the WebLogic Personalization Server.

In addition to UserManager and GroupManager, you can instantiate and use the lightweight ProfileWrapper object to access a user or group profile. A ProfileWrapper can access the correct ProfileManager session bean(s) based on the identity it was initialized with. If it was initialized with both a user and group name, the group will be used as an explicit successor for all getProperty methods that do not take an explicit successor. For more information about ProfileWrapper, refer to the Javadoc API documentation.

 

---

Setting Global Values for a Profile

Profile properties can also belong to the "default", or null, property set, by passing in a null value when setting the property. Doing this will mean that the property cannot be validated or recognized by the E-Business Control Center, but it provides a way to set global values for a profile. When a property is requested, the profile first looks for a value with that name in the given property set, and if it is not found, it looks in the default property set. For example, a user profile can have the property Age defined in the default property set, and as long as there is no property called Age in another property set, calling getProperty(x, "Age") will always return that value for any property set x.

 

---

Accessing Properties from an LDAP Server

The WebLogic Portal sample applications include a default property set named "ldap," which can retrieve properties from an LDAP server. Before you use this property set with the sample applications or with your own application, you must do the following:

1. If you have already deployed the application on a WebLogic Portal instance, stop the server.

2. Deploy the ldapprofile.jar component within your application as described in "Add JAR Files" under "Assembling and Deploying Enterprise Applications" in the Deployment Guide.

3. Start the server and deploy the application.

4. Start the WebLogic Server Administration Console for the active domain, and do the following:

   1. In the left pane, click Deployments --> EJB --> ldapprofile.

   2. Right-click this node.

   3. Select Edit Descriptor.

   4. When the descriptor comes up in a new window, navigate to ldapprofile.jar --> EJB Jar --> Enterprise Beans --> Sessions --> LdapPropertyManager --> Env Entries.

5. This will list the connection variables, and their default values as shown in Table 8-15. You will need to edit these values to match your LDAP server's configuration.

   Table 8-15 Edit These Values to Match Your LDAP Server's Configuration

   Connection Variables	Description
   config/serverURL	The URL of your LDAP server.
   config/principal	The name of the principal to use when connecting to your LDAP server, usually "admin" or something similar.
   config/principalCredential	The Password of the principal defined above.
   config/userDN	The location of users in your LDAP directory.
   config/groupDN	The location of groups in your LDAP directory
   config/usernameAttribute	The attribute used to describe usernames in your LDAP directory, usually "uid". This will be used to map WLS usernames to LDAP usernames.
   config/groupnameAttribute	The attribute used to describe group names in your LDAP directory, usually "cn". This will be used to map WLS group names to LDAP group names.

   
    

6. After editing these values, persist them by navigating to the root ldapprofile.jar node and clicking Persist.

7. Restart the server.

 

---

Incorporating Data from Other External Sources

This section describes how to create a Unified User Profile that incorporates user data from external data sources in addition to or instead of LDAP servers, such as a legacy system or another database (See Figure 8-3).

This section includes the following subsections:

• How WebLogic Portal Retrieves User Data from External Sources

• Configuring WebLogic Portal To Retrieve User Data from External Sources

Note: If you want to incorporate user data only from an LDAP server, you do not need to complete the steps in this section. Instead, refer to Accessing Properties from an LDAP Server.

Unified User Profile Security

A Unifed User Profile is not a custom WebLogic security realm. User passwords are set in the WebLogic security realm, not in the user profile with other user properties. When UserManager.setPassword() is called, it delegates to the WebLogic security realm, not to a ProfileManager. However, the Unified User Profile and the WebLogic security realm are closely associated, because the UserManager is the synchronization point between the Unified User Profile and the WebLogic security realm. For example, the UserManager.createUser() method delegates to the security realm to create the user there, and then to a ProfileManager to create the user profile using the createUniqueId() method of one or more EntityPropertyManagers. All user management operations should be performed through the UserManager instead of directly through the security realm in order to keep the security realm and the user profile in sync.

See UserManager in the WebLogic Portal Javadoc at http://download.oracle.com/docs/cd/E13218_01/wlp/docs40/interm/javadoc.htm.

For information on writing a custom security realm, go to http://download.oracle.com/docs/cd/E13222_01/wls/docs61/security/prog.html#1041025.

How WebLogic Portal Retrieves User Data from External Sources

This section provides background information for completing the tasks that are described in Configuring WebLogic Portal To Retrieve User Data from External Sources.

To retrieve user data from a non-LDAP, external source, WebLogic Portal does the following (See Figure 8-26):

1. A JSP tag, API, or WebLogic Portal service invokes the ProfileFactory and passes a user ID as a parameter. The ProfileFactory returns a ProfileWrapper object for the user.

   ProfileWrapper is a lightweight object that is used to access a user or group profile. For more information, refer to the Javadoc API documentation.

   For example, you use the PostLoginProcessor Webflow component to retrieve user information on a specific JSP. When a customer accesses the JSP, PostLoginProcessor invokes the ProfileFactory.

   See "Initializing the Customer Profile" in the Guide to Developing Campaign Infrastructure.

2. The JSP tag, API, or WebLogic Portal service calls the getProperty("propertySet", "propertyName") method of the ProfileWrapper.

3. ProfileWrapper calls the getUserProfileManager method of the UserManager.

   UserManager is the synchronization point between user profile support and the WebLogic Server security realm. The UserManager handles user creation and deletion by delegating to various ProfileManagers. The UserManager has a registry of ProfileTypes that map a ProfileType name to a particular deployment of a ProfileManager. For more information about the Java objects, refer to the Javadoc API documentation.

   The getUserProfileManager method does the following:

   1. Retrieves the user's type from the WebLogic Portal RDBMS repository.

      You can specify a user's type when you create a user, (the createUser() method takes a user type as a parameter), and WebLogic Portal stores the type designation in its RDBMS repository. After you create a user, you cannot change the type.

   2. Looks in the UserManager deployment descriptor to find a ProfileManager that corresponds to the user type. If the user does not have a type, UserManager returns the default ProfileManager.

   3. Returns a ProfileManager.

      ProfileManager is a stateless session bean used to access profile values. It coordinates property inheritance and the mapping of properties to different data sources.

      UserManager and ProfileManager are both configurable through deployment descriptors: you should never have to modify/extend them by writing code.

4. ProfileWrapper calls the getProperty("propertySet", "propertyName", "username") method of the ProfileManager from the previous step.

   The getProperty method does the following:

   1. Looks in the ProfileManager deployment descriptor for an EntityPropertyManager mapping that matches the propertySet/propertyName. If there is no such mapping, it looks for a mapping that matches the propertySet. If there is no such mapping, it finds the default EntityPropertyManager.

   2. Returns an EntityPropertyManager.

      EntityPropertyManager is responsible for reading/writing properties to/from a datasource.

5. The EntityPropertyManager retrieves the property from its data source.

6. EntityPropertyManager returns the value to ProfileManager, which returns it to ProfileWrapper, which returns it to the client. If the EntityPropertyManager returns null, the ProfileManager invokes successor searches (described in Property Inheritance).

7. If the successor searches return null, the PropertySetManager is used to get the default value for the property for the given property set. The PropertySetManager returns the value to the ProfileManager, which returns it to the ProfileWrapper, which returns it to the client.

   Note: You should use the WebLogic Portal Administration Tools to create a property set definition containing your UUP properties. This UUP property set can be used to provide default property values-default properties that are also required by the Portal personalization tools. For example, the tool for creating customer segments needs to know which properties (and which types of properties) are available for defining a customer segment.

   Figure 8-26 How WebLogic Portal Retrieves Data From an External Source

   
    

Note: The retrieval of default property values from the property set metadata in the portal schema is not shown in this figure.

A Unified User Profile is not a custom WebLogic security realm. For information on Unified User Profile security, see Unified User Profile Security.

Configuring WebLogic Portal To Retrieve User Data from External Sources

To retrieve user data from external sources, complete the following tasks:

1. Create an EntityPropertyManager EJB to Represent External Data

2. Deploy a ProfileManager That Can Use the New EntityPropertyManager

Create an EntityPropertyManager EJB to Represent External Data

To incorporate data from an external source, you must first create a stateless session bean that implements the methods of the com.bea.p13n.property.EntityPropertyManager remote interface. EntityPropertyManager is the remote interface for a session bean that handles the persistence of property data and the creation and deletion of profile records if appropriate.

In addition, the stateless session bean should include a home interface and an implementation class. For example:

MyEntityPropertyManager
extends com.bea.p13n.property.EntityPropertyManager

MyEntityPropertyManagerHome
extends com.bea.p13n.property.EJBHome

Your implementation class can extend the EntityPropertyManagerImpl class. However the only requirement is that your implementation class is a valid implementation of the MyEntityPropertyManager remote interface. For example:

MyEntityPropertyManagerImpl extends
com.bea.p13n.property.internal.EntityPropertyManagerImpl

or

MyEntityPropertyManagerImpl extends
javax.ejb.SessionBean

We recommend the following guidelines for your new EJB:

• Your custom EntityPropertyManager is not a default EntityPropertyManager. A default EntityPropertyManager is used to get/set/remove properties in the Portal schema. Your custom EntityPropertyManager does not have to support the following methods. It can throw java.lang.UsupportedOperationException instead:

  getDynamicProperties

  getEntityNames

  getHomeName

  getPropertyLocator

  getUniqueId

• If you want to be able to use the Portal framework and tools to create and remove users in your external data store then you must support the createUniqueId() and removeEntity() methods. However, your custom EntityPropertyManager is not the default EntityPropertyManager so your createUniqueId method does not have to return a unique number. It must create the user entity in your external data store and then it can return any number, such as -1.

• The following recommendations apply to the EntityPropertyManager methods that you must support:

  getProperty() - Use caching. You should support the getProperties method to retrieve all properties for a user at once, caching them at the same time. Your getProperty method should use getProperties.

  setProperty() - Use caching.

  removeProperties(), removeProperty() - After these methods are called then a call to getProperty should return null for the property. Remove properties from the cache too.

• Your implementations of the getProperty(), setProperty(), removeProperty(), and removeProperties() methods must include any logic necessary to connect to the external system.

• If you want to cache property data, the methods must be able to cache profile data appropriately for that system. (See the com.bea.p13n.cache package.)

• If the external system contains read-only data, any methods that modify profile data must throw a java.lang.UnsupportedOperationException. Additionally, if the external data source contains users that are created and deleted by something other than WebLogic Personalization Server, your createUniqueId and removeEntity methods can simply throw an UnsupportedOperationException.

• To avoid class loader dependency issues, make sure that your EJB resides in its own package.

• For ease of maintenance, place the compiled classes of your custom EntityPropertyManager bean in your own JAR file (instead of modifying an existing WebLogic Portal JAR file).

Before you deploy your JAR file, follow the steps in the next section.

Deploy a ProfileManager That Can Use the New EntityPropertyManager

A "user type" is a mapping of a ProfileType name to a particular ProfileManager. This mapping is done in the UserManager EJB deployment descriptor.

To access the data in your new EntityPropertyManager EJB, you must do one of the following:

• In most cases you will be able to use the default deployment of ProfileManager, the UserProfileManager. You will modify the UserProfileManager's deployment descriptor to map a property set and/or properties to your custom EntityPropertyManager. If you support the createUniqueId() and removeEntity() methods in your custom EntityPropertyManager, you can use WebLogic Portal Administration Tools to create a user of type "User" with a profile that can get/set properties using your custom EntityPropertyManager. For more information, refer to Modifying the Existing ProfileManager Deployment Configuration.

• In some cases you may want to deploy a newly configured ProfileManager that will be used instead of the UserProfileManager. This new ProfileManager is mapped to a ProfileType in the deployment descriptor for the UserManager. If you support the createUniqueId() and removeEntity() methods in your custom EntityPropertyManager, you can use the WebLogic Portal Administration Tools (or API) to create a user of type "MyUser" (or whatever you name it) that can get/set properties using the customized deployment of the ProfileManager that is, in turn, configured to use your custom EntityPropertyManager. For more information, refer to Configuring and Deploying a New ProfileManager.

ProfileManager is a stateless session bean that manages access to the profile values that the EntityPropertyManager EJB retrieves. It relies on a set of mapping statements in its deployment descriptor to find data. For example, the ProfileManager receives a request for the value of the DateOfBirth property, which is located in the PersonalData property set. ProfileManager uses the mapping statements in its deployment descriptor to determine which EntityPropertyManager EJB contains the data.

Modifying the Existing ProfileManager Deployment Configuration

If you use the existing UserProfileManager deployment to manage your user profiles, perform the following steps to modify the deployment configuration.

Under most circumstances, this is the method you should use to deploy your UUP. An example of this method is the deployment of the custom EntityPropertyManager for LDAP property retrieval, the LdapPropertyManager. The classes for the LdapPropertyManager are packaged in ldapprofile.jar. (See Accessing Properties from an LDAP Server.) The deployment descriptor for the UserProfileManager EJB is configured to map the "ldap" property set to the LdapPropertyManager. The UserProfileManager is deployed in usermgmt.jar.

1. Back up the usermgmt.jar file in your enterprise application root directory.

2. From usermgmt.jar, extract META-INF/ejb-jar.xml and open it for editing.

3. In ejb-jar.xml, find the following element:

   <!-- 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>

   and add an <env-entry> element after this to map a property set to your custom EntityPropertyManager like this:

   <!-- 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>

4. In ejb-jar.xml, find the following element:

   <!-- 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>

   and add a <ejb-ref> element after this to map a reference to an EJB that matches the name from the previous step with ejb/ prepended like this:

   <!-- 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>

   The home and remote class names match the classes from your EJB JAR file for your custom EntityPropertyManager.

5. If your EntityPropertyManager implementation handles creating and removing profile records, you must also add Creator and Remover entries. For example:

   <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>

   This instructs the UserProfileManager to call your custom EntityPropertyManager when creating or deleting user profile records. The names "Creator1" and "Remover1" are arbitrary. All Creators and Removers will be iterated through when the UserProfileManager creates or removes a user profile. The value for the Creator and Remover matches the ejb-ref-name for your custom EntityPropertyManager without the ejb/ prefix.

6. From usermgmt.jar, extract META-INF/weblogic-ejb-jar.xml and open it for editing.

7. In weblogic-ejb-jar.xml, find the following elements:

   <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>

   and add an ejb-reference-description to map the ejb-ref for your custom EntityPropertyManager to the JNDI name. This JNDI name must match the name you assigned in weblogic-ejb-jar.xml in the JAR file for your customer EntityPropertyManager. It should look like this:

   <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>

   Note the ${APPNAME} string substitution variable. The WebLogic EJB container automatically substitutes the enterprise application name to scope the JNDI name to the application.

8. Update usermgmt.jar for your new deployment descriptors. You can use the jar uf command to update the modified META-INF/ deployment descriptors.

9. Edit META-INF/application.xml for your enterprise application to add an entry for your custom EntityPropertyManager EJB module like this:

   <module>

     <ejb>UUPExample.jar</ejb>

   </module>

10. If you are using an application-wide cache, you can manage it from the WebLogic Server Administration Console if you add a <Cache> tag for your cache to the META-INF/application-config.xml deployment descriptor for your enterprise application like this:

    <Cache

      Name="UUPExampleCache"

      TimeToLive="60000"

    />

    For information on using com.bea.p13n.cache.Cache, see "Using Caches" in the Performance Tuning Guide.

11. Verify the modified usermgmt.jar and your custom EntityPropertyManager EJB JAR archive are in the root directory of your enterprise application and start your server.

12. Use the WebLogic Server Administration Console to verify your EJB module is deployed to the enterprise application and then use the console to add your server as a target for the EJB module. You need to select a target to have your domain's config.xml file updated to deploy your EJB module to the server.

13. Use the E-Business Control Center to create a User Profile (property set) that matches the name of the property set that you mapped to your custom EntityPropertyManager in ejb-jar.xml for the UserProfileManager (in usermgmt.jar). You could also map specific property names in a property set to your custom EntityPropertyManager.

    Note: Be sure to synchronize the new data to your server after the property set is created.

14. Your new Unified User Profile type is ready to use. You can use the WebLogic Portal Administration Tools to create a user of type "User," and it will use your UUP implementation when the "UUPExample" property set is being modified. When you call createUser("bob", "password") or createUser("bob", "password", null) on the UserManager, several things will happen:

    • A user named "bob" is created in the security realm.

    • A WebLogic Portal Server profile record is created for Bob in the WebLogic Portal RDBMS repository.

    • If you set up the Creator mapping, the UserManager will call the default ProfileManager deployment (UserProfileManager) which will call your custom EntityPropertyManager to create a record for Bob in your data source.

    • Retrieving Bob's profile will use the default ProfileManager deployment (UserProfileManager), and when you request a property belonging to the "UUPExample" property set, the request will be routed to your custom EntityPropertyManager implementation.

Configuring and Deploying a New ProfileManager

If you are going to deploy a newly configured ProfileManager instead of using the default ProfileManager (UserProfileManager) to manage your user profiles, perform the following steps to modify the deployment configuration. In most cases, you will not have to use this method of deployment. Use this method only if you need to support multiple types of users that require different ProfileManager deployments-deployments that allow a property set to be mapped to different custom EntityPropertyManagers based on ProfileType.

An example of this method is the deployment of the custom CustomerProfileManager in customer.jar. The CustomerProfileManager is configured to use the custom EntityPropertyManager (CustomerPropertyManager) for properties in the "CustomerProperties" property set. The UserManager EJB in usermgmt.jar is configured to map the "WLCS_Customer" ProfileType to the custom deployment of the ProfileManager, CustomerProfileManager.

1. Back up the usermgmt.jar file in your enterprise application root directory.

2. From usermgmt.jar, extract META-INF/ejb-jar.xml and open it for editing.

3. In ejb-jar.xml, copy the entire <session> tag for the UserProfileManager and configure it to use your custom implementation class for your new deployment of ProfileManager.

   In addition, you could extend the UserProfileManager home and remote interfaces with your own interfaces if you want to repackage them to correspond to your packaging (for example., examples.usermgmt.MyProfileManagerHome, examples.usermgmt.MyProfileManager). However, it is sufficient to replace the bean implementation class:

   <session>

     <ejb-name>MyProfileManager</ejb-name>

     <home>com.bea.p13n.usermgmt.profile.ProfileManagerHome
     </home>

     <remote>com.bea.p13n.usermgmt.profile.ProfileManager
     </remote>

     <ejb-class>examples.usermgmt.MyProfileManagerImpl
     </ejb-class>

     <session-type>Stateless</session-type>

     <transaction-type>Container</transaction-type>

     <!-- 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>

     <!-- register a Creator for MyEntityPropertyManager -->

     <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>

     <!-- register a Remover for MyEntityPropertyManager -->

     <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>

     <!-- the default property manager -->

     <ejb-ref>

       <ejb-ref-name>ejb/EntityPropertyManager</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>

     <!-- my custom property manager -->

     <ejb-ref>

       <ejb-ref-name>ejb/MyEntityPropertyManager</ejb-ref-name>

       <ejb-ref-type>Session</ejb-ref-type>

       <home>examples.usermgmt.EntityPropertyManagerHome</home>

       <remote>examples.usermgmt.EntityPropertyManager</remote>

     </ejb-ref>

     <!-- property set manager -->

     <ejb-ref>

       <ejb-ref-name>ejb/PropertySetManager</ejb-ref-name>

       <ejb-ref-type>Session</ejb-ref-type>

       <home>com.bea.p13n.property.PropertySetManagerHome</home>

       <remote>com.bea.p13n.property.PropertySetManager</remote>

     </ejb-ref>

     <!-- group profile manager, which is the user's successor -->

     <ejb-ref>

       <ejb-ref-name>ejb/GroupProfileManager</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-link>GroupProfileManager</ejb-link>

     </ejb-ref>

     <security-role-ref>

       <description>This ref declares the Administrative role
       for this bean</description>

       <role-name>SystemAdminRole</role-name>

       <role-link>SystemAdminRole</role-link>

     </security-role-ref>

     <security-role-ref>

       <description>This ref declares the Administrative role
       for this bean</description>

       <role-name>DelegatedAdminRole</role-name>

       <role-link>DelegatedAdminRole</role-link>

     </security-role-ref>

   </session>

   You must create an <env-entry> element to map a property set to your custom EntityPropertyManager. You must also create a <ejb-ref> element to map a reference to an EJB that matches the name from the PropertyMapping with ejb/ prepended. The home and remote class names for your custom EntityPropertyManager match the classes from your EJB JAR file for your custom EntityPropertyManager.

   Also, if your EntityPropertyManager implementation handles creating and removing profile records, you must also add Creator and Remover entries. This instructs your new ProfileManager to call your custom EntityPropertyManager when creating or deleting user profile records. The name suffixes for the Creator and Remover, "Creator1" and "Remover1", are arbitrary. All Creators and Removers will be iterated through when your ProfileManager creates or removes a user profile. The value for the Creator and Remover matches the <ejb-ref-name> for your custom EntityPropertyManager without the ejb/ prefix.

4. In ejb-jar.xml, you must add an <ejb-ref> to the UserManager EJB section to map your ProfileType to your new deployment of the ProfileManager like this:

   <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>

   The <ejb-ref-name> must start with ejb/ProfileType/ and must end with the name that you want to use as the profile type as an argument in the createUser() method of UserManager.

5. From usermgmt.jar, extract META-INF/weblogic-ejb-jar.xml and open it for editing.

6. In weblogic-ejb-jar.xml, copy the weblogic-enterprise-bean tag for the UserProfileManager and configure it for your new ProfileManager deployment:

   <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>

   You must create an <ejb-reference-description> to map the <ejb-ref> for your custom EntityPropertyManager to the JNDI name. This JNDI name must match the name you assigned in weblogic-ejb-jar.xml in the JAR file for your custom EntityPropertyManager.

   Note the ${APPNAME} string substitution variable. The WebLogic Server EJB container automatically substitutes the enterprise application name to scope the JNDI name to the application.

7. In weblogic-ejb-jar.xml, copy the <transaction-isolation> tag for the UserProfileManager and configure it for your new ProfileManager deployment:

   <transaction-isolation>

     <isolation-level>TRANSACTION_READ_COMMITTED
     </isolation-level>

     <method>

       <ejb-name>MyProfileManager</ejb-name>

       <method-name>*</method-name>

     </method>

   </transaction-isolation>

8. Create a temporary usermgmt.jar for your new deployment descriptors and your new ProfileManager bean implementation class (and remote and home interfaces if you are replacing those). This temporary EJB JAR archive should not have any container classes in it. Run ejbc to generate new container classes.

9. Edit META-INF/application.xml for your enterprise application to add an entry for your custom EntityPropertyManager EJB module like this:

   <module>

     <ejb>UUPExample.jar</ejb>

   </module>

10. If you are using an application-wide cache, you can manage it from the WebLogic Server Administration Console if you add a <Cache> tag for your cache to the META-INF/application-config.xml deployment descriptor for your enterprise application like this:

    <Cache

      Name="UUPExampleCache"

      TimeToLive="60000"

    />

    For information on using com.bea.p13n.cache.Cache, see "Using Caches" in the Performance Tuning Guide.

11. Verify the modified usermgmt.jar and your custom EntityPropertyManager EJB JAR archive are in the root directory of your enterprise application and start your server.

12. Use the WebLogic Server Administration Console to verify your EJB module is deployed to the enterprise application, then use the WebLogic Server Administration Console to add your server as a target for the EJB module. You must select a target to have your domain's config.xml file updated to deploy your EJB module to the server.

13. Use the E-Business Control Center to create a User Profile (property set) that matches the name of the property set that you mapped to your custom EntityPropertyManager in ejb-jar.xml for the UserProfileManager (in usermgmt.jar). You could also map specific property names in a property set to your custom EntityPropertyManager.

    Note: Be sure to synchronize the new data to your server after the property set is created.

14. Your new Unified User Profile type is ready to use. You can use the WebLogic Portal Administration Tools to create a user of type "UUPExampleUser," and it will use your UUP implementation when the "UUPExample" property set is being modified. That is because you mapped the ProfileType using an <ejb-ref> in your UserManager deployment descriptor, ejb/ProfileType/UUPExampleUser. Now, when you call createUser("bob", "password", "UUPExampleUser") on the UserManager, several things will happen:

    • A user named "bob" is created in the security realm.

    • A WebLogic Portal Server profile record is created for Bob in the WebLogic Portal RDBMS repository.

    • If you set up the Creator mapping, the UserManager will call your new ProfileManager deployment, which will call your custom EntityPropertyManager to create a record for Bob in your data source.

    • Retrieving Bob's profile will use your new ProfileManager deployment, and when you request a property belonging to the "UUPExample" property set, the request will be routed to your custom EntityPropertyManager implementation.