User Management Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Planning a User and Group Strategy

Developing a plan to structure your users and groups can save you time later during other phases in the portal life cycle. You must determine where your existing user and group information is stored, how to retrieve this information, if you want to allow users to self-register, and if you will need to add new users to your portal,

You must also determine if you want to store and retrieve user profile information to use in personalization, and if you need to encrypt that user data. You should consider what each group can see or do in your portal, and plan your roles accordingly. If you decide you want to be able to edit user profile information later, you must configure the user store to be writable.

This chapter includes the following sections:


Developing a User and Group Management Strategy

You should plan your role structure at the same time you plan your strategy for users and groups. Making groups role-based to control what each group can do and see in your portal will save you time later.

Use the following steps as guidelines to develop a user and group strategy:

  1. Plan the structure of your groups and subgroups. If your users are located in an external user store and it contains groups, you can bring those existing groups into WebLogic Portal. See Planning Your Groups and Group Hierarchy for more information on categorizing groups and users. Plan the roles for your groups (see the Security Guide for more information on roles).
  2. Determine where your users are stored and how to access them. Users can be stored in an internal user store (the default RDBMS user store) or in an external user store. For a detailed description of authentication providers and user stores, see Accessing Users. Determine if you want to encrypt sensitive user data stored in property sets; see Planning Data Encryption and Creating a User Profile.
  3. Decide if you will create groups and add users programmatically or if you will use the Administration Console. You can use the WebLogic Scripting Tool to retrieve large numbers of existing users and groups. For instructions, see the Oracle WebLogic Server WebLogic Scripting Tool Guide. You can also create JSP tags and controls that let users register themselves when they go to your portal application.
  4. If necessary, you can perform the following tasks with the Administration Console or with the Server Administration Console:
    1. Create groups and subgroups
    2. Add users
    3. Add users to groups
    4. For instructions on creating groups and users in the Administration Console, see Adding and Managing Groups and Adding and Managing Users.

  5. Determine if you want to collect and integrate information about users (user profile properties) into your portal. You can use user profile information to target users with personalized content, e-mails, pre-populated forms, and discounts based on the rules you set up. Personalized content can also help guide your users through a process in your portal. For instructions, see Creating and Updating User Profiles and Editing User Profile Property Values.
  6. If user profile properties are stored externally, create a UUP to retrieve additional user profile information from the external user stores. You can use the properties to define rules for personalization, delegated administration, and visitor entitlement. For more information on when to use UUP, see Planning to Use a UUP. For instructions on setting up UUP, see Configuring a UUP.
  7. After your users and groups appear in the Administration Console, you can place users and groups in roles for delegated administration and assign visitor entitlement. If you are using more than one user store, you might have a group in one user store with a name that is the same as a group in another user store. When you set delegated administration on a group, an administrator in that delegated administration role can manage that group in all providers that contain that group (if the administrator also has delegated administration rights to those other providers). See the Security Guide for instructions on assigning roles and entitlement.


Planning Your Groups and Group Hierarchy

You can structure your users into groups and subgroups that look like your organization, which makes it easier to manage users. A group can be a related collection of users, such as a department, team, or regional office. A user can belong to more than one group, and groups can belong to other groups. Plan the roles you plan to associate with each group, to control what each group can see and do.

If you are using an external user store and it contains groups, you can build a group hierarchy tree to retrieve its group structure and view it in the Administration Console. See Adding and Managing Groups for instructions.

Administrators can also create and change a group profile, which is a schema that determines the data you collect and store about a specific group of users. The properties in the group profile contain information about the group that is stored in editable fields in the Administration Console.

You can edit properties for groups, but users belonging to those groups do not automatically inherit the group properties you specify. If a user belongs to two groups, for example, and you have edited each group’s properties, you must specify which set of group properties the user should inherit. For more information, see Adding and Managing Groups.

After you determine your group structure, you can programmatically create, move, and delete groups in or the Administration Console.

After you create your groups, you can tie the groups to roles and visitor entitlement to control what users see and experience in your portal.

This section contains the following topics:

Organizing Users into Groups

For instructions on putting users into groups, see Placing Users in Groups and Placing Users in Groups.

The Everyone group is a built-in group in Administration Console that you cannot modify. All users, including anonymous users, belong to this group.

The first step in setting up your groups is to determine your group hierarchy. For example, you might have a top-level group called AllEmployees that contains all of the employees in your company. The AllEmployees group might then contain other groups, each of which contains just the employees of offices in different geographic locations.

This categorization is shown in the following example:

AllEmployees (group containing all employees)

When you create a group, you create an empty group to which you can add an infinite number of users. You can then classify the users in the group by mapping the group to an entitlement role; see the Security Guide for instructions.

You can use the Administration Console to add a user to a group; see Placing Users in Groups. You can also use Workshop for WebLogic to add a user to a group; see Adding a User to a Group with a JSP Tag.

If you are using an external user store, you should determine if there are existing groups in that user store and match those groups to the groups you are creating.

Using an Existing Group Structure

If the user store you are accessing already has users organized into groups, you can build a hierarchical tree in the Administration Console that matches the existing group structure. If you are using WebLogic Portal Server's default RDBMS user store, you do not need to build a group hierarchy tree. See Using a Group Hierarchy Tree for instructions.


Working with a User Store

You can use the default RDBMS user store that comes with WebLogic Portal, or you can use a user store outside of WebLogic Portal. Examples of an external user store include OpenLDAP or Netscape’s iPlanet. You can connect that provider to WebLogic Portal and the users in that external user store can log into your portal.

This section contains the following topics:

Editing User Information

If you want to be able to edit information about your users, you must configure your external user store to allow write access. If the user store is writable, you can add users, groups, and user profiles that are stored in that user store. See the Security Guide for instructions on setting up external user stores and making them writable.

If the user store is read-only, the properties are visible in the portal but you cannot change them. The default configuration for supported external user stores is read-only access to users and groups from the Administration Console or the WebLogic Server Administration Console. The default RDBMS user store provides write access by default.

Accessing Multiple User Stores

If you have users stored in more than one external user store, you might want to access each of these user stores. WebLogic Portal supports using more than one authentication provider and more than one user store.

Accessing multiple user stores can help you perform the following portal administration tasks:

Tip: Do not store identical user names or group names in more than one user store. If you are storing users, passwords, and groups in an external user store (such as OpenLDAP or Netscape’s iPlanet), you can connect that user store to WebLogic Server (assuming it is a supported type), and the users in that external user store can log into your portals. For example, user dsmith can reside in the default RDBMS user store and in an external RDBMS user store. In this case, WebLogic Portal uses only one user profile for user dsmith.

After you follow the instructions in the Security Guide to develop and configure the external user store, the authentication provider for the user store appears in a drop-down list in the Administration Console. Two authentication providers appear in Figure 2-1.

Figure 2-1 Choose the Authentication Provider from the Drop-Down List

Choose the Authentication Provider from the Drop-Down List

Note: If your external user store contains additional properties for users and groups (for example, e-mail and phone numbers), accessing those properties involves separate development steps to create a UUP. See Configuring a UUP.

Planning to Use a UUP

Use UUP to retrieve additional user profile information from other user stores, such as OpenLDAP servers and databases, legacy applications, and flat files. Using a UUP to integrate existing systems with user profiles provides the following benefits:

Use a UUP to perform the following tasks:

You do not need to use an external data store’s UUP to perform any of the following tasks:

Using a Sample UUP Scenario

