
	User Management Guide

CHAPTER 5 Managing User Profiles

This chapter describes how to manage user profiles. It contains the following sections:

For more information For an overview of user profiles, see About profiles.

About user profiles

User profiles are persistent collections of data associated with individual users of a Web application. Individual data items within a user profile are called attributes.

For more information For information about attributes, see Profiling with User Attributes

Your Director application can obtain user-specific information and store the information in a profile. It can then later retrieve, act upon, and analyze the information.

The User service API provides methods to create profiles, find profiles, and to store and retrieve user-specific information.

For more information See Using the User API.

The custom Web application in the Portal subsystem includes a core component that creates profiles for users who do not already have one. The source code for the component is provided so that you can use it as a template.

For more information See Using the New User component.

In addition, Director provides a Web tier application that includes a facility for managing user profiles interactively:

For more information See Using the Profiles Section of the PAC.

About managing user profiles

How profiles are managed and stored depends on how the authentication realms are configured in the Directory subsystem. This section explains the differences between how profiles work in LDAP and non-LDAP realms.

For more information on realms, see Understanding Authentication Realms

Non-LDAP realms

Applications that do not include an LDAP realm use a separate repository (database) to store profile information. The same repository is also used to store Portal preferences and ACL-based security information. It is commonly referred to as the application database.

Director applications use the JDBC persistence provider to access the database. When you configure a Director project, you are required to specify the JNDI name for the application database as the Director Framework Datasource. The format of the name you specify depends on the target application server.

NOTE: On an exteNd application server, the application database can be, and usually is, different from the deployment database, which typically is the SilverMaster database.

How profiles correspond to users

The profile database exists independently from the authentication realm. In other words, although user profiles typically correspond to authenticated application users, this is not a requirement. The relationship between profiles and users depends on the design of your application.

For example, a Director application can create and maintain a profile for:

An entire realm
Only users who actually log in (successfully authenticate)
A subset of users based on application-specific criteria

Profiling only users who actually log in is the most typical usage. By default, the Portal Login and New User core components do the following:

Retrieve the profile associated with the UUID of each user who logs in
If no matching profile exists, create a new one

If you need to write custom components that profile based on application-specific criteria, use the Portal Login and New User core components as templates.

How profiles differ from portal preferences

In a non-LDAP realm, the User service stores portal preferences information in addition to profiles. These preferences (portal pages, portal defaults, portal components, and so on) are stored in separate tables within the application database and are understood and managed by the Portal manager in the Portal service; the User service in this case is functioning only as a storage service.

In earlier versions of Director, the User subsystem API contained classes for managing portal preferences. In other words, portal preferences were considered to be part of a user profile. In Director 4.0, these classes moved to the Portal subsystem API. Their names, however, have not changed. Thus, when using the Portal API, do not be confused by class names that contain the word profile.

LDAP realms

In applications that use an LDAP realm, profile information is stored within the LDAP directory, not within the application database. (That database is used only for Portal preferences and ACL-based security information.)

Director uses the JNDI persistence provider to access the LDAP directory. When you configure a Director project, you specify the information needed to access the LDAP directory server.

For more information on configuring LDAP realms, see Configuring an LDAP realm

How profiles correspond to users

In applications that use an LDAP realm, the realm itself is the profile database. In other words, within an LDAP container, profile information and authentication information are stored in the same user record.

The behavior of the Portal Login and New User core components depends on how the LDAP realm is configured. If you need to write custom components for these purposes, use the Portal Login and New User core components as templates.

Using the New User component

The New User component is one of the core components used in the custom Web application. It allows anonymous users to add themselves to the writable realm and automatically creates a profile for each new user.

The New User component is provided as a template for your own application. You can copy and customize the New User component or design a new one.

NewUserComponent

The New User component does the following:

Adds a user name and password to the writable realm (if enabled)
Creates a user profile identified by the combination of the user's realm name and an automatically generated 32-bit UUID
Adds some default attributes to the profile

The source file for the New User component is in your Director project directory:

  Portal\WEB-INF\lib\portal-core-resource\src\com\sssw\portal\
      component\core\NewUserComponent.java

Using the User API

The User service provides API access to user profiles. Topics in this section include:

Checking the realm configuration

Director allows you to reconfigure an application to use a different authentication realm. If you expect to do that, consider writing component code that is general enough to work with both LDAP and non-LDAP realms. To do so, you need a way to determine which realm is in use at run time. To find out whether or not your application is configured for an LDAP realm, use:

  EboUserHelper.getUserDataStore()

This method returns a string value indicating whether the User service uses JNDI (LDAP directory) or JDBC (application database),

Checking for a writable realm

To find out whether or not your application is configured for a writable realm, use:

  EboUserHelper.isReadOnlyUserSchema()

This method returns a boolean value indicating whether or not the User service schema is modifiable. A JDBC schema can be readable or writable but a JNDI schema is not modifiable within Director.

Creating a new profile

This code shows how the New User component adds a user profile:

  //
  // Get a profile delegate from the user service
  //
  EbiUserDelegate userDelegate =  
      com.sssw.fw.usermgr.client.EboFactory.getUserDelegate();
  //
  // Instantiate an empty profile object for this user
  //
  EbiUserInfo userInfo = (EbiUserInfo)userDelegate.createUserInfo();
  //
  // Add profile info (default attributes) for the user
  //
  userInfo.setUserID(m_uid);
  userInfo.setUserFirstName(m_firstName);
  userInfo.setUserLastName(m_lastName);
  userInfo.setUserEmailAddress(m_email);
  userInfo.setUserAuthenticatedRealmName
      (dirService.getPrimaryRealmName());
  //
  // Add the new profile
  //
  boolean status = userDelegate.createUser(context, userInfo);

Looking up user profiles

The User API includes user query and user metadata query classes that you can implement to retrieve a list of user profiles that meet certain criteria.

For more information, see EbiUserQuery and EbiJndiQuery in the API Reference.

Getting a user profile

This code shows how to obtain and display a user profile:

  import com.sssw.fw.usermgr.api.*;
  import com.sssw.fw.usermgr.client.*;
  
  try {
      //
      // Get the user identifier
      //
      String userUUID = EboUserHelper.getUserUUID(context);
      //
      // Get a user delegate object from the factory
      //
      EbiUserDelegate userDelegate = EboFactory.getUserDelegate();
      //
      // Get a user info object
      //
      EbiUserInfo userInfo =
          (EbiUserInfo)userDelegate.
              getUserInfoByUserUUID(context,userUUID);
      //
      // Get the registration info and add to output buffer
      //
      sb.append("UserID: " + userInfo.getUserID() + "<br>");
      sb.append("UserUUID: " + userInfo.getUserUUID() + "<br>");
      sb.append("UserFirstName: " + 
          userInfo.getUserFirstName() + "<br>");
      sb.append("UserLastName: " + 
          userInfo.getUserLastName() + "<br>");
      sb.append("UserEmailAddress: " + 
          userInfo.getUserEmailAddress() + "<br>");
  }
  catch (EboFactoryException e) { sb.append( e.getMessage() ); }
  catch (EboSecurityException e) { sb.append( e.getMessage() ); }

GetUserInfo1


	User Management Guide