This guide describes how to add and manage users and groups in your portal application. A user can be a portal administrator or a portal end user (a visitor or a registered user). Each user is given a unique identity within a security realm. A group is a collection of users who usually have something in common, such as working in the same department. Create users and groups to simplify user management and administration.
You can add and manage portal users and groups using any of the following methods:
These internal and external user stores are accessed from Oracle Web Logic Portal through the WebLogic Security Service Provider Interface (SSPI) Authentication Providers. An authentication provider uses the username and password to find and authenticate a corresponding user in the user store.
Figure 1-1 shows how authentication providers and user stores work together.
The guide also contains instructions for creating user profiles to retrieve other information about users, such as phone number, e-mail address, country, and so on. This user profile information is used to create personalization features that display customized content or guide users through a process.
WebLogic Portal uses the default PointBase Relational Database Management System (RDBMS) database that ships with WebLogic Server. During the installation, WebLogic Portal installs demonstration user accounts and data into the WebLogic Server default database. You can also store user information externally and manage these attributes through a Unified User Profile (UUP). You can also track anonymous users (users who have not yet registered) to get information about these portal visitors and display customized content for them.
This chapter includes the following sections:
This section contains the following topics:
Oracle WebLogic Portal supports two types of users:
A portal administrator can simplify management tasks by combining users into groups and subgroups. An administrator with full management rights can add, edit, remove, or move users and user profile properties programmatically in Workshop for WebLogic or in the WebLogic Portal Administration Console.
You can access existing users through internal or external user stores. An internal RDBMS user store is included when you install WebLogic Server and WebLogic Portal, and it uses the SQLAuthenticator as the authentication provider. You can also access more than one external user store that contains your users, so you can select users and groups from multiple user stores. For instructions on setting up external user stores, see the Security Guide.
In addition to retrieving users stored in the external user store, you can also add users to the user store (if the user store is writable) using WebLogic tools or you can add users directly to the user store itself. See Accessing Users for more information on authentication providers and user stores.
When you add a user, WebLogic Portal creates a user profile that contains the user’s identity (name and password). Other user properties (such as address, phone number, e-mail, hobbies, and so on) can be added to the user profile to set up personalization and define rules for delegated administration and visitor entitlement. Personalization allows you to target users with customized content that enhances the user’s interaction with your portal. Delegated administration and visitor entitlement control what the user can see or do in your portal.
If you have external data stores that contain additional information about users and groups, accessing those properties involves separate development steps to create a UUP. For more information on integrating these external systems with user profiles, see Configuring a UUP.
WebLogic Portal also contains tracking tools to find out more about visitors to your portal, such as the date and time they visit and information in the request or session. This anonymous user tracking helps you present personalized content to an unregistered user over multiple sessions.
WebLogic Portal uses the following terminology to describe users:
username = Stringto display on the Welcome page).
A user profile can store and retrieve additional information about users, such as phone number, e-mail address, country, and so on. You can use this information to create personalization features that display customized content or guide users through a process.
WebLogic Portal supports three kinds of user profiles:
The user profile is stored in the session by default. The profile is usually initialized on the user’s first visit to the portal. At the same time, an anonymous profile or a tracked anonymous profile is initialized in the session on first access (if user tracking is enabled and the request has a valid tracking cookie). See Setting Up Anonymous User Tracking for instructions on setting up anonymous users.
If the user logs in (authenticates), the session initialization process switches the profile with the user's registered profile. If the user registers with the system, a registered profile is created that is initialized with values from the tracked anonymous profile, and the profile is placed in the session.
In addition to storing valuable information (attributes) about users, you can also use user profiles to implement portal security. When you use visitor entitlement to limit user access to portal resources (desktops, books, pages, portlets, and other resources), the visitor entitlement policy can be defined with user properties. For example, you could create a visitor entitlement role called manager that determines if a user who logs in has an employee_type property with a value of manager, then that user belongs to the manager role. You could then select a portlet and set its visitor entitlement to the manager role. When a manager logs in, the manager sees the portlet. If a non-manager logs in, the user does not see the portlet.
You can also create delegated administration roles using user profile properties. See the Security Guide for instructions.
When you add a user to WebLogic Portal, you add the user to the user store. WebLogic Portal supports two places (both of which use SSPI) to store users:
|Note:||The RDBMS user store that shipped with WebLogic Portal prior to version 9.2 has been deprecated and it not automatically upgraded to 9.2 or later versions. If you installed and used the Portal version of the RDBMS user store, you can upgrade it with a migration script. See the Upgrade Guide for instructions on running the script.|
|Note:||WebLogic Portal supports the use of multiple user stores or authenticators. When you use more than one authenticator, you can configure each authenticator differently to allow flexibility in authenticating the users. The authenticators can require the user to be authenticated in one authenticator, some of the authenticators, or all of the defined authenticators (depending how they were configured).|
You can add users to an external user store with WebLogic Server Administration Console, WebLogic Portal Administration Console, or by adding a user directly to the user store. You can encrypt sensitive user data in external UUP user stores; see Planning Your Groups and Group Hierarchy for general information.
A group is a collection of users. Creating groups and placing users in groups can help the portal administrator simplify user management and administration. A subgroup (child group) is a subset of a higher-level group (parent). Organizing users into groups and subgroups that look like your organization can make it easier to manage users.
Creating groups and subgroups can help you perform the following tasks:
Administrators with full group management rights can add, remove, move, and change group profile properties in the WebLogic Portal Administration Console. For more information, see Editing a Group Profile.
See Planning a User and Group Strategy for detailed information on developing a user management strategy that can save you time during the Development, Staging, and Production phases.
This section contains the following topics:
The tasks in this guide are organized according to the portal life cycle. The portal life cycle contains four phases: Architecture, Development, Staging, and Production. Adding and managing users and groups is part of the portal life cycle. For more information about the portal life cycle, see the WebLogic Portal Overview.
Figure 1-3 lists some of the user and group management tasks in each phase.
In the Architecture phase, you plan how to organize and access users and groups stored in internal or external user stores. You can decide if you want users to register themselves when they visit your portal application. If you plan to retrieve user profile information from multiple systems, you can use UUP to perform this integration. If you want to edit that user profile information in the Administration Console, you must make the information writable in the user store. Your strategy for organizing users and groups is different from the strategy you use to create roles and visitor entitlement. Roles and entitlements are used to control what users can view and do in your portal.
The following chapter provides guidance on Architecture tasks:
In the Development phase, developers use Workshop for WebLogic to create JSP tags and controls that allow you to add users or let users add themselves to your portal. Developers can also programmatically create groups and subgroups, set up user profiles and properties, create a UUP, and track anonymous users. Developers can choose to implement user roles with declarative security with roles and entitlement (using the isAccessAllowed() method) or programmatic security (with the isUserInRole() method). Declarative security is easy to change and manage. Programmatic security is often coded into portlets, books, and pages and is more difficult to modify.
Tools: Workshop for WebLogic and the Java API.
The following chapters provide guidance on Development tasks:
In the Staging phase, you can add administrative users to a staging environment to test the functionality you created in the Development phase. You can also test user profiles and UUP in this phase to verify that they are collecting additional information about users. The Development and Staging phases often occur simultaneously. You might move iteratively between these two phases, developing and then testing what you created. If you return to the Development phase and make changes, you must redeploy your portal application to see the changes in the Staging phase. If you plan to use more than one development team to create your portal, determine how you will merge and assemble the code.
The following chapters provide guidance on Staging tasks:
After you test your portal application in the Staging phase, use the Production phase to perfect your production environment. In the Production phase, for example, you might use the Administration Console to fine tune your portal application, such as adding or moving a group or an administrative user, removing a user or group, adding a desktop, and creating community users and groups.
If you are new to portal development, see the WebLogic Portal Overview for more information about the portal life cycle.
You can also consult the following information: