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:
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:
For instructions on creating groups and users in the Administration Console, see Adding and Managing Groups and Adding and Managing Users.
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:
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.
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.
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:
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.
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.
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. |
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:
Use the following scenario to understand how and when to use a UUP:
For instructions on how to set up a UUP, see Configuring a UUP.
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.
Following are guidelines to follow when you create users and groups: