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. 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.
  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 BEA 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 BEA Workshop for WebLogic Platform 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 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 Server, or you can use a user store outside of WebLogic Server. Examples of an external user store include OpenLDAP or Netscape’s iPlanet. You can connect that provider to WebLogic Server 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.

 


Upgrading Users and Groups from Portal 8.1

WebLogic Server 9.2 contains a new default SQLAuthenticator authentication provider, which contains an RDBMS user store for users and group membership.

When you run the BEA WebLogic Upgrade Wizard, you can choose to upgrade your WebLogic Portal 8.1 SP4, SP5, or SP6 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 BEA 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