Purpose

To maintain the set of available self serve user categories

SubSystem

Callista Connect

This form is used to maintain the available set of Self Serve User Categories for use with Callista Connect applications. Each user category represents a group of users with common attributes, such as Enrolled Student, Course Applicant, Administrator or Public. When Callista Connect applications are accessed, the System determines the associated user category/ies, and the Authentication and Mapping Methods associated with each category. This enables the user to be authenticated based on data input via the application login page.

• Self Serve Access Inquiry Code, such as ADMIN (Administrators), SEC-ADM (Secured - Admission Applications), SEC-ENR (Secured - Student Applications) or PUBLIC (attached to user categories in the Maintain Self Serve Access form (SSFF1600)).
• Mapping Method, such as ORACLEUSER (Person Oracle User Name) or Callista User ID/Password.
• Authentication Method, such as ORACLEUSER (Oracle Database User), Callista User ID/Password or LDAPBasic. Each Self Serve Authentication Method is also associated with one or more Authentication Configurations that define the server or database connection for the user.
• Input codes, such as user USERID (User ID) or PASSWORD prompt the user for input details for authentication.

Typical Self Serve User Category set-up

Typically, each user category is associated with a single authentication method and mapping method. For example, the category ENROLLED (Enrolled student) may be assigned the Authentication Method CALLISTAID and Mapping Method CALLISTAID (Callista user ID and password). Thus, when logging into an application associated with any of the category's Self Serve Access Codes, the system attempts to authenticate the user via the Callista user ID/password they have entered. It then identifies the person in Callista by mapping the user ID/password to a their person ID and person details. The mapping is necessary so that the user can be restricted to selecting only their data.

Whilst it is possible to associate multiple authentication and Mapping Method with a Self Serve User Category, it should only be necessary if there is a special requirement for optional modes of authentication for the category. For example, it may be a requirement that Web Self Serve Administrators who are also students can gain direct access to student facilities, having first logged into an administrative application, but without having to re-enter authentication information (i.e. a user ID and password). To achieve this, it would be necessary to:

• Set up ORACLEUSER as a second authentication method (i.e. rank 2) and mapping method for the user category ENROLLED
• Set up the 'administrative' user category as ACTIVE against the 'administrative' Self Serve Access Code, in SSFF1600. This means that the 'administrative' category can be used for re-authentication when directly accessing other secured applications
• Set up the 'administrative' user category as INACTIVE against the 'secured applications' Access Code, in SSF1600. This means that administrative users can access secured student applications, but that the 'administrative' user category will not be displayed on login pages

Use this form to define the self service user categories.

Self Serve User Category block

• Self Serve User Category
  Create a new Self Serve User Category or perform a query to retrieve an existing user category.
• Prompt
  A Prompt is recorded to define the User Category. The Prompt is displayed on the Application Login Page if there are multiple ACTIVE categories associated with the application (via the application's access code in SSFF1600).
  
  For example: a user category of ADMIN might include the prompt 'I am an administrator'.
• Description
• Closed check box
• System Authentication Usage
  Select from the LOV, or enter a valid System Authentication Usage code

  Buttons (see below)

  • Self Serve Access Inquiry
  • Mapping Method
  • Authentication Method
  • Input

Self Serve Mapping Method block

• System User Mapping Type
• Description
• Person ID Type

Rules/Notes:

Mapping Method, Authentication Method and Input cannot be updated for a closed user category.

A closed Self Serve User Category cannot be added to a Self Serve Access Code (in SSFF1600).

The System Authentication Usage for Web Administrator should be set to STAFF (in SSFF1700) for SSO authentication to work correctly. See the Callista Product Centre - wiki.callista.com.au/display/CPC for further details relating to SSO (Single sign on).

Self Serve Access Inquiry button

This overlay displays any relationships between the context Self Serve User Category and the Self Serve Access Code. The user category is associated with access codes in the Maintain Self Serve Access form (SSFF1600).

The Active check box (to the right of the Description field), defines whether the user category is available for initial authentication to a secure application associated with the Context Access Code. If more than one active user category is associated with the Access Code, they are listed when the user attempts to login to one of the Access Code's secure applications. The user must select the appropriate category as each category may have different authentication requirements.

If a user has already achieved authentication to a secure application via a particular category, then they can achieve re-authentication to another secure application whose access code is associated with the same category (either active or inactive).

The Display Order column (far right) determines the order of the Context User Category in the list of categories displayed on the application login pages (if there are multiple ACTIVE categories).

Rules/Notes:

Mapping Method button

Each Self Serve User Category is mapped to at least one System User Mapping Type. It is used to identify the Self Serve user's Callista person ID from the User ID entered as part of the authentication. Failure to add a Mapping Method to a category will make it impossible for the System to identify the user as a person in Callista, and therefore prevent them from viewing their Callista data.

It is only necessary to record a Person ID Type (far right), for the System User Mapping Type when an external user management system is used for authentication. It provides the link between the person in the external system and their record in Callista. Once authenticated, the person is identified in Callista via their alternative (USERNAME) Person ID related to the external authentication system. For example: The institution uses an external system called SAS (Student Authentication System) to authenticate its student users. Students exist in Callista with an alternate person ID of type SAS, which is their identifier in SAS. After the person is authenticated via SAS, the System uses the alternate person ID to map the person to a Callista Person ID in the Person table.

Person ID Types are recorded in the Maintain Person ID Types form (ENRF01B0).

Rules/Notes:

Only Person ID Types with a system person ID type of USERNAME are available in the LOV.

Where a Self Serve User Category has the system authentication type PUBLIC, a Mapping Method is not required. A Mapping Method MUST be recorded for all other Authentication Types.

Authentication Method button

Each Self Serve User Category requires at least one System Authentication Type to be selected. Authentication Type defines how the System should authenticate users. For example: if CALLISTAID is the preferred authentication type, the System uses the values input by the user when logging in (i.e. user ID and password) to validate the person with a Callista used ID and password. If it is unable to find the ID/password as a valid combination, the user is not authenticated. This Callista user ID/password information for each user is maintained in the Maintain Self Serve User Authentication Information form (SSFF2300).

The usage code/s of the System Authentication Type are displayed as a lamp in this block (right hand side). All codes defined in the System Authentication Type are displayed.

• Select a System Authentication Type from the LOV. Each system authentication type is ranked, giving an order of precedence for authenticating details. Thus, if multiple methods are selected, the System checks methods in the order defined by the ranking. It initially attempts to authenticate the user via the method ranked 1. If unsuccessful, the next ranked method is checked, and so on until the user is authenticated.
• If necessary, select the System Authentication Type Configuration details for the System Authentication Type from the LOV. The System Authentication Type Configuration, together with the authentication information, provides the required details for the system to connect the user to a database. For example: the authentication type ORACLEUSER requires three pieces of configuration detail (SERVER, SERVERPORT and ORACLE_SID):
• SERVER = HOST (e.g. <server name>.its.institution.edu.au)
• SERVERPORT = PORT (e.g. 1527)
• ORACLE_SID = SID (e.g. SISA)

All of the above data is transparent to the user when logging on.

Other external authentication systems necessitating System Authentication Types not yet specified may also require the existence of authentication configuration details.

Rules/Notes:

If the Authentication Type ORACLEUSER is recorded for a User Category, configuration details MUST also be recorded for it. The number of configuration details for the Authentication Type must match the number of System Authentication Type Configuration definitions.

It is recommended that only one Authentication Method be selected for each Self Serve User Category.

If multiple Authentication Methods are selected, they MUST each require the same number of input codes for authentication. For example: the authentication type CALLISTAID requires the system input codes USERID and PASSWORD. The authentication type PUBLIC does not require any system input codes. However, the authentication types CALLISTAID and ORACLEUSER both require a user identifier and password for input, so they MAY exist together as Authentication Methods for a Self Serve User Category.

If multiple Authentication Methods are selected, ORACLEUSER should be ranked last in the order for authenticating. This is because when authenticating, if the ORACLEUSER Authentication Method fails all authentication checking stops.

The LDAPBASIC authentication method uses Netscape's LDAP Library for authentication. This Authentication Method has been included to enable single authentication for all systems accessed by students at the institution, where LDAPBASIC is the pre-existing global protocol. For further details on setting up LDAP Authentication refer to the LDAP Configuration form and the Callista Product Centre - wiki.callista.com.au/display/CPC.

The System Authentication Type values in the LOV are restricted to values that have the same System Authentication Usage as the context in the Self Serve Usage Category.

Input button

Optionally assign one or more System Authentication Input Code to the User Category. However, if an Authentication Method is selected requiring certain input types, these must be selected to allow a user to login.

System Authentication Input Code defines the information required to be input by the Self Serve User in an application Login Page in order to authenticate. For example: users may be required to authenticate with a USERID and PASSWORD.

Each System Authentication Input Code has a Default Display Prompt (second from right). An Override Display Prompt (underneath the System Authentication Input code), is available to customise the prompt for the particular institution and/or self serve user category.

The Display Order (far right), defines the order in which the system authentication input codes are displayed.

Rules/Notes:

There are no validations to ensure that the Authentication Input Codes match the System Input required for the System Authentication Type. For example: an authentication method of CALLISTAID may have been selected. The system requires authentication inputs USERID and PASSWORD. If only the USERID authentication input is selected for the user category, a user in this category would never be able to login, as a password could not be entered.