Use the following scenario to understand how and when to use a UUP:

  1. You created a new portal application and you want users to be able to log into it.
  2. Your users are stored in an RDBMS user store outside of the WebLogic Portal. You could connect WebLogic Server (your portal application's domain server instance) to your RDBMS system, and your users could log into your portal application as if their user names 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 using a UUP.
  3. You also stored e-mail and phone number information (properties) for users in your RDBMS user store, and you want to access those properties in your portal applications. You must create a UUP for your RDBMS user store to access those additional properties from your code.

For instructions on how to set up a UUP, see Configuring a UUP.


Planning Data Encryption

WebLogic Portal provides two ways to encrypt your sensitive user profile data. You should choose the encryption method in the planning phase, before you begin the development phase. Both WebLogic Portal and WebLogic Server use the 3DES encryption algorithm.

Choose one of the following methods if you want to encrypt user data:

  1. Enable encryption for your user profile property set – Select the Enable Encryption check box to have the Profile Manager encrypt all user profile data in the property set before you send it to the UUP. For more information, see Creating a User Profile.
  2. Use your custom UUP adapter to perform your own encryption – If you plan to have your custom UUP encrypt the data for the property set you specify, do not select the Enable Encryption check box as described in Creating and Updating User Profiles. The Profile Manager sends and receives the data in clear text and encryption and decryption occur at the UUP. (If you do check the Enable Encryption check box, the data is encrypted and decrypted twice, and can impact performance. This type of double encryption is not recommended.)
  3. Having the Profile Manager encrypt the data is the most secure method to encrypt data in WebLogic Portal. However, the Profile Manager manages encryption keys for each encrypted property set. If you want to share your encrypted data across portal applications or domains, you can transfer an encryption key from one custom UUP to another. For instructions, see Transferring an Encryption Key Between Custom UUPs.

    This guide does not provide instructions on setting up encryption at your custom UUP. For information on why you would choose this method, see Encrypting Data by the Custom UUP.

Setting up a Password as an Encryption Key for Your UUP

Using a password as an encryption key to protect your UUP data is the easiest method to set up profile encryption for WebLogic Portal, but it is the least secure. You can use a clear text password or encrypt the password with weblogic.encrypt utility. For instructions on setting a password in the Administration Console, see step 10 in Configuring an LDAP UUP and Transparent Failover.

Note: If you decide to use an encrypted password, your Database Administrator will not be able to view the data in the user profile database. In prior releases of WebLogic Portal, the default was clear text, which meant the Database Administrators could view the user profile data.

Enabling Encryption for a Property Set

When user profile data is retrieved from the UUP adapter, the data is decrypted on the fly. The encryption and decryption are transparent to the profile requester and the UUP. Encryption and decryption are performed at run time when set or get profile data is available through the Portal Administration Portal or profile APIs. Selecting the Enable Encryption check box generates an encryption key if you do not have a key assigned. The encryption key is written to the plan.xml file. If you have group profile data in the same encrypted property set as the user profile, the group profile data is also encrypted.

Select the Enable Encryption check box if any of the following scenarios apply:

To enable encryption for a property set, follow the instructions in step 6 in Creating a User Profile Property Set.

Encrypting Data by the Custom UUP

An alternative encryption method is to set up encryption at your custom UUP. The Profile Manager sends the user profile data in clear text to the UUP and the UUP adapter encrypts the data and stores it. When the Profile Manager requests profile data, the UUP adapter decrypts the data to clear text and returns it in clear text. You do not need to perform additional configuration to your UUP adapter.

Tip: Do not check the Enable Encryption check box (as described in Creating a User Profile Property Set), because that option will encrypt and decrypt the data twice and can impact performance.

Enable encryption for a custom UUP if any of the following scenarios apply:


Upgrading Users and Groups from Portal 8.1

WebLogic Portal Server 9.2 contained a new default SQLAuthenticator authentication provider, which contains an RDBMS user store for users and group membership. The same default authentication provider is used currently.

When you run the Oracle WebLogic Upgrade Wizard, you can choose to upgrade your WebLogic Portal 8.1 SP4, SP5, or SP6, or Portal 9.2 or 9.2 MP1 users and groups or continue to use your existing RDBMS user store in Portal 8.1:

For step-by-step upgrade instructions on running the Oracle WebLogic Upgrade Wizard, see the Upgrade Guide.


Designing Users and Groups for Optimal Performance

Following are guidelines to follow when you create users and groups:

  Back to Top       Previous  Next