|
|
|
|
|
|
Creating and Managing Users
This chapter discusses how User Management combines enterprise data about users with profile data that is used to personalize the users' view of the application.
This topic includes the following sections:
Note: Throughout this chapter, the environment variable WL_COMMERCE_HOME is used to indicate the directory in which you installed the WebLogic Commerce Server 3.2 and WebLogic Personalization Server 3.2 software.
Overview of User Management
The User Management system is a set of JSP tags, EJBs, and tools that facilitate the creation and persistence of user and group profile properties. It provides access to user profile information within a larger personalization server solution. In addition, the User Management system provides user-authentication mechanisms and user-to-group associations.
The User Management system responsibilities include:
Users and Groups
The two primary components employed by the Personalization Server's User Management system are the User and Group, which extend ConfigurableEntity. It is from these components that User, and Group, and Unified User Profile functionality stems. User and Group components are also referred to as "user profiles" and "group profiles."
The fully qualified name of each object is as follows:
The User Management system works in conjunction with the WebLogic Server's security realm. In this arrangement, the security realm provides a list of users and groups, group membership information, and authentication. The User Management system uses the security realm to authenticate users and to know which users and groups exist and are valid, and which users are in a group. With this information from the security realm, it is possible for the User Management system to accomplish its primary duties: creating, retrieving, and managing user and group profiles complete with property data. A default security realm (User Management RDBMSRealm) is provided by the Personalization Server as part of its "out-of-the-box" configuration.
Property data can be anything that is relevant to a user or group profile in the context of your personalized application. Things like age, gender, and favorite genres of music could all be property data. Things like department, position, and office location could also be property data. Much more is explained later about the actual and possible implementation details of handling property data in user and group profiles.
Group hierarchies permit property inheritance. For example, if a user profile does not yet have a "backgroundColor" property value, then the backgroundColor property value might be inherited from an "engineering" group. Groups may have only one or no parent group. As will be discussed later in this chapter, even if a realm for a third-party data store (for example, LDAP server) is used to access users and groups, any arbitrary group hierarchy may be configured for personalization purposes (property inheritance) via the User Management tools.
Profile functionality for both the User and Group components is inherited from the ConfigurableEntity implementation. Figure 4-1 shows a simplified representation of the User-Group-ConfigurableEntity relationship.
Figure 4-1 The User-Group-ConfigurableEntity Relationship
Unified User Profiles
In the BEA WebLogic Personalization Server, system users are represented by user profiles. A user profile provides an ID for a user and access to the properties of a user, such as age or e-mail address. Property values can be single-valued or multi-valued, and are requested via a getProperty() method which takes a property name as a key.
An advantage of the user profile is that it can be extended and customized to retrieve user information from an existing data source. For example, the user profile that ships with the Personalization Server can combine user properties from the Personalization Server database with user properties from an LDAP server into a single user profile for use within an application. Developers and system users need not worry about the different underlying data sources. To them there is just one place to go for user information - the user profile.
The Unified User Profile (UUP) is the name used to describe this aggregation of properties from an existing data source and the Personalization Server database tables into a single, customized user profile. More specifically, a UUP marries existing user/customer data by extending BEA's User component. By installing the Personalization Server's database tables into the existing database instance and extending the provided com.beasys.commerce.axiom.contact.User implementation, developers can quickly create a customized UUP that retrieves and stores properties from/to the existing database. This powerful flexibility is desirable because it allows access to existing data without requiring data migration or disrupting existing applications that also use the data. Conversely, if it is more desirable to migrate existing data into a separate Personalization Server database instance, this is also possible.
Configuration 1
Users and groups exist in some type of data store already, such as an LDAP directory. Existing user property data must be incorporated into the Unified User Profile as shown in Figure 4-2.
Figure 4-2 Configuration 1
Users and groups already exist in a data store such as an LDAP directory. No existing user or group data must be incorporated into the Unified User Profile. All user and group property data is stored in the Personalization Server's database tables as shown in Figure 4-3.
Figure 4-3 Configuration 2
There is no existing store of users and groups. The Personalization Server's database tables contain all user and group data as shown in Figure 4-4.
Figure 4-4 Possible Configuration 3
User, group, and property data are in an existing database. Existing user property data must be incorporated into the Unified User Profile. A custom realm must be created in order to use the existing users and groups with the Personalization Server as shown in Figure 4-5.
Figure 4-5 Possible Configuration 4
The UnifiedUser example, found at %WL_COMMERCE_HOME%/server/public_html/examples/unifieduserprofile/index.htm, demonstrates a fictitious company's use of the UUP to take advantage of existing customer data. The UnifiedUser extends com.beasys.commerce.axiom.contact.User and retrieves data from a pre-existing database. If you have existing user information that you wish to leverage in your application, it is recommended that you study this example. The UnifiedUser shows how, with relative ease, you can create a customized UUP that suits your application's persistence needs. The following table explains exactly what must be extended in order to create your own custom UUP.
|
Object |
Must Extend |
|
UUP Primary Key |
com.beasys.commerce.axiom.contact.UserPk--with no key fields added. |
|
UUP EJB Interface |
com.beasys.commerce.axiom.contact.User |
|
UUP EJB Implementation |
com.beasys.commerce.axiom.contact.UserImpl |
The fact that UUPs are ConfigurableEntities means that user profiles have the notion of setting and getting a property explicitly or implicitly. Explicitly setting a property means calling a setter method for a property directly. Implicitly setting a property means setting a property via the setProperty() method where no explicit setter method is available. For example, if a UUP contains a "userPoints" property, calling setUserPoints() directly would explicitly set the userPoints property, while calling setProperty() with the "userPoints" key would implicitly set the userPoints property. When it is called, setProperty() will first look for a setUserPoints() setter method to call in the user profile. If such a setter method exists, this method is called and is responsible for setting the property and doing whatever else is necessary regarding that property's change in value. Ultimately it is the UUP implementation's responsibility to persist explicitly-set property values- even if they are implicitly called via setProperty(). ConfigurableEntity only handles persisting implicitly set properties where no explicit setter method exists.
Figure 4-6 diagrams both an explicit and implicit call to setUserPoints(). In both cases, it is the UUP bean's responsibility to handle storing the userPoints value. If no setUserPoints() method had existed in the UUP bean, the ConfigurableEntity implementation would have handled storing the userPoints value.
Figure 4-6 Implicit and Explicit Calls to Set the userPoints Property
This notion of implicitly and explicitly setting properties allows for additional flexibility in UUP implementation. If any special logic needs to happen during the setting or getting of a property, such as the recalculation of some other value, it can conveniently be done in a setter or getter method for that property. Functionality external to the UUP can always count on having a setProperty() method and a getProperty() method for access to properties, eliminating any need to know whether a property has its own setter or getter. For example, the <um:getProperty> JSP tag can always retrieve the userPoints property value even if a getUserPoints() method is the only way provided by the UUP to retrieve userPoints. This is because the UUP's getProperty() method will first check to see if it has a getUserPoints() method before checking elsewhere. Properties that have an explicit set<PropertyName>() and get<PropertyName>() method are referred to as "explicit properties," while properties that can only be set through a call to setProperty() are referred to as "implicit properties."
When implementing a custom UUP EJB, you only need to worry about implementing explicit getter and setter methods for the explicit properties you want the UUP to have. The implementations of these setters and getters then do whatever is necessary to set and retrieve the property values in the existing datastore.
There are a few important things to be aware of when creating a custom UUP. The get<PropertyName>(), set<PropertyName>() convention must be followed for all explicit property setting and getting in a UUP. This means if you have a UUP with an explicit userPoints property, you must provide an explicit getUserPoints() method-retrieveUserPoints() would not work. Similarly, setting userPoints must be done with a setUserPoints() method. This is because the getProperty() and setProperty() methods look for getters and setters that follow this convention when getting and setting properties via implicit calls. Overriding setProperty() or getProperty() is not permitted-all getting and setting of explicit properties must be done through getter and setter methods. Explicit getters and setters must take and return objects-primitives such as long and float must be wrapped in java.lang.Long and java.lang.Float objects to be compatible with ConfigurableEntity's getProperty() and setProperty() methods.
Also, if you provide a getter method, it is a good idea to also provide a setter method and vice versa. This is because you can never predict when someone will try to set or get a property. For example, let's say you provide a getter that retrieves a property from a database table but no corresponding setter. If setProperty() is called for that property it will be stored in a Personalization Server table. This is messy because you have the value being retrieved from one place and set in another. The next time the property is retrieved, it would have its original value-not the value that was set. If you want to provide a read-only property, you should implement an empty setter method.
The definition of ConfigurableEntity's getProperty() method is as follows:
public Object getProperty(String propertySet,
String propertyName,
ConfigurableEntity explicitSuccessor,
Object defaultValue);
The getProperty() method searches for properties in different places in a specific order which is important to understand. For example, if a property is not found for a User, perhaps a Group should be queried for the value. In this case the User would inherit the property value from a Group. In ConfigurableEntity terms, the Group would be the User's "successor." If a property is not found in a ConfigurableEntity, then the ConfigurableEntity's successor is queried for the value. This way ConfigurableEntities can inherit and override values from a parent entity. Successors can be implicit or explicit. An implicit successor is a ConfigurableEntity's default successor or a successor that is set for a specific Property Set. An explicit successor is a ConfigurableEntity that is passed as a parameter to the getProperty() method. Following is the order of the getProperty() property search as it exists in ConfigurableEntity, and hence the User and Group objects as well as any UUP objects:
Note: Properties to be retrieved from LDAP must be registered as LDAP attributes. See Registering User Attributes for Retrieval from LDAP.
The definition of ConfigurableEntity's setProperty() method is as follows:
public Object setProperty(String propertySet,
String propertyName,
Object value);
This method has a few details that are also important to understand. If setProperty() is used to set a property for a Property Set that is inconsistent with the property set's definition, an exception is thrown. For example, suppose we have defined a "UnifiedUserExample" Property Set that has a userPoints property of type Integer. If someone tries to set the userPoints property for the "UnifiedUserExample" Property Set to be "foo," an exception would be thrown because userPoints is defined as being of type Integer and "foo" is text. Similarly, setting a Boolean property value to "bar" would result in an exception because Boolean values are restricted to Boolean objects.
If setProperty() is called and null is passed for the Property Set, the property value is set in the null Property Set-referred to as the default Property Set. As described previously in the search order of getProperty(), the default property set is searched before looking for the property value in the "Reserved" Property Set and then a successor.
The "Reserved" Property Set is a read-only Property Set that is used to hold property values from an external datastore. The only time the "Reserved" Property Set is currently used in the Personalization Server is when properties are retrieved from an LDAP directory. Attempting to set a property in the "Reserved" Property Set will result in an exception being thrown. Properties in the "Reserved" Property Set and the Reserved Property Set itself are not editable via the User Management tools. The User Management tools allow the specification of attributes to be retrieved from an LDAP server for users and groups.Only these attributes will be retrieved at runtime.
Properties can be set via setProperty() with a Property Set specified that does not exist. This is allowed, but strongly discouraged. When this is done, a Property Set is not created "on-the-fly" for the specified Property Set name. Rather, the specified Property Set name serves only as a namespace for the property. Similarly, it is allowed but strongly discouraged to set a property via setProperty() for an existing Property Set specifying a property that does not exist for that Property Set. Properties set in either of these ways are not editable through the User Management tools, but properties in the "null" ( "default") property set are editable from the tools.
A couple of additional points about getProperty() and setProperty() that are worth mentioning are as follow:
Object value = myUser.getProperty("my_property_set",
"my_integer_property",
null,
null);
Number tempNumber = (Number) value;
int realValue = tempNumber.intValue(); Object value = myUser.getProperty("my_property_set",
"my_float_property",
null,
null);
Number tempNumber = (Number) value;
float realValue = tempNumber.floatValue();The com.beasys.commerce.axiom.contact.User object offers functionality for EJB find operations that makes integrating a UUP with the Personalization Server easy. Once a UUP's ejbFind() finds records in the existing data store, the call to super.ejbFind()--the User object ejbFind()-- will create the necessary records for the UUP in the Personalization Server tables if they do not yet exist and the following condition is met: If the User object ejbFind() fails, it checks the underlying security realm to see if the username corresponds to a valid user. If so, User's ejbFind() creates the necessary records, thereby eliminating finder errors and the need to spend time initially migrating user data into the Personalization Server's User database tables (Figure 4-7).
Figure 4-7 Flow During an ejbFind() Operation
If your configuration is such that the realm cannot verify the existence of the user, but the user must be created, it is the responsibility of your EJB to create the superclass records if they are not found initially. The UnifiedUser example code demonstrates such a situation. Please refer to the ejbFindByPrimaryKey() method in the file UnifiedUserBean.java.
Six entries are required in the ejb-jar.xml file used when creating the unified user profile bean's descriptor. There entries are:
This environment entry is not to be confused with the actual JNDI lookup name of the extended EJB. Rather, it is used to relate profile entries for the UUP EJB with those of com.beasys.commerce.axiom.contact.User. The value must always be:
com.beasys.commerce.axiom.contact.User
Exact entry:
<env-entry>
<env-entry-name>JNDIHomeName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>
com.beasys.commerce.axiom.contact.User
</env-entry-value>
</env-entry>
This environment entry is used to configure the EJB to pull property values from a particular classification of Property Sets. The value must always be:
USER
Exact entry:
<env-entry>
<env-entry-name>SchemaGroupName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>USER</env-entry-value>
</env-entry>
This environment entry specifies which SmartBMP class to use when creating, refreshing, updating, and removing the EJB. If you have created a SmartBMP for your class which extends com.beasys.commerce.axiom.contact.UserSmartBMP, use the classname of your SmartBMP for this entry. If you do not use a particular SmartBMP with your class, use com.beasys.commerce.axiom.contact.UserSmartBMP as the value.
Sample entry:
<env-entry>
<env-entry-name>SmartBMPClass</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>
com.beasys.commerce.axiom.contact.UserSmartBMP
</env-entry-value>
</env-entry>
This environment entry specifies which EntityPropertyManager bean to use when accessing user and group properties. If using the LDAP configuration (security realm is the LDAPRealm), the entry must be as follows.
Exact Entry:
<env-entry>
<env-entry-name>EntityPropertyManagerHome</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>
com.beasys.commerce.foundation.property.EntityPropertyAggregator
</env-entry-value>
</env-entry>
For any other configuration the EntityPropertyManagerHome entry should be specified as follows.
Exact Entry:
<env-entry>
<env-entry-name>EntityPropertyManagerHome</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>
com.beasys.commerce.foundation.property.EntityPropertyManager
</env-entry-value>
</env-entry>
The contents of the ejb-jar.xml file shipped with the UnifiedUser example are shown below. Note that this bean was not paired with its own SmartBMP implementation derived from UserSmartBMP.
This entry specifies which persistence helper class should be used by the BMP. If the standard UserSmartBMP is being used, the value should be "com.beasys.commerce.foundation.plugin.bmp.BMPPersistenceHelperPlugin".
Exact Entry:
<env-entry>
<env-entry-name>PersistenceHelperPlugin</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>com.beasys.commerce.foundation.plugin.bmp. BMPPersistenceHelperPlugin</env-entry-value>
</env-entry>
This entry specifies the type of Unified Profile that this class belongs to. It is necessary to transparently create, edit, and delete UUP users through the admin tools. In the Unified User Example, the value is "Unified Profile Example".
Exact Entry:
<env-entry>
<env-entry-name>UnifiedProfileType</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Unified Profile Example</env-entry-value>
</env-entry>
<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>examples.usermgmt.UnifiedUser</ejb-name>
<home>examples.usermgmt.UnifiedUserHome</home>
<remote>examples.usermgmt.UnifiedUser</remote>
<ejb-class>examples.usermgmt.UnifiedUserBean</ejb-class>
<persistence-type>Bean</persistence-type>
<prim-key-class>examples.usermgmt.UnifiedUserPk</prim-key-class>
<reentrant>False</reentrant>
<env-entry>
<env-entry-name>JNDIHomeName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>com.beasys.commerce.axiom.contact.User</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>SchemaGroupName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>USER</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>SmartBMPClass</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-
value>com.beasys.commerce.axiom.contact.UserSmartBMP</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>EntityPropertyManagerHome</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-
value>com.beasys.commerce.foundation.property.EntityPropertyAggregator</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>PersistenceHelperPlugin</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-
value>com.beasys.commerce.foundation.plugin.bmp.BMPPersistenceHelperPlugin</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>UnifiedProfileType</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Unified Profile Example</env-entry-value>
</env-entry>
<resource-ref>
<res-ref-name>jdbc/commercePool</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</entity>
</enterprise-beans>
<assembly-descriptor></assembly-descriptor>
</ejb-jar>
Additionally, the following entry must be added to the weblogic-ejb-jar.xml file of the UUP so that it can access the commercePool database connection pool:
<weblogic-enterprise-bean>
[...]
<reference-descriptor>
<resource-description>
<res-ref-name>jdbc/commercePool</res-ref-name>
<jndi-name>weblogic.jdbc.jts.commercePool</jndi-name>
</resource-description>
</reference-descriptor>
[...]
</weblogic-enterprise-bean>
The last step in completing a custom UUP requires the UUP to be registered with the Personalization Server through the User Management tools. In order to register the UUP, the User Management tools require the following:
|
Item |
Description |
|
Profile Type Name |
Arbitrary name that is later used to refer to the profile type through the User Management system's <um:getProfile> JSP extension tag. |
|
Profile Home Class |
The home class of the new profile type. |
|
Profile Remote Interface |
The remote interface of the new profile type. |
|
Profile Primary Key Class |
The primary key class of the new profile type. |
|
Profile JNDI Name |
The JNDI lookup name of the new profile type. |
By registering the UUP with the Personalization Server, it becomes possible to ask for the new profile type with the <um:getProfile> JSP tag:
<um:getProfile profileType="UnifiedUserExample" profileKey="<%=username%>"/>
It is then possible to use the <um:getProperty> and <um:setProperty> JSP tags with the UUP.
Using WebLogic Realms
A realm is a Java class that provides access to a store of Users, Groups, ACLs (Access Control Lists), and related services. WebLogic Server uses a realm as a service, calling into the realm to retrieve Users, Groups, and ACLs as Java objects. WebLogic Server provides realms that access the WebLogic Server properties file, Windows NT, or UNIX networks, and LDAP servers for user, group, and ACL information. The WebLogic Personalization Server provides an additional RDBMSRealm which uses its own database tables containing user and group information as an out-of-the-box option. It is also possible to create your own realm if your situation requires accessing a datastore not supported by WebLogic Server.
The WebLogic Personalization Server must have access to a realm to retrieve information about users and groups, determine a group's members, and authenticate users. By depending on realms, the Personalization Server can use existing stores of user and group information, allowing that information to remain in place. For instance, if you already have users and groups defined in an LDAP directory, they can be accessed by the Personalization Server through the LDAPRealm without requiring any redundant data entry.
If you are using the Personalization Server without an external data store of user and group information, then that information will be stored in the Personalization Server's database tables. In this case, the com.beasys.commerce.axiom.contact.security.RDBMSRealm must be used to access user and group information from the Personalization Server tables. For this configuration to work, the appropriate realm properties for your database type must exist in the commerce.properties file. Make sure the following properties are set:
In the BEA WebLogic Personalization Server's commerce.properties file:
If using Oracle Thin Drivers (Oracle 8.0.5, Oracle 8.1.5):
commerce.usermgmt.RDBMSRealm.driver=oracle.jdbc.driver.OracleDriver
commerce.usermgmt.RDBMSRealm.dbUrl=\
jdbc:oracle:thin:@<machine name>:<port number>:<database instance>
commerce.usermgmt.RDBMSRealm.dbUser=<database user>
commerce.usermgmt.RDBMSRealm.dbPassword=<database user's password>
If using the WebLogic Oracle OCI Driver:
commerce.usermgmt.RDBMSRealm.driver=weblogic.jdbc.oci.Driver
commerce.usermgmt.RDBMSRealm.dbUrl=jdbc:weblogic:oracle
commerce.usermgmt.RDBMSRealm.dbServer=<machine name>
commerce.usermgmt.RDBMSRealm.dbUser=<database user>
commerce.usermgmt.RDBMSRealm.dbPassword=<database user's password>
If using Cloudscape:
commerce.usermgmt.RDBMSRealm.driver=COM.cloudscape.core.
JDBCDriver
commerce.usermgmt.RDBMSRealm.dbUrl=jdbc:cloudscape:Commerce;\
create=true;autocommit=false
commerce.usermgmt.RDBMSRealm.dbUser=none
commerce.usermgmt.RDBMSRealm.dbPassword=none
In the BEA WebLogic Server's weblogic.properties file:
weblogic.security.realmClass=\
com.beasys.commerce.axiom.contact.security.RDBMSRealm
It is important to note that if a realm other than the Personalization Server's RDBMSRealm is being used, the administration tools for creating users and groups become inaccessible. This is because adding users and groups and administering credentials must be done through tools provided by the external datastore.
For use within the Personalization Server, a realm must be a subclass of weblogic.security.acl.AbstractListableRealm. The WebLogic NTRealm, LDAPRealm, and UnixRealm are all subclasses of AbstractListableRealm.
Tools are provided that allow a properly-configured realm to be set up for use by the Personalization Server. The realm configuration tools allow you to choose which groups from the realm you wish to use in the Personalization Server, map group names that have changed in the realm to new group names, and clean up Personalization Server records that no longer correspond to valid realm users or groups.
Note: Changing the underlying realm can cause unpredictable behavior if the realm configuration tools are not immediately used to map and remove groups and clean up users as appropriate for the new realm.
In addition to user and group information, realms may also provide ACLs to determine an authenticated user's permissions within the system. An ACL guards an object or service in WebLogic Server. ACLs can guard servlets and JSP pages, JMS queues and topics, EJBs, JDBC connection pools, JNDI contexts, and ZAC packages. You can also create custom ACLs for use in your applications, and these ACLs will be supported by the Personalization Server.
An ACL holds a list of AclEntries, each with a set of permissions for a user or group. A permission is an action that can be performed on the protected resource - for example, "execute," "lookup," "read," or "write." The exact permissions available depend on the type of resource the ACL protects. For example, a servlet requires "execute" permission, and a JMS queue requires "read" or "write" permission.
For more information on realms, including how to configure and administer realms, consult the WebLogic Server documentation for Using WebLogic Realms and ACLs. Also, for more information on implementing a custom realm, see the WebLogic Server documentation.
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">. For more information on these tags, see the topic "User Management JSP tags" in JSP Tag Library Reference in the WebLogic Personalization Server Developer's Guide.
For an example, see %WL_COMMERCE_HOME%/server/public_html/anonymousprofile/index.html
Privacy Statement
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:
For complete information, see the P3P specification, section 2.2.1. http://www.w3.org/TR/P3P/#mechanism_ref
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.
User Manager
The UserManager Session EJB provides user management functionality in a Personalization Server-specific context. Services provided by the UserManager include:
For a complete list of UserManager services, please refer to the UserManager Javadoc.
Though it supplies the underlying functionality of the Group/User management JSP extension tags, the UserManager can be accessed directly. However, the UserManager is not intended for use outside the context of the Personalization Server. To emphasize this point, the general relationship between the UserManager and the security realm support mechanism will be briefly explained, followed by a few examples.
Figure 4-8 shows the relationship between the UserManager, the RealmLink, and the security realm. The RealmLink is used to ensure that realm query results are consistent with Personalization Server user and group data. The RealmLink is the only object aware of both the Personalization Server data, and the Realm user and group data. An example of RealmLink activity is the query for group names associated with a particular user. Since the user manager administration tools allow for group registration with the Personalization server, the RealmLink will only return group names for a particular user that exist in both the security realm and in the Personalization Server tables.
Figure 4-8 UserManager/RealmLink Cooperation
To ensure behavior consistent with Personalization Server purposes, the UserManager employs two primary strategies:
For example, the createGroup() method throws a UserManagementException if the out-of-the-box RDBMSRealm is not being used. The logic behind such an exception is that the UserManager is designed to work with the default Personalization database schema. If another realm is being used (for example, WebLogic LDAPRealm), it is assumed that the client has another means, besides the Personalization Server Administration Tools, that should be used for adding and removing groups and users to/from the realm.
For example, the getGroupNamesForUser() method returns only group names which exist in the current security realm and which are registered with the Personalization Server via the Realm Configuration tools.
Using the User Management Tool
The User Management Administration Tools allow you to create and associate users and groups or to link to and use existing directories of users. A user or group may then be personalized by overriding property values as defined in the Property Set Management tool. The Unified Profile Types tool allows you to configure access through User Management tag libraries to your existing application EJBs.
Note: If your system is configured for a third-party realm, the interface above would contain a Realm banner in addition to the ones presented and an LDAP banner if you are using the LDAPRealm. In addition, the Create buttons would not appear on the Users or Groups banners.
Creating Groups
Note: The User Management tools do not allow the creation of a group called "everyone", as this is a reserved WebLogic Server group name.
To create groups:
Deleting Groups
To delete groups:
Note: The group name must be entered exactly.
Adding Users to Groups
To add users to groups:
To locate the appropriate group, do one of the following:
To locate a user, do one of the following:
Note: The search applies both list boxes.
Removing Users from Groups
To remove users from groups:
To locate the appropriate group, do one of the following:
To locate a user, do one of the following:
Editing Group Property Values
To edit group property values:
To locate the appropriate group, do one of the following:
Notes: Non-default Property sets and properties not configured through the Property Set Management tools are not editable here.
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:
Creating Users
To create users:
Note: Limit usernames to 25 characters.
Note: Characters in password fields appear as asterisks.
Alternatively, click Back to return to the User Management Home page without
creating the new user.
Note: The WLCS RDBMSrealm allows mixed case (for example: User, user) user creation.
Note: The administration tools do not allow the creation of a user with username "system" or "guest", as these are reserved WebLogic Server terms.
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:
To locate a user, do one of the following:
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:
Deleting Users
To delete users:
To locate a user, do one of the following:
Note: When a user, declared in the weblogic.properties file, is deleted from the Delete Users screen, the corresponding User component and its properties will be deleted, but the username will continue to be returned from user searches.
Creating Unified Profile Types
To create unified profile types:
The Unified Profile Type tool facilitates the registration of profile types to be used as Unified User Profile (UUP) objects.
The following table contains descriptions of the Create New Unified Profile Type fields:
|
Field |
Description |
|---|---|
|
Profile Type Name |
This is an arbitrary name that is used to refer to the profile type through the User Management system's <um:getProfile> JSP extension tag. |
|
Profile Remote Interface |
The remote interface of the new profile type. |
|
Home |
The home class of the new profile type. |
|
PK Class |
The primary key class of the new profile type. |
|
JNDI Name |
The JNDI lookup name of the new profile type. |
Alternatively, click Back to return to the User Management Home page without
saving your changes.
Editing Unified Profile Types
To edit unified profile types:
Deleting Unified Profile Types
To delete unified profile types:
Using Other Realms
The remaining tools are accessible only if a realm other than Personalization Server's RDBMSRealm is used. The LDAP tools are accessible only if WebLogic's LDAPRealm is used.
Registering User Attributes for Retrieval from LDAP
This screen is used to register user attribute names for run-time retrieval via the group profile.
Note: For the LDAP features to appear in the User Management tool, you must first install and configure the WebLogic LDAP security realm for your WebLogic Server. See http://www.weblogic.com/docs51/admindocs/ldap.html for details.
Note: Your WebLogic Commerce Server administration tool is set up to allow access to the group called "admin." To access your WebLogic Commerce Server administration tool after you start your server with the alternate security realm, you will need to create a group called "admin" with an administrative user in it. By default, the exampleportal application is set to the AcmeUsers group profile when not authenticated. To use the exampleportal application with another security realm such as LDAP, you need to create a group called "AcmeUsers." Without this group, an exception is thrown to the console complaining about its absence. Another solution is to change the default group for exampleportal from AcmeUsers to another group being used within the security realm.
Registering LDAP Properties for Use With Rules
To use LDAP properties in rules, the rules need to know that the properties exist. For any properties that are registered for retrieval from LDAP, create a property set with the LDAP properties in it, and give each property the same name as the property that is registered in LDAP.
You cannot use the User Management Administration Tool or the WebLogic Personalization Server framework to modify properties that are stored in LDAP, but you can use the fact that other property sets are searched before LDAP if you want to override the LDAP value.
Unregistering User Attributes for Retrieval from LDAP
To unregister user attributes for retrieval from LDAP:
Registering Group Attributes for Retrieval from LDAP
To register group attributes for retrieval from LDAP:
Unregistering Group Attributes for Retrieval from LDAP
To unregister group attributes for retrieval from LDAP:
Viewing LDAP Configuration Settings
To view LDAP configuration settings:
|
Parameter |
Description |
|---|---|
|
Groups Location |
Distinguished name for the hierarchical parent of all relevant groups. |
|
Group Name Attribute |
The name of the attribute that uniquely identifies a group. |
|
Group Username Attribute |
The name of the attribute in group objects that has as its value the group members. |
|
Users Location |
Distinguished name for the hierarchical parent of all relevant users. |
|
Username Attribute |
The name of the attribute that uniquely identifies users in the system. Example: login name or unique ID. |
|
LDAP System Principal |
Distinguished name for a system level user. This user has read access to all information in the LDAP directory accessed by the application. |
|
LDAP URL |
The Universal Resource Locator (URL) of the LDAP directory server you are running. |
|
SSL |
Indicates whether communication from the Personalization Server to the LDAP directory should be encrypted over SSL. |
Note: The values above are "read only" and are specified when configuring the LDAPRealm.
Selecting Groups for Use in the Personalization Server from the Realm
To select groups for use in the Personalization Server from the realm:
Mapping Realm Groups to the Personalization Server
When a name changes in the realm, you must change it in the Personalization Server too. Use this tool when a group name changes in the realm. Mapping works by changing the records in the Personalization Server to reflect the new group name.
Note: You are only given the option of mapping those groups that have been found in your database but are missing from the realm.
Note: Group mapping works by simply changing the name of the group in the personalization tables to the group name in the realm. All property data is retained.
Deleting Groups from Your Database
To delete groups from your database:
Note: You are only given the option of deleting those groups that are found in your database but are missing from the realm. A confirmation dialog box appears.
Deleting User Records That Do Not Exist in the Realm from the Personalization Database
To delete user records that do not exist in the realm from the Personalization database:
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|