Security

Security within the SPIRIT application suite can be categorized into the following three specific areas: Session, Authentication, and authorization.

Session

A session is defined as the time span between logging on and logging off the system. The SPIRIT application suite requires that a user authenticate their identity by providing login credentials. If a user authenticates successfully, they must also have the appropriate authorization to access a requested function from within the SPIRIT application suite.

Authentication

Authentication refers to the user's ability to gain access to the system based on their credentials. When a user attempts to access an executable image that requires data from the SPIRIT application's database, the user must provide credentials by supplying the appropriate user ID and password when prompted. This is accomplished via the Login screen. The Login screen is displayed at the beginning of a session.

After the user provides their credentials the system must check that the user's record exists. This is done by performing a check to see if the user ID that was provided matches an existing record in the USERID column of the USERPROFILE table. If a matching record exists, then the password that was provided is cryptographically matched to the PASSWORD column of the USERPROFILE using the industry standard Triple Data Encryption Algorithm in order to prevent malicious detection of the user’s credentials. Passwords are stored in an encrypted format in the database. If the user's password authenticates then the WIC Session Manager is started and the user's authorizations are checked for the executable they are attempting to access; otherwise the user is not logged into the system.

This section describes the screens that are displayed when the OK button is clicked and the user attempts to log into SPIRIT application.

Authorization

Authorization is best described as the process of verifying that a function is accessible when a user has the appropriate access level(s) to all features that comprise that function. This is controlled by assigning users to locations to establish staff member relationships. Staff members are then assigned one or more roles thereby establishing the authority a user may assume while acting as a staff member of a particular location.

As stated above, one or more roles can be assigned to a staff member. Roles are global in nature as they can be assigned to more than one user within the organization. Examples of roles are: Nutritionist, Clerk, Administrator, etc. Each role has a comprehensive list of all permissions in the system. Permissions are a combination of feature and access level. Features are abstract statements that can be related to functionality in the system. An example of a feature would be "Participant Demographics" (this would map to the presentation of participant demographic information within the system.) The access level associated with features can be set to one of the following: None, View, Add, or Full control. In this case, None would prohibit the role from viewing participant demographic information while View would restrict the role to a read-only view of the information. Add would restrict the role to adding participant demographic information while Full control would allow the role to View, Add, Edit, and Delete the information. Since each role has a comprehensive list of features, the access level must be set for all features in order to define the permissions for the role. By default a new role has no permissions. This is accomplished by defaulting all features to an access level of None. Note that if the permissions for a role are changed, all staff members assigned that role will inherit the changes.

The permissions given to a staff member are a combination of the highest permissions across all the roles assigned to the staff member. Consider the following example:

Jane Smith is a staff member assigned to a Clinic. She assumes the roles of Clerk and Administrator for the clinic (via her staff member profile). The role of Clerk has been granted full control of Participant Demographic Information while the role of Administrator is only able to view Participant Demographic information. Jane is granted full control of Participant Demographic Information since the access level granted to the Clerk role (full control) overrules the lower access level granted to the Administrator role (view). Note that if the Clerk role was removed from Jane's staff member profile she would only be able to view Participant Demographic Information.

This Authorization model allows for a user to be defined to a specific agency as an administrator and to a specific clinic as a Clerk (or any combination of the two). This model has value in that it allows the system administrator to define explicit access at a location level.

In order to make any modifications to the participant's information, the participant must be transferred into the clinic that is servicing the participant at that point in time. (This is required in order to provide caseload and dual participation information.) In order to satisfy this requirement, users are required to select a specific location (in this case a clinic) as the current location. Establishing this relationship allows the system to prompt the user to transfer the participant when appropriate.

In order to allow the user to select from all clinics and subsequently work as a staff member of the clinic, the system creates a staff member relationship to each clinic location for users that perform the role of Clerk at a clinic.

Sample Permissions

The system will log attempts by users to access applications for which they do not have sufficient privileges. For example: if a user whose role is nutritionist attempts to start the Data Synchronization Client application but the permission for that role is set to "None", the attempt to start the application is logged. The information will include the user ID, application name, as well as the date and time of the attempt.

Clerk

Administrator

Definitions

The following definitions are provided in order to help the user understand the Security philosophy that has been implemented within the SPIRIT application suite:

Access Level - Access level refers to a state of privilege or permission feature. The SPIRIT application has four (4) access levels that grant elevated privilege. The access levels are "None", "View", "Add", and "Full" which are located in the ACCESSLEVEL table.

Descriptor - Human readable data that assigns meaning.

Feature - A feature is a security descriptor. The features available in the SPIRIT application are located in the FEATURE table.

Feature Group - A logical set of features that are grouped together that identifies what SPIRIT application system the features that are a part of the feature group belong to. Features Groups are located in the Reference Dictionary table (CATEGORYID = "FEATUREGROUP").

Location - A geographic descriptor that identifies a work place where WIC related business is conducted. Locations are located in the LOCATION table.

Permission - Permissions define an assignable relationship between an access level and a feature. Permissions provide the context necessary to determine what a user has access to. Permissions are located in the PERMISSION table. Each feature in the SPIRIT application has at most 4 access levels.

• A permission with an access level of "None" means that the user does not have any access to the feature assigned to the permission. This is the default level of privilege.

• A permission with an access level of "View" means that the user has read-only access to all data related to the feature assigned to the permission. The user can view data related to the feature. The user cannot add new data, delete existing data, or edit existing data related to the feature.

• A permission with an access level of "Add" means that the user has commentary access to all data related to the feature assigned to the permission. The user can view and add data related to the feature. The user cannot delete or edit existing data related to the feature.

• A permission with an access level of "Full" means that the user has editorial access to all data related to the feature assigned to the permission. The user can view, add new data, delete existing data or edit existing data related to the feature.

Role - A role is an assignable security descriptor that can have permissions assigned to it. Roles are located in the ROLE table.

Role Permission - A logical relationship between a role and permission. This relationship is located in the ROLEPERMISSION table.

User Location Role - A logical relationship between a user, their work location, and role. Basically, users are assigned roles and locations together in order to identify what functions they have access to at their respective work locations. This relationship is located in the USERLOCATIONROLE table.