A CORBA compliant service and its interface description are required to authenticate users. This service shall provide services to a client application including the creation of user accounts, the modification of user accounts (including the addition, deletion or modification of an arbitrary number of user attributes), the deletion of user accounts, and the logging of current users.

A generic database interface description will be provided so as to allow the use of different external database formats for persistent data.

In the case of user login, the service compares the requested information to that stored in an external database. On a successful comparison, the service will make the user access level available to the requesting entity.

The program will send CORBA events to the ORB to be used by external applications. These events may contain user state information as well as user exceptions. Some initial events will be that a user was added; a user's configuration was changed; a user was deleted; a user logged on; a user changed his password. These events are for use by applications such as those which track unauthorized access attempts or monitor all login activity (including which user has logged in to the system at what time).

As part of the design phase of this project, NAU Motorola team will provide the interface description written in IDL for the subsystem to Motorola. The IDL will describe the methods used for the following required operational scenarios:

1. Login scenario:
   • User starts up the application and is requested to login via a popup window, entering a login name and password Login is validated
   • If successful, access to appropriate actions is given, depending on user level
   • If unsuccessful, user is asked to retry


2. Create a User :
   • User wishes to create a new user
   • User enters information for user and saves it


3. Modify a User:
   • User selects a user to modify
   • User modifies information and saves it


4. Delete a User:
   • User selects a user to delete
   • User is asked to verify deletion
   • User is deleted from database
   
   
5. Another system component gets a user attribute
   • Component requests value for user attribute
   • User subsystem returns value


6. Another system component sets a user attribute
   • Component requests to set value for user attribute
   • User subsystem stores value

Other Requirements

1. The data will actually be persistent (stored) via a database to which NAU Motorola team will provide an interface written in IDL



2. The following data should be available for a given user
   • Login name
   • Full User name
   • Password (appropriate sensitivity to visibility should be given)
   • User access level other attributes stored as (name, value) pairs
   • (Ex: fax, pager number, email address). There is no limit to the number of these that may be stored.


3. There should be an easy interface for managing the additional (name, value) pairs. These may be used to store user preferences.



4. User access levels should be able to be configured, added or deleted.



5. All scenarios above will generate events (via CORBA event services) that may be monitored by other components.