eQuest Intranet/Extranet

    Log-In and Self-Registration

    Version 1.0.1

1. Goals.

? 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

    required to acknowledge a privacy policy shown in a scrolling list box in the self-registration

    eQuest Log-In and Self-Registration – Page 1

    confirmation page. This privacy policy will be retroactively applied to all pre-existing eQuest

    users.

? Upon internal user self-registration, selective user fields will be copied into the eQuest users

    table.

? 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

    “VIEW_SECURITY_DATA”.

? 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.

A. Login.

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.

    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.

    Figure 2.

    eQuest Log-In and Self-Registration – Page 3

    Figure 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

Figure 4.

eQuest Log-In and Self-Registration – Page 5

    Figure 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

    entries).

    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) –

    Mike Miller

? 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

    bring across.

? 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