|
|
|
|
|
|
Creating and Managing Users
This following topics are included:
Using the User Management Tool
Creating Unified Profile Types
Deleting Unified Profile Types
Registering group attributes for retrieval from LDAP
Deleting user attributes from LDAP
Adding group attributes in LDAP
Unregistering group attributes for retrieval in LDAP
Viewing LDAP configuration settings
Selecting groups for the Personalization Server from realm
Mapping realm groups to the Personalization Server
Deleting groups from your database
User Management joins enterprise data about users with profile data that is used to personalize the users' view of the application.
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 follow:
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 follows:
User - com.beasys.commerce.axiom.contact.User
Group - com.beasys.commerce.axiom.contact.Group
ConfigurableEntity - com.beasys.commerce.axiom.foundation.ConfigurableEntity
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 what 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 doesn't 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 (e.g., 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. The figure below 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 email 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.
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.
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.
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.
Figure 4-5 Possible Configuration 4
The UnifiedUser example, found at <install_dir>/server/publish.html/examples/unifieduserprofile/index.html, 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 preexisting 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.
The figure below 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:
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 it 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 doesn't 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" or "default" property set are editable from the tools.
A couple of additional points about getProperty() and setProperty() that are worth mentioning 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 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 collaborate 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 is used to configure the EJB to use the correct database connection pool class. The value must always be:
com.beasys.commerce.foundation.plugin.weblogic.WeblogicConnectionPool
Exact Entry:
<env-entry>
<env-entry-name>SmartConnectionPoolClass</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entryvalue>
com.beasys.commerce.foundation.plugin.weblogic.
WeblogicConnectionPool
</env-entry-value>
</env-entry>
This environment entry provides the URL of the database to the EJB. The value must always be:
jdbc:weblogic:jts:commercePool
Exact Entry:
<env-entry>
<env-entry-name>SmartBMP_URL</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>jdbc:weblogic:jts:commercePool</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 LDAP realm), 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 EntityPropertyManager 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.
<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>com.beasys.commerce.user.example.UnifiedUser</ejb-name>
<home>com.beasys.commerce.user.example.UnifiedUserHome</home>
<remote>com.beasys.commerce.user.example.UnifiedUser</remote>
<ejb-class>com.beasys.commerce.user.example.UnifiedUserBean</ejb-class>
<persistence-type>Bean</persistence-type>
<prim-key-class>com.beasys.commerce.user.example.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>SmartConnectionPoolClass</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-
value>com.beasys.commerce.foundation.plugin.weblogic.WeblogicConnectionPool</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>SmartBMP_URL</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>jdbc:weblogic:jts:commercePool</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>
</entity>
</enterprise-beans>
</ejb-jar>
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:
|
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 for doing so.
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 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">. See the documentation for User Management JSP tags for more information on these tags.
For an example, see <install_dir>/server/public_html/anonymousprofile/index.html.
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.
The figure below shows the relationship between the UserManger, 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 (e.g.,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 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 your are using the LDAP Realm. 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.
Deleting groups
To locate the group to delete by name:
Note: The group name must be entered exactly.
or
To locate the group to delete within the Group Hierarchy:
Adding users to groups
To locate the appropriate group by name:
or
To locate the appropriate group within the Group Hierarchy:
To locate the user by name:
or
To see a list of all users in an alphabetized category:
Note: The search applies both list boxes.
Removing users from groups
To locate the appropriate group by name:
or
To locate the appropriate group within the Group Hierarchy:
To locate the user by name:
To see a list of all users within an alphabetized category:
Editing group property values
To locate the appropriate group by name:
or
To locate the appropriate group within the Group Hierarchy:
Note: Non-default Property sets and properties not configured through the Property Set Management tools are not editable here.
Creating users
Note: All new users are com.beasys.commerce.axiom.contact.usercomponents.
Note: Limit user names 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 RDBMS realm allows mixed case (e.g., User, user) user creation.
Editing user property values
Note: The administration tools do not allow the creation of a user with username "system" or "guest", as these are reserved WebLogic Server terms.
Note: Explicit properties of UUP are not editable from the administration tools.
Note: Use the wildcard feature by entering a partial user name immediately followed by an asterisk (*). The asterisk is a search return variable.
To locate the appropriate user by name:
or
To see a list of all users within an alphabetized category:
Deleting users
To locate the appropriate user by name:
or
To see a list of all users within an alphabetized category:
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 user name will continue to be returned from user searches.
Creating 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
Deleting Unified Profile Types
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.
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/docs50/admindocs/ldap.html for details.
Registering group attributes for retrieval from LDAP
This screen is used to register group attribute names for runtime retrieves via the group profile.
Deleting user attributes from LDAP
Adding group attributes in LDAP
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/docs50/admindocs/ldap.html for details.
Unregistering group attributes for retrieval in LDAP
Viewing 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 LDAP realm.
Selecting groups for the Personalization Server from realm
Mapping realm groups to the Personalization Server
Use this tool when a group name changes in the realm. The records in the Personalization Server to reflect the 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
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 from personalization database
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|