Log-In and Self-Registration
? To revise the eQuest log-in procedure to utilize CT domain authentication for internal users
and leverage internal user’s existing domain logon attributes thereby eliminating the need to
maintain a separate user id and password for CT users and duplicate the maintenance of
their user attributes within eQuest.
? To expedite access to eQuest through a self-registration procedure for internal users and to
simplify access for external users through a registration self-request procedure.
2. Definition of Terms.
? Internal User – any CT employee or contractor that possesses a CT domain login for
accessing the company network inside the firewall or through a secured VPN connection.
? External User – any third-party partner employee that does not have a CT domain login and
would only be able to access CT applications through an Extranet server.
? Intranet – An internal, private Web site for a business that is used internally by the employees.
? Extranet - An intranet web site that is accessible from the Internet through a firewall.
3. Decisions and Assumptions.
? Siteminder will continue to protect all sites and all users will continue to be required to
explicitly sign-on to eQuest to achieve authentication and access.
? Intranet and Extranet access will be provisioned from the same server running a single code
base through a single URL.
? The eQuest NetScape LDAP group (“EQT”) will be revised to only contain authentication
entries for external users. These entries will be modified to use the user’s email address as
the user id. This will enable all internal user CAI’s to be able to be used as eQuest ID’s. All
internal user entries will be removed from this LDAP.
? All internal users will authenticate using their CT domain logins – whether accessing eQuest
from the intranet or the Extranet
? The Siteminder policy server will use a cascading set of authentication modes – the CT
domain followed by the NetScape LDAP and then any legacy domains (not yet converted to
CT) as required.
? eQuest will be allowed to use the CTN4a object for access to a specified internal user’s
personal information required for their self-registration (First Name, Last Name, Phone, Email,
Company, Country). This information will only be available following authentication to internal
users accessing eQuest from the Intranet. To address privacy concerns, each user will be
eQuest Log-In and Self-Registration – Page 1
? Upon internal user self-registration, selective user fields will be copied into the eQuest users
? As each user joins a new instance, they will receive the “BASE_PUBLISHER_USER” role.
This role will grant access to 3 tasks: “VIEW_AOI_NAVIGATION”, “VIEW_PUBLISHER” and
? All eQuest administrative functionality will be disabled when running from the Extranet.
Administrators will be able to access these functions remotely through a VPN session.
Ramification – need to be able to query header variables to determine is session is running
inside or outside.
4. High Level Design.
All users will see the same login page and will be required to enter their user name and
passwords. Internal users will enter their CT CAI and current CT password while external users
will enter their email address and passwords. The user input will be processed against the
cascading authentication modes defined above.
Invalid login attempts (invalid user id and/or password) will simply redisplay the login page.
New internal users can self-register or new external users can request registration by clicking on
the one of two new links at the bottom of the login page: Internal User Self-Registration or
External User Registration Request. The revised login page (login.fcc) is depicted in Figure 1.
eQuest Log-In and Self-Registration – Page 2
B. Internal User Self-Registration.
Upon selection of the Internal User Self-Registration the user will be directed to the InternalSelfRegisterLogin.fcc page (outside the firewall in the eQuest Public folder) for
authentication as a valid CT internal user (depicted in Figure 2). This page should only be able to
authenticate against the CT and legacy domains (not the LDAP). Following authentication the
user will be directed to the InputForInternalSelfRegister.asp (inside the firewall) page (depicted in
Figure 3). This page will look up the authenticated user’s attributes using the CTN4a object (First
Name, Last Name, Phone, Email, Company, Country) and display this back to the user for
validation. Following selection of an initial instance and submittal, the user will be added to the
eQuest user model and then immediately directed to the eQuest Start page where they
immediately can begin using the application.
eQuest Log-In and Self-Registration – Page 3
C. External User Registration Request.
The External User Registration Request process will use a set of ASP pages that execute outside
the firewall from the eQuest Public folder. The External User Registration Request link on the
sign-on page will direct the prospective user to a new page called
“InputForExternalRegRequest.asp (depicted in Figure 4). Upon submit of this page the
prospective user will be directed to a new page called “ConfirmExternalReg.asp” (depicted in
Figure 5). This page will send a formatted email message, using the ASPMail component, to the
prospective user and will display the information they entered along with a “thank you” message indicating what will happen next. Upon receipt of the email message the prospective user will
forward the message to a CT sponsor. The prospective user must know the email address of a
sponsor from their prior, professional contacts. Upon receipt of the forwarded email message,
the designated sponsor will review the request and decide whether to approve the request or not.
If approved, the sponsor will forward the email message to a valid eQuest site administrator for
the specified instance. The administrator will then add the user as an external user using the
“Security/Create User” page.
eQuest Log-In and Self-Registration – Page 4
eQuest Log-In and Self-Registration – Page 5
D. Users Table – Metadirectory Synchronization.
Since the user attributes for internal users will no longer be maintained in the eQuest “USERS” table, these attributes will need to be synchronized with the MetaDirectory on a regular basis.
These attributes will be read-only in eQuest. An Oracle procedure will be developed that will
refresh the user attributes in the eQuest “USERS” table using the corresponding fields from the
Oracle Metadirectory table. The procedure will be scheduled to run at least nightly.
E. User Maintenance.
The pages that maintain eQuest user attributes will need to be revised as follows to
accommodate the new design:
? Admin Tools/Reset User LDAP Password - This link will be renamed to Reset External User
Password but will otherwise function as-is.
? Admin Tools/Delete User From All Instances – This will function as-is except that it will no
longer delete a Netscape LDAP entry for internal users (they won’t have Netscape LDAP
eQuest Log-In and Self-Registration – Page 6
? Security/My Info/Change Password – This link will now only be displayed when the logged on
user is an external user.
? Security/Modify Security/Create User – The security side list (SecuritySideList.asp) will be
modified to have two links, “Create Internal User” and “Create External User”. This will
enable the validation of the proposed new eQuest user id against the appropriate user store
(MetaDirectory or Netscape LDAP respectively).
? Internal Users -The specified user id will be used to query the MetaDirectory using the
CTN4a object returning the applicable user attributes which will be displayed (read-only)
in the Create User page. The only attributes that will be selectable for a new internal
user are Roles and MBP’s Owned.
? External Users – The specified email address will be used to query the NetScape LDAP
to validate the user id is available (not already registered). The Create User page will
require the input of all the user’s attributes in addition to the Roles and MBP’s owned.
? Security/Modify Security/Edit User – The page for entering the user id will query the eQuest
Users table to determine that the user exists and then direct to the Edit User page. If the
user being edited is an internal user the user attributes will be read-only – if external then
they will be editable (because they will be maintained through this interface).
? Security/Modify Security/Delete User - This will function as-is except that it will no longer
delete a Netscape LDAP entry for internal users (they won’t have Netscape LDAP entries).
F. User Lists and Reports.
Since the structure of the “USERS” table will remain basically unchanged, this design eliminates
the need to revise any of the user reports or pages that list users. However, to minimize user
data privacy concerns these pages will be reviewed and any unnecessarily displayed user
attributes will be removed.
G. Release Implementation Tasks and Action Items.
? Completion of new GAP test server – Shared Server.
? Completion of new GAP cert(production) server – Shared Server.
? Setup of dual mode web site configuration (Intranet/Extranet) – Shared Server
? Consulting and configuration for the new Siteminder Public folder pages - Andrew Hardiman.
? Acquisition and integration of new CTN4a object (prototype currently using CTN3 object) –
? Development of a user personal data privacy statement - IP specialist.
? Incorporation of the IP policy acceptance – IP specialist.
? Pre-code freeze integration and system testing and code refinement – Mike Miller
eQuest Log-In and Self-Registration – Page 7
? Business unit External user account review and summarization – Jeff and Mark?
? Development of USERS table cleanup routines (convert external user ids to email addresses,
implement hard passwords for external user ids, make internal/external flag assignments, pull
current Metadirectory attributes for internal users, delete unused and invalid user accounts) –
Mike Miller, Mark O’Neill
? Development of the USERS table synchronization procedure -Don Meyer.
H. Current Discussion Items.
? External user account validation – strategy for determining which external user accounts to
? External user id (Netscape LDAP) hard password and account expiration policy
implementation – Should this be done in this release? I think so.
eQuest Log-In and Self-Registration – Page 8