Chapter 4   Configuring Membership




Overview

---

Previous versions of the iPlanet Portal Server supplied only a proxy model for authentication. The proxy model integrates well with existing corporate security schemes where authentication databases are independent of the Portal Server. In the iPlanet Portal Server, there are client interfaces to many standard authentication types: UNIX, RADIUS, SafeWord, LDAP, SecurID, NT, etc.

This version offers an additional method which does not rely on a customer authentication database-Membership Authentication. When the iPlanet Portal Server is configured for a consumer audience, the administrator may want them to self-register onto the portal on their first visit. This allows the Portal Server to act as both client and server, instead of accessing an independent authentication database (e.g.: UNIX, RADIUS, SafeWord, LDAP, SecurID, NT, etc.)

The iPlanet Membership Authentication procedure is similar to the my.yahoo.com, my.netscape.com or mysun.sun.com registration procedures. The new user creates an account and personalizes it without the aid of an administrator. Once the new user has created their account, they access it as a registered user with their chosen user name and password, as well as viewer interface, saved on the iPlanet user profile database as authorization data and user preferences.

The administrator may configure and/or customize this module in three ways:

• Look and feel: what is displayed on the new user's screen

• Content: what data is requested from the new user

• Function: how the new user interacts with the data requests.

Functionality

---

The goal of the Membership Module is to self-register new users into the Portal Service framework in a simple manner.

The Membership Module performs the following tasks:

• Requests specific information from the new user

• Requests password twice and performs simple confirmation check

• Places the new user in the administrator-configured default domain

• Creates new user profile

• Stores the user profile in the profile server

The Membership Module does not perform these tasks:

• Modify user profiles

• Allow the new user to re-register in order to change their profile

• Delete user profiles

User Types

---

Three groups interact with the Membership Module: new and registered users, and system administrators.

• New Users: A new user is someone creating a new user ID within the server. New users will need to enter a user name and a password. They can also enter any optional data set by the administrator.

• Registered Users: During subsequent sessions, when the user (now registered) logs in, they only need to enter their user name and password and then select the Login button. A successful login will send them to the desktop.

• System Administrators: The system administrator is responsible for the interface presented to the user, customizing the type and amount of data, as well as changing any functionality of the Membership Module.

Screens

---

Two screens are displayed by the Membership Module:

• Login Screen: This screen requests the user name and password from a registered user. If the user name and password are authenticated by the profile server, the registered user is allowed onto the portal. Users accessing the membership module for the first time should select the 'New User' button which will direct them to the Registration screen.

• Registration Screen: This screen requests data from the new user. The new user registers by completing this form which includes a password confirmation sequence and confirmation of a unique user name. If this is a user's first time, they need to select the new user button. No other input is needed. When their registration is accepted by the profile server, they are directed to the disclaimer page.

User Data

---

There are eleven data fields which are displayed in the Registration Screen. The new user is requested to fill out values for these fields as part of the registration process. The first three data fields are required in the default Membership Module configuration. The default configuration may be customized as described earlier in this chapter.

• Required
  • *User Name

  • *User Password

  • *Confirm User Password

• Optional
  • First Name

  • Last Name

  • Phone Number

  • E-mail Address

  • Street Address

  • City

  • State

  • Zip Code

Components

---

There are three components to Membership Authentication:

• XML Data definition which defines the membership profile:
  iwtAuthMembership.xml

• HTML Form to present the data file to new user for input:
  register.html

• Pluggable Authentication API Properties file:
  Membership.properties

There is a one-to-one relationship between the XML file, the HTML form and the Auth properties file. Each attribute listed in the Auth properties file corresponds to one input element in the HTML form, which corresponds to one attribute in the XML file. There is a one-to-one mapping between the properties file and the HTML file. The attributes listed in the properties file is a subset of the attributes in the XML file.

Customization

---

The default data and interface shipped with the Membership Authentication Module is generic so as to fit into any domain.You may want to configure it to reflect your corporate branding, special data and information specific to your product. There are three ways of customizing the Membership Module:

• Look and feel

• Content

• Function

The administrator may customize the Membership Module as long as:

• The one-to-one relationship of the three files (XML, HTML, Auth Properties) is maintained.

• The elements required by the Membership Module are retained (see requirements section below).

  
  

  ---

  Caution

  Be careful when you make changes to one of these files, you must also change the other two files, so as to reflect the changes across all three files.

  ---

  
  

Look and Feel

To customize the look and feel of the user registration page, the administrator may modify the default HTML files shipped with the iPlanet Portal Server. The default files are membership.html (the login screen), register.html (the new user registration screen), and 12 HTML files used for error screens. The error screens are listed in Memebershp.properties.

Change these files to create a look and feel which follows your corporate branding. Everything is configurable, the gifs, colors, text and fonts, and the layout of the data fields. The default logos are installed in: <installdir>/SUNWips/public_html/images.

---

Note	The images used by the Membership Module are also used in other parts of the product

---

Content

To change which data is requested, which is required, and which is optional, requires, at a minimum, editing the Membership.properties. It may also be necessary to modify the HTML files and the xml definition.

All attributes used by the Membership module are defined in Membership.properties. To add a new field to the registration page, the attribute name must be added to the Membership.properties file, and to the register.html file. The name used in both files is the name defined in the iwtAuthMemberhip.xml file. For example, if the attribute to display was iwtAuthMembership-userAge, the entry in Membership properties would be:

ATTRIBUTE iwtAuthMemberhip-userAge

When a new attribute is added, it not only needs to be put in Membership.properties, but it also must go in register.html. Without this the user would never see the new field. The name used in the HTML file must match the name used in properties file.

To make this attribute a required entry field, the letters "REQ_" need to be prepended to the attribute name.

ATTRIBUTE REQ_iwtAuthMemberhip-userAge

To let the user know which attributes are required and which are not, register.html defines the entries in bold text and with an '*'. While this is not a requirement, it is recommended. It would be impossible for a user to know which fields are required and which are not. Any method for indicating the required fields is allowed, it is not restricted to those used by the default module.

If the data definition supplied with iwtAuthMembership does not meet your needs, it can be altered by adding and removing attributes as needed. Alternatively, a new XML definition can be created and substituted for the default. If this is done Membership.properties, and register.html will need to be updated to reflect the new attribute names. Also in register.html is a hidden field which contains the name of the profile to store the user data. This must be the name of the xml definition you substituted. If a new XML definition issued with the default module, a few required attributes must be present:

password

passwordLength

userName

Function

To allow you to customize the behavior of the Membership Module itself and create your own self-registration module, the code for the Membership Module is shipped with iPlanet Portal Server. This allows you to write a module that, for example, performs tighter password checking, cross-references data-fields or allows multiple screen authentication.

Membership Module Requirements

---

Certain elements required by the Membership Module must be retained. These elements are specified below. They are necessary for the default Membership Module to work properly.

• Required Input
  • Required registration fields are indicated by prepending REQ_ to the attribute name in the HTML file.

• Registration Page Hidden Fields
  • Name of the profile used to store the user data.

  • Attribute name that stores the password minimum length.

  • User name and password.

• Processing
  • A button on the Login page to login to the server.

  • A button on the Login page to redirect to the Registration page.

  • A button on the Registration page to submit the data.

• Error Messages
  • To indicate that the user profile is not found.

  • To indicate that the user name is not found.

  • To indicate that the user password is not found.

  • To indicate that the user has entered the wrong password.

  • To indicate that the selected user name is not unique.

  • To indicate that the user password is not confirmed.

  • To indicate that a required field is empty when form is submitted.

  • To indicate that the user name and password are identical.

  • To indicate that the password and confirm password values are not identical.

  • To indicate a configuration error.

  • To indicate a profile exception within the server.

  • To indicate that the password is invalid.