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:
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:
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 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.
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.
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:
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 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:
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.
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 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.|
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 inin Creating a User Profile Property Set.
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:
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.
Following are guidelines to follow when you create users and groups: