iChain User Services is a collection of seven Java servlets that provide a lightweight and easy-to-manage user self-provisioning environment that is based on open standards (LDAP). No Novell client is needed. iChain User Services is designed to replace the legacy (and no longer supported) iChain Community Services.
The user self-provisioning servlets include User Self-Registration, User account modification, Change Password, Password Manager, and Redirect. With the iChain 2.2 release, there are two new features that affect the way passwords can be changed using the iChain servlets: Password Hint and Password Challenge/Response.
Password Hint: Allows users to enter a line of text that will give them a hint if they forget their password.
Password Challenge/Response: Allows users to create a question with a specific answer that, when answered correctly, will allow them to change their passwords without entering the current password.
The Password Hint and Password Challenge/Response servlets are mutually exclusive and either can be enabled at any time. Both features are disabled by default and will not change the basic user services servlets.
The basic services in iChain User Services are provided by the following seven Java servlets (including the two password features described above):
iChainAddUser: A Web-based user self-registration servlet.
iChainModifyUser: A Web-based user account modification servlet.
iChainPasswordChange: Enables users to change their passwords.
iChainPasswordMgr: A password management servlet that provides users a way to change an expired password. The Password Manager checks (and displays for the user) the number of grace logins remaining and provides an automatic destination redirection after the password is successfully changed. If the grace logins have more than one remaining, users have the option to bypass the password change and continue on to their destinations. However, if there is only one grace login remaining, users are forced to change their passwords.
To enable Password Manager, point to the servlet from the iChain Proxy Server by clicking Configure, then clicking the Access Control tab in the Password Management Servlet URL field.
iChainChallenge: A public servlet that lets users create new passwords by entering a correct response to a challenge question. The servlet prompts for a unique ID to identify the user, such as e-mail or cn (configurable in the iChainAppConfig.txt file). The servlet then displays a page that asks the challenge question with an option for the user to create a new password.
iChainChallengeChange: Manages the challenge and response data for the user when the challenge/response feature is enabled. It presents a page that requests the user's current password, along with a new question and response. If the user correctly enters the password, the challenge question and response will be updated for that user.
iChainAddUser$ISOPasswordTemplate: This is an inner class in iChainAddUser.class that holds iChain password policies.
There are two attributes currently defined in the iChainProfiles class named iChainPasswordHint and iChainPasswordAnswer. The iChainPasswordHint attribute is used to store either the Password Hint or the Password Challenge question, depending on which option is enabled. The iChainPasswordAnswer will contain a hashed value of the answer.
Both the iChainPasswordHint and the iChainPasswordAnswer attributes are defined as CI_STRINGS. The values stored in the iChainPasswordAnswer attribute are hashed using an MD5 algorithm in the java.security.MessageDigest class. The resulting byte string is then Base 64-encoded and stored as a string in the directory. The iChainPasswordAnswer value is case-sensitive because it is MD5 and Base 64-encoded.
Upon initialization, the servlets read a configuration file, iChainAppConfig.txt, to customize their functionality to your environment and to easily provide localization (or modification) of all message and error strings. This configuration file also allows you to make any LDAP directory attributes available to the user for user account creation or modification.
NOTE: The configuration file must reside in the same directory as the servlets (where you place the *.class files).
The settings that can be modified using the configuration file are:
The following is an example of the format and syntax making the LDAP attributes of title (job title) and mail (e-mail address) available to the user during account creation or modification:
---------- ---------- ---------- ---------- ----------
# ATTRIBUTES for User Creation or Modification
# Format: <LDAP name>, <"HTML display">, <Required: yes/no>
# Example: givenName, "First Name", yes
# NOTE: "cn", "givenName", "surname", & "userPassword" are
# automatically provided and required by default
# (do NOT list these 4 attributes in this file)
NumberOfAttributes=2
attr1=title, "Job Title", no
attr2=mail, "Email Address", yes
---------- ---------- ---------- ---------- ----------
The attributes can also be designated as required or not required when they are presented to the user during account creation or modification.
The iChainAppConfig.txt configuration file supports auxiliary class attributes. If the attributes you want to list are attributes in an auxiliary class, you will need to add an extra entry at the end of the attrX line as shown:
attr3=commerceAccountID, "Commerce ID", no, commerceAcct
In the example, commerceAccountID is the LDAP attribute name and commerceAcct is the auxiliary class that this attribute is a member of.
Below is the legend from the default iChainAppConfig.txt and a working example of setting an auxiliary class attribute:
#Legend: <LDAPname>, <"HTML display">, <isRequired?>, <AuxClass or 'no'>, <defaultValue>, <isHiddenOnForm?>
NumberOfAttributes=3
attr1=title, "Title", no
attr2=mail, "Email Address", yes
attr3=deframeUserEnabled, "DeFrame User?", yes, deframeUser, true, no
Setting Multiple Attribute on the Same Auxiliary Class: If you are setting multiple attributes on the same auxiliary class, you must specify the auxiliary class name only in the first attribute definition. For example:
NumberOfAttributes=11
attr1=title, "Title", no
attr2=mail, "Email Address", yes
attr3=deframeUserEnabled, "DeFrame User?", yes, deframeUser, true, no
attr4=deframeUserVolatile, "Dynamic User? (true/false)", yes, , true, no
attr5=deframeUserWts, "RDP Protocol? (true/false)", yes, , true, no
attr6=deframeUserIca, "ICA Protocol? (true/false)", yes, , true, no
attr7=deframeUserUseProfile, "Store Registry files? (true/false)", no, , true, no
attr8=deframeUserProfilePath, "Path to profile Storage:", no, ,\\5c\\5c10.1.1.1\\sys\\, no
attr9=deframeUserStoreDocProfile, "Store data files? (true/false)", no, , true, no
attr10=commerceBudgetHolder, "Your BH will be:", yes, commerceAcct, cn=CostCenter1;ou=company1;ou=ods;o=novell;c=us, no
attr11=commerceAccountID, "Account ID:", yes, , 1234, no
In the above example, Attribute 10 shows the syntax necessary for eDirectory object names using semicolons.