Skip Headers
Oracle® Fusion Middleware User Management Guide for Oracle WebLogic Portal
10g Release 3 (10.3.4)

Part Number E14254-02
Go to Documentation Home
Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

1 Introduction

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.

Figure 1-1 Authentication Providers and User Stores

Description of Figure 1-1 follows
Description of "Figure 1-1 Authentication Providers and User Stores"

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 Derby 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:

1.1 Introducing Users and Groups

This section contains the following topics:

1.1.1 Understanding Users

Oracle WebLogic Portal supports two types of users:

  • Portal administrators – Manage portal content and portal users, and build portals with existing portal resources

  • Portal end users (visitors) – Use the portals assembled by the portal administrator

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 Oracle Enterprise Pack for Eclipse (OEPE) 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 Oracle Fusion Middleware Security Guide for Oracle WebLogic Portal.

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 Section 1.1.3, "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 Chapter 6.

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:

  • User ID – For an anonymous user, a user ID is a unique number that follows the actions of tracked anonymous profiles. A User ID is used because the user is not registered.

  • Credential – An authentication token, such as a password or certificate.

  • Principal – When capitalized, Principal is a Java object. For example:

    • A Principal object represents the abstract notion of a principal, which can represent an entity, such as an individual, corporation, or a login ID.

    • A Subject object (which maps to a user) can hold multiple Principals.

    • In WebLogic Security, Principal objects map to groups and also IDs.

  • Username – A user attribute, such as a user's name. It can also be a string (for example, username = String to display on the Welcome page).

1.1.2 Understanding User Profile Types

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:

  • Registered – A fully-registered user who can be authenticated with the system.

  • Anonymous – A user who does not have an identity with the system.

  • Tracked Anonymous – A user who is recognized by WebLogic Portal but is not registered. The user has an identity but cannot authenticate with the system.

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 Chapter 7 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. Implementing Security and User Profiles

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 Oracle Fusion Middleware Security Guide for Oracle WebLogic Portal for instructions.

1.1.3 Accessing Users

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:

  1. Internal User Store – You can use the default SQLAuthenticator authentication provider to access the RDBMS user store that comes with WebLogic Server. The default RDBMS user store contains users and group membership. Security roles and policies are stored separately in the Lightweight Directory Access Protocol (LDAP) server.

    The default RDBMS user store supports the following access and storage functions:

    • Performs read and write access by the WebLogic Security providers

    • Creates, reads, updates, and deletes entries in the RDBMS server

Figure 1-2 The SQLAuthenticator is the Default Authentication Provider

Description of Figure 1-2 follows
Description of "Figure 1-2 The SQLAuthenticator is the Default Authentication Provider"


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 Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Portal for instructions on running the script.
  1. External User Store – WebLogic Portal also supports using external user stores that contain users and group information. External user stores can include OpenLDAP, Netscape iPlanet, Novell NDS, or Microsoft Active Directory, and other RDBMS user stores.

    Using more than one user store can help you perform the following portal administration tasks:

    • Users in external user stores can log into your portal desktops.

    • When external users and groups appear in the Administration Console, you can define access to applications through personalization rules that are based on users and groups and their profile properties.

    • You can entitle users in an external user store to specific portal resources when they log in. You can define visitor entitlement rules based on external users and groups.


      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 Section 2.2, "Planning Your Groups and Group Hierarchy" for general information.

1.1.4 Using Groups and Group Hierarchy

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:

  • Organize a related group of users, such as a department, team, or regional office

  • Locate users

  • Set up delegated administration and visitor entitlement to control what users can see in your portal and the actions they can perform

  • Work with large sets of users at one time

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 Section 8.3, "Editing a Group Profile."

See Chapter 2 for detailed information on developing a user management strategy that can save you time during the Development, Staging, and Production phases.

1.2 User Management in the Portal Life Cycle

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 Oracle Fusion Middleware Overview for Oracle WebLogic Portal.

1.2.1 Architecture

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:

1.2.2 Development

In the Development phase, developers use Oracle Enterprise Pack for Eclipse 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: Oracle Enterprise Pack for Eclipse and the Java API.

The following chapters provide guidance on Development tasks:

1.2.3 Staging

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:

1.2.4 Production

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.

1.3 Getting Started

If you are new to portal development, see the Oracle Fusion Middleware Overview for Oracle WebLogic Portal for more information about the portal life cycle.

You can also consult the following information: