If you have an existing store of users, groups, and additional properties (such as address, e-mail address, phone number, and so on), unified user profiles are a necessary part of bringing those user properties into the WebLogic Portal environment, where they can be used for retrieving and editing property values and setting up personalization, delegated administration, and visitor entitlements.
This topic describes the unified user profile, when to use it, and when not to use it.
Note: This topic contains the terms "user store" and "data store." A user store can contain users and groups, as well as additional properties. A data store implies that the store does not have to contain users and groups. It can simply contain properties.
Here is an example that explains what a unified user profile is and does:
Let's say you're creating a new portal application that you want users to be able to log in to. Let's also say your users are stored in an RDBMS user store outside of the WebLogic environment. You could connect WebLogic Server (your portal application's domain server instance) to your RDBMS system, and your users could log in to your portal application as if their usernames and passwords were stored in WebLogic Server. If authentication was all you wanted to provide through your RDBMS user store, you could stop here without needing a unified user profile.
However, let's say you also stored e-mail and phone number information (properties) for users in your RDBMS user store, and you wanted to be able to access those properties in your portal applications. In this case, you need to create a unified user profile for your RDBMS user store that lets you access those additional properties from your code.
Technically speaking, a unified user profile is a stateless session bean you create (with associated classes) that lets WebLogic Portal read property values stored in external data stores, such as LDAP servers and databases. Once connected to an external data store with a unified user profile, you can use portal JSP tags, controls, and the WebLogic Portal API to retrieve user property values from that store. You can also take the extra step of surfacing these external properties in the WebLogic Administration portal, where the properties can be used to define rules for personalization, visitor entitlements, and delegated administration.
Whether or not you have additional properties stored in your external user store, the external users and groups you connect to WebLogic Server are automatically assigned the default user property values you have set up in WebLogic Portal, without the use of a unified user profile. With the WebLogic Administration Portal, you can change the default WebLogic Portal property values for those users. These values are stored in WebLogic Portal's RDBMS data store using the Portal schema.
The following figure shows where a unified user profile fits between an external user store and the WebLogic environment.
1 |
This external RDBMS user store, which supports authentication, contains users (principals) and passwords in one database table and groups (principals) in another. Giving a user store authentication capabilities (as an authentication provider or identity asserter) involves configuration steps not associated with the unified user profile configuration process. (See Developing Security Providers for WebLogic Server.) Unified user profile configuration is not dependent on the authentication provider configuration and vice versa. Once the RDBMS authentication provider is connected to WebLogic Server, WebLogic Server (and WebLogic Portal) can see those users and groups. Those users can log in to your portal applications, and you can include those users and groups in your rules for personalization, delegated administration, and visitor entitlements. Also, WebLogic Portal's ProfileWrapper maps the principals to properties kept in the Portal schema, thereby establishing the user profile. |
2 |
Unified User Profile - The same external table that contains users and passwords also contains additional properties (email and phone) for each user. These additional properties are not part of authentication; but they are part of each user's profile. If you want to access these properties in your portal applications (with the WebLogic Portal JSP tags, controls, or API), you must create a unified user profile for the RDBMS user store. When you create the unified user profile, the ProfileWrapper includes the external properties in the user profile. The unified user profile consists of a stateless session bean and associated classes that you create. If you want to surface any of these properties in the WebLogic Administration Portal to be used in defining rules for personalization, delegated administration, or visitor entitlements, create a user profile property set for the external user store in addition to implementing your unified user profile session bean. The property set provides metadata about your external properties so that WebLogic Workshop and the WebLogic Administration Portal know how to display them. Properties from an external data store are typically read only in the WebLogic Administration Portal. |
3 |
WebLogic Portal lets you create user/group properties and set default values for those properties. Any user or group in WebLogic Server, whether created in the default LDAP store or brought in through a connection to an external user store, is automatically assigned those default property values; and you can change the default values for each user or group, programmatically or in the WebLogic Administration Portal. This does not involve unified user profiles, because the properties to be retrieved are local, not stored in an external data store. In the illustration, after the authentication provider or identity asserter provides the principals, the ProfileWrapper combines the principals with the external properties of email and phone (retrieved by the unified user profile) and the default WebLogic Portal properties of address and postal code, all of which make up the full user profile. |
A user profile is not a security realm, and it does not provide authentication. It is not even the external user store itself. It is the connection (stateless session bean with associated classes) that lets you read properties in the external user store.
Create a unified user profile for an external data store if you want to do any of the following:
You do not need to create a unified user profile for an external data store if you only want to: