CASA Requirements v2 1

Centralized Authentication System Assessment
Document Version 2.1 Prepared by CW Belcher, ITS June 29,2010
The Centralized Authentication System Assessment (CASA) project was chartered to review our campus authentication needs and recommend a strategy for meeting those needs. As part of these activities, the CASA Customer Steering Committee reviewed and vetted a set of functional and non-functional requirements for a centralized authentication system for campus, which are documented in this requirements specification.
CASA Requirements
Executive Summary
Organization
This requirements specification is organized into the following sections:
Section Section Section Section Section Section Section Section Section Section Section Section Section Section Section 1 Login Functionality 2 Session Management 3 Logout Functionality 4 Authentication Logging 5 Protected Resource Identification 6 Authorization Functionality and mod_auth_eid 7 Authentication Log Interfaces 8 Distributed Access Functionality 9 Robustness 10 Security 11 Usability and Accessibility 12 Parallel Operation 13 Documentation 14 Provisioning (section deleted in version 2.0) 15 Extensibility

Document Version 2.1
Requirements
Section 1 Login Functionality
ID CASA.1.0 Type Functional Requirement Description The system shall provide login functionality through a login web interface and through an authentication service API. Rationale This is a basic function of an authentication system Source Basic system functionality Notes The login web interface is meant for use by person authentication principals using web-based applications. The authentication service API is meant for use by person principals using non-web applications and by non-person principals (e.g., machine-tomachine authentication). Deleted in version 2.0. Functional Requirement The system shall check for a valid authentication session before redirecting to login web interface. This is basic functionality for a single sign-on system: user should not be presented with the login page if s/he already has a valid authentication session. At sensitive points in certain business process, some applications need to require that the user reassert their identity. Authentication should be handled through the login web interface. Basic system functionality
CASA.1.1 CASA.1.2
CASA.1.14
Functional Requirement
The system shall allow protected applications to trigger reauthentication of the user.
CASA Customer Steering Committee
Added in version 2.0.
CASA.1.3
The system shall redirect an unauthenticated user to the login web interface when the user browses to a protected resource.
Basic system functionality
CASA Requirements
UT Austin

ID CASA.1.4
Type Constraint
Description The authentication system shall use an existing high-availability data store for authentication data such as UT EID, password, and authentication status.
Rationale The new authentication system will take advantage of a centralized UT user data store and will not store user data beyond what is necessary for authentication logging. The current authentication system login and logout pages can be accessed from off-campus, creating a basic customer expectation of the same from the replacement system. Only person EIDs will be allowed to authenticate through the web interface. The web single sign-on environment is for use by people, not machines. The core authentication machinery should support non-person authentication. An application that does not directly interact with the user should not have to accept another application's assertion of the user's identity.
Source Derived from design decision
Notes It is assumed that the UT EID will be the user name for the authentication system.
CASA.1.5
Constraint
The system shall allow access to login functionality to users from outside the UT network.
CASA.1.6
The system shall support person EID authentication.
CASA.1.15
The system shall support machine-to-machine authentication. The system shall enable an application called by another application to independently verify the authenticated user's identity.
Added in version 2.0. For example, applications that need to authenticate with services like the XML Gateway. Added in version 2.0.
CASA.1.16
CASA Requirements
UT Austin

ID CASA.1.17
Type Functional Requirement
Description The system shall provide basic identity information about the authenticated user to the consuming application. "Basic information" refers to UT EID, UIN, display name, affiliations, entitlements, and EID class.
Rationale Most applications using the authentication system will need to know the EID or UIN of the authenticated user to operate properly. In addition, providing other commonly used basic information about the user (such as name, affiliation, entitlements, and EID class) will allow the consuming applications to avoid the expense of retrieving this information from another source. The current authentication system relies upon username/password-based authentication, creating a basic customer expectation of the same from the replacement system. There are emerging needs for other authentication factors on campus, such as certificates, one-timepasswords, etc. Access to certain sensitive UT services and/or data would benefit from a higher level of security. Providing this information will help users to identify misuse of the system by an attacker who has tried to or has successfully compromised their account.
Source Derived from the existing system and customer expectations.
Notes Added in version 2.0.
CASA.1.7
The system shall support EID username/ password-based authentication.
CASA.1.18
The system shall support authentication factors other than username/password.
Added in version 2.0. This requirement is distinct from CASA.15.2, which refers to authentication with multiple factors at the same time. Added in version 2.0.
CASA.1.19
The system shall support multifactor authentication.
CASA.1.8
The system shall make information about last valid and last invalid authentication attempts available to EID users upon request.
UT Austin Secure Web Application Coding Guidelines, sections 1.2.2 and 1.2.3.
CASA Requirements
UT Austin

ID CASA.1.9.0
Description The system shall not establish an authentication session upon an unsuccessful authentication attempt. The authentication service shall refuse to establish an authentication session upon unsuccessful authentication attempt. The web-based authentication interface shall return the user to the login web page upon unsuccessful authentication attempt The system shall only authenticate users who are eligible to log in.
Rationale Unsuccessful authentication attempts should not move the user further along in the authentication process.
Source Basic system functionality
Notes
CASA.1.9.1
Added in version 2.0. See also CASA.1.11.4.
CASA.1.9.2
Added in version 2.0. See also CASA.1.11.5.
CASA.1.10
To comply with the business rules of the EID system and maintain consistent behavior between the current and new authentication systems. This is a basic usability requirement, to provide feedback to the user or consuming application.
EID system authentication status business rules
To log in, EID accounts must not be 1) locked, 2) in initial status, or 3) required to change password.
CASA.1.11.0
The system shall provide appropriate messages upon an authentication attempt.
Usability guidelines
CASA.1.11.1 CASA.1.11.2 CASA.1.11.3 CASA.1.11.4 Functional Requirement The authentication service shall return an appropriate code/message to the consuming application upon successful or unsuccessful authentication attempt. CASA Customer Steering Committee
Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Added in version 2.0.
CASA Requirements
UT Austin

ID CASA.1.11.5
Description The web-based authentication interface shall provide an appropriate message to the user upon unsuccessful authentication attempt. The web-based authentication interface shall direct the user to the originally-requested resource upon successful authentication. The system shall include defenses against brute force attempts to guess passwords or lock accounts.
Rationale
Source CASA Customer Steering Committee
Notes Added in version 2.0. No message will be provided to the user by the web authentication interface upon successful authentication.
CASA.1.12
The user should be returned to the original destination once authenticated.
CASA.1.13
Basic system functionality; UT Austin Secure Web Application Coding Guidelines, section 1.1.6, 9.1.1, 9.1.7
These defenses should also be resistant to a denial-of-service attack.
CASA Requirements
UT Austin

Section 2 Session Management

ID CASA.2.0 Type Functional Requirement Functional Requirement Description The system shall automatically manage the authentication session. The system shall renew the authentication session upon activity within a predetermined period. The system shall require reauthentication of a session automatically after a predetermined period of user inactivity. Rationale This is a basic function of an authentication system. The authentication session shall be maintained as active so long as the user continues use before the session times out. Inactive authentication sessions must be invalidated after a certain period of time, as a security measure to reduce the risk of another individual acting as the authenticated user. A session should be invalidated when it appears the session has been hijacked by another user. This is a general security measure to mitigate the risk of unauthorized use of an individual's credentials. Source Basic system functionality Basic system functionality Notes
CASA.2.1
CASA.2.2
CASA.2.3
The system shall include defenses against attempts to hijack authentication sessions. The system shall require reauthentication of an application session after a pre-determined period of continuous session activity, unless that application has received approval for extended-length sessions from the ISO.
CASA.2.4
UT Austin Secure Web Application Coding Guidelines, section 2.1.6
CASA Requirements
UT Austin

Section 3 Logout Functionality

ID CASA.3.0 Type Functional Requirement Description The system shall provide logout functionality. Rationale This is a basic function of an authentication system. Source Basic system functionality; UT Austin Secure Web Application Coding Guidelines, section 2.1.4 Basic system functionality Notes
CASA.3.1
The system shall provide a mechanism to invalidate the authentication session. The web-based authentication interface shall redirect the user to the URL specified by the web application that initiated the logout request after the authentication session is invalidated. If no post-logout redirect URL is specified, the web-based authentication interface shall redirect the user to the UT home page.
This allows the user or the application consuming the authentication service to definitively end the session. This functionality is included in the current authentication system, creating a basic customer expectation of the same from the replacement system.
CASA.3.2
Derived from functional design of the existing authentication system
CASA Requirements
UT Austin

Section 4 Authentication Logging

ID CASA.4.0 CASA.4.1 Type Functional Requirement Constraint Description The system shall log authentication attempts. The system shall be configured to disable authentication services should authentication logging fail. (This implies that the administrators of the authentication system will need a mechanism to authenticate themselves that does not rely on the authentication system itself when accessing the system for repairs or maintenance.) The system shall log all authentication attempts, both valid and invalid. Rationale This is a basic function of an authentication system. To ensure the integrity of authentication functionality, as the recording of authentication activities is basic for an authentication system. Source Basic system functionality Basic system functionality The authentication mechanism used by administrators needs to be audit-able. Notes
CASA.4.2
A record of all authentication activity is required for historical, forensic, trend analysis, and other functionality. The ISO has requested this data retention period for all authentication attempts. This requirement supports CASA.1.8.
Basic system functionality; ISO
CASA.4.3
Non-functional requirement Non-functional requirement
The system shall maintain a record of all authentication attempts for at least 90 days. The system shall maintain a record of last valid and last invalid authentication attempts indefinitely.
ISO, Legal Affairs, and Records Retention UT Austin Secure Web Application Coding Guidelines, sections 1.2.2 and 1.2.3
CASA.4.4
CASA Requirements
UT Austin

ID CASA.4.5
Type Functional requirement
Description The system shall record the following data for each authentication attempt: user ID, session identifier, user's IP address, identifier of the server or application that initiated the authentication request, IP address of the server accessed, target URL, date/time, and whether the attempt was successful.
Rationale These fields support a) user authentication history, b) last valid/invalid authentication information, and c) forensic queries.
Source Derived from design of the existing authentication system
Notes We need to disclose to users the information being logged by this system.
CASA Requirements
UT Austin
10

Section 5 Protected Resource Identification

ID CASA.5.0 Type Functional Requirement Description The system shall allow distributed server managers to identify the specific resources on those servers that should be protected by the centralized authentication system. Rationale This is a basic function of an authentication system. Source Basic system functionality Notes
CASA Requirements
UT Austin
11

Section 6 Authorization Functionality and mod_auth_eid

ID CASA.6.0 Type Functional Requirement Description The system shall replace the authentication functionality, but not the authorization functionality, of mod_auth_eid. Rationale The current authentication system includes authorization functionality (by way of mod_auth_eid), so a clear determination of what, if any, authorization functionality the new authentication system will provide is required. Source Derived from design of the existing authentication system and the CASA Customer Steering Committee Notes
CASA.6.1 CASA.6.2 CASA.6.3 CASA.6.4 Functional Requirement The system shall replace the authentication functionality currently provided by the mod_auth_eid Apache Web Server module. The CASA Customer Steering Committee endorsed a clear delineation of authentication and authorization functionality. The scope of the new authentication system will include authentication services provided by centrally developed tools like mod_auth_eid, but will exclude authorization services these tools might provide. See CASA.6.4 CASA Customer Steering Committee
Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Added in version 2.0.
CASA.6.5
Constraint
The system shall not replace the authorization functionality currently provided by the mod_auth_eid Apache Web Server module.
CASA Requirements
UT Austin
12

Section 7 Authentication Log Interfaces

ID CASA.7.0 Type Functional Requirement Description The system shall provide a programmatic interface that makes authentication logging information available to authorized consumers, such as EID system stewards, the EID Administrative support web application, and the ISO. Rationale This is a basic interface requirement of the system. Source Basic system functionality Notes
CASA.7.1 CASA.7.2.0 CASA.7.2.1 CASA.7.2.2 CASA.7.2.3 CASA.7.2.4 CASA.7.3.0 CASA.7.3.1 CASA.7.3.2
Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0.
CASA Requirements
UT Austin
13

Section 8 Distributed Access Functionality

ID CASA.8.0 Type Functional Requirement Description The system shall allow distributed servers and applications to participate in the centralized authentication system. Rationale This is a basic function of an authentication system. Source Basic system functionality Notes The centralized authentication system must be usable by servers/ applications that are distributed across campus. A system that requires centralized hosting of servers/ applications does not meet this requirement.
CASA.8.1
Constraint
The system shall ensure that only authorized authentication consumers (servers/applications) can interact with the authentication system. The system shall include a mechanism for revoking a client server's access.
To maintain system security.
CASA.8.2
In situations such as the violation of the authentication system Acceptable Use Policy, stewards need to be able to revoke a client's access to the system. Support for Apache on Red Hat Linux, Apache on Solaris, and IIS on Windows will satisfy this requirement.
CASA.8.3
The system shall support the web server and operating system combinations that account for 80% of the installed server/OS platforms currently using the current UT Direct and Fat Cookie authentication service.
Basic requirement for successful replacement of the current authentication system
CASA Requirements
UT Austin
14

Section 9 Robustness
ID CASA.9.0 Type Non-functional Requirement Constraint Description The system shall be robust. Rationale This is a basic expectation of a critical infrastructure system. This is a critical infrastructure system which acts as the gateway for a large number of other UT systems, many of them also critical. This is a basic expectation of a critical infrastructure system. Source Basic expectation for critical infrastructure system Authentication stewards The new data center's overall availability will be 99.9% until October 2011, when host availability will increase to 99.94%. Notes
CASA.9.1
The system shall be architected to provide 99.9% uptime on an annual basis (approximately 8.75 hours of downtime per year).
CASA.9.2.0
Non-functional Requirement
The system shall perform well under peak loads.
Basic expectation for critical infrastructure system Deleted in version 2.0.
CASA.9.2.1 CASA.9.2.2 Non-functional Requirement The system shall be architected to take no more than one second to process authentication requests. The system shall be architected to support a peak load of 200 authentication (login) requests per second. The system shall be architected to support a peak load of 3.2 million hits (protected resource access attempts) per hour. Current system peak is approximately 94 logins/second. 200 logins/second will provide roughly 100% headroom. This is based on a UTDirect server hit peak of 1.6 million on January 19, 2010; this figure does not include all Fat Cookie resource access attempts. 3.2 million hits/hour will provide roughly 100% headroom. User experience
CASA.9.2.3
Historical load statistics
CASA.9.2.4
Historical load statistics
CASA.9.2.5
Deleted in version 2.0.
CASA Requirements
UT Austin
15

ID CASA.9.3.0
Type Non-functional Requirement
Description The system shall be architected to recover from certain types of failure without affecting operation of the authentication services. The system architecture shall support the deployment of system components on multiple servers. The system shall allow repurposing of servers across personalities and environments.
Rationale This is an architectural mechanism to support the high expectations for system uptime, reliability, and accuracy. This is an architectural mechanism to support the high expectations for system uptime, reliability, and accuracy. Allows quick replacement of failed servers and obviates the need for extensive debugging before redeploying a server. Also enables easy addition of servers under high, temporary load. This is a basic expectation of a critical infrastructure system. Having separate environments allows for instability in the nonproduction environments, while maintaining production stability; it also allows fully prod-like testing, which is necessary for thorough reviews which do not affect customers. For use by system stewards, real time monitoring information is necessary for problem identification and resolution.
Source Basic expectation for critical infrastructure system
Notes
CASA.9.3.1
Derived from design decision
CASA.9.3.2
CASA.9.4.0
Non-functional Requirement Constraint
The system shall function accurately and reliably. The system shall include separate and distinct environments for development and unit testing, system and integration testing, and production operations.
Basic expectation for critical infrastructure system Basic expectation for critical infrastructure system
CASA.9.4.1
CASA.9.4.2
The system shall provide realtime status monitoring capability for all system components.
Basic expectation for critical infrastructure system
CASA Requirements
UT Austin
16

ID CASA.9.4.3
Description The system shall provide status monitoring for all system components that is accessible to UT operators. The system shall include a defined process for updating software and server configurations in coordination with client servers that minimizes the visible impact on end users.
Rationale A basic requirement for systems hosted in the UT data center. While most updates to the authentication system will not affect client software, some updates will require coordination with the authentication clients, and the system uptime requirements cannot accommodate expected downtime in these situations. Error reporting is necessary for analysis of system performance, accuracy, and areas potentially needing improvement. Some types of errors may require timely assistance and should be conveyed in a manner that allows this (e.g., email). With multiple servers in multiple environments, it is of the utmost importance that all are exactly the same, for system reliability. The management of building, configuring, and changing servers needs to be automated as much as possible, for consistency and speed.
Source UT Data Center
Notes
CASA.9.4.4
CASA.9.4.5
The system shall provide the capability to notify the maintenance team via email when system errors occur.
CASA.9.4.6
The system shall include a reproduce-able process for building and configuring system servers.
CASA Requirements
UT Austin
17

ID CASA.9.4.7
Description The system shall include a reproduce-able process for building and deploying system code.
Rationale To ensure code consistency and stability across environments and from one build to another, there should be a build and deployment process which is automated as much as possible.
Notes
CASA Requirements
UT Austin
18

Section 10 Security
ID CASA.10.0 Type Non-functional Requirement Description The system shall be secure. Rationale This is a basic expectation of a critical infrastructure system. Source Basic expectation for critical infrastructure system; ISO Deleted in version 2.0. Constraint The system shall limit communication with the authentication system servers to authorized applications and servers using a secure mechanism. This will reduce the opportunity for nonauthorized access to the highly sensitive authentication system servers. Derived from design decision Notes
CASA.10.1 CASA.10.2
CASA.10.3 CASA.10.4 Constraint The system shall provide a security framework that ensures only authorized users and processes have access to logging data and the capability to update logs. The system shall ensure that authentication sessions established in one authentication system environment (meaning Test, QA, Production) cannot be used in other authentication system environments. The web-based authentication interface shall adhere to the university's Secure Web Application Coding Guidelines. Access to logs must be limited to authorized users for data integrity and access control. Basic expectation for critical infrastructure system
CASA.10.5
Constraint
This safeguards against individuals affecting Prod systems (protected by Prod authentication) with anything other than a Prod logon. The authentication system has access to highly sensitive data such as EID passwords and must adhere to current security practices. This set of guidelines may be used as a checklist for verification.
CASA.10.6
Constraint
ISO
CASA Requirements
UT Austin
19

ID CASA.10.7.0
Type Constraint
Description The system shall protect the confidentiality of non-public identity information.
Rationale The authentication system will have access to highly sensitive data, such as EID passwords, in other systems, and these data must be protected appropriately and with the same degree of care inside the authentication system. The system must follow UT security policies.
Notes
CASA.10.7.4
Constraint
The system shall be in compliance with the university's Minimum Security Standards for Systems for Category I data. The system shall not expose password characters in plain text in any part of the system or its interfaces. The system shall not store EID passwords in any form.
ISO
CASA.10.7.1
Constraint
No password echo functionality should be allowed. While the system will require access to authentication credentials, architectural decisions dictate that this information will not be stored within the authentication system. Among other rationales, this limits security and data integrity concerns by not duplicating information. University policy prohibits the use of Social Security Numbers without express business need. The system should provide a way for users to verify the authenticity of the login page.
UT Austin Secure Web Application Coding Guidelines, section 1.1.3 Derived from design decision
CASA.10.7.2
Constraint
CASA.10.7.3
Constraint
The system shall not use Social Security numbers (SSNs) within its internal processing. The web-based authentication interface shall include measures to aid users in detecting phishing attempts.
UT Austin Information Resources Use and Security Policy V.10 CASA Customer Steering Committee Added in version 2.0.
CASA.10.8
CASA Requirements
UT Austin
20

Section 11 Usability and Accessibility

ID CASA.11.0 Type Non-functional Requirement Constraint Description The web-based authentication interface shall be usable and accessible. The web-based authentication interface shall meet the Texas Administrative Code 206.70 Accessibility Standard. The web-based authentication interface shall be usable. The web-based authentication interface shall conform to MIT web site usability guidelines. The web-based authentication interface shall provide messages that are appropriate for the intended user audience. Rationale This is a basic expectation of any UT system. To meet state legal requirements. Source Basic system expectation State of Texas policy Notes
CASA.11.1
CASA.11.2.0 CASA.11.2.1
Non-functional Requirement Non-functional Requirement
This is a basic expectation of any UT system. Usability is difficult to specify, making a checklist for basic concerns essential for verification. As an example, a message intended for an end user should use non-technical language, while a message intended for a system steward might include error codes, line numbers, etc. This will enhance the degree to which messages are understandable and useful.
Basic system expectation Basic system expectation
CASA.11.2.2
Usability guidelines
CASA Requirements
UT Austin
21

Section 12 Parallel Operation

ID CASA.12.0 Type Constraint Description The system shall provide the capability for the new and existing authentication systems to run in parallel. Rationale Implementation plans for the new system, given the criticality of the service, require that its use be phased in over time and overlap with the current system. Some authentication behaviors will change during parallel operation and are likely to be puzzling to end users. The Help Desk staff and IDM team are likely to need to distinguish which authentication system a user is using. Source Derived from implementation decision Notes
CASA.12.1
The service shall provide documentation describing the effects of running the new and the existing authentication systems in parallel. The web-based authentication interface shall provide a distinction between the new login page and the existing login page to aid in technical support.
Derived from implementation decision
CASA.12.2
Derived from implementation decision
CASA.12.3 CASA.12.4 CASA.12.5 Functional Requirement The web-based authentication interface logout process shall remove all authentication-related cookies generated by the existing Central Web Authentication system. The web-based authentication interface shall permit the existing Central Web Authentication system's logout process to invalidate a user's active authentication session. During parallel operation, system overlap should be made as transparent as possible. A logout behavior that applies only to one system has the potential to confuse users. During parallel operation, system overlap should be made as transparent as possible. A logout behavior that applies only to one system has the potential to confuse users. Derived from design decision
Deleted in version 2.0. Deleted in version 2.0.
CASA.12.6
Basic system expectation
CASA.12.7
CASA Requirements
UT Austin
22

ID CASA.12.8
Type Constraint
Description The system shall not generate Fat Cookies.
Rationale The Customer Steering Committee has recommended that the Fat Cookie be retired as part of the implementation of the new authentication service and that the new system specifically not generate Fat Cookies. To successfully retire Fat Cookie, mechanisms must be provided to replace the Fat Cookie functionality in the major platforms and environments where Fat Cookie is used on campus.
Notes Added in version 2.0. This constraint implies that the use of Fat Cookie must be retired before the existing authentication system can be decommissioned.
CASA.12.9
The system shall provide mechanisms for the following platforms/environments that use Fat Cookie to participate in the central authentication service: Java, Ruby, Python, Mason (Perl), PHP, Cold Fusion, and IIS/.Net web applications.
Derived from existing Fat Cookie customer base
CASA Requirements
UT Austin
23

Section 13 Documentation
ID CASA.13.0 Type Non-functional Requirement Description The service shall include documentation to support those who use or may want to use the authentication system. The service shall provide technical documentation that is targeted to systems administrators and campus developers. Rationale This is a basic expectation of all UT services. Source Basic system expectation Notes
CASA.13.1
The authentication system serves different customer bases with widely different needs, each of which needs non-overlapping information.
Basic system expectation
CASA Requirements
UT Austin
24

Section 14 Provisioning (section deleted in version 2.0)

ID CASA.14.0 CASA.14.1 CASA.14.2 CASA.14.3 CASA.14.4 CASA.14.5 CASA.14.6 Type Description Rationale Source Notes Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0. Deleted in version 2.0.
CASA Requirements
UT Austin
25

Section 15 Extensibility
ID CASA.15.0 Type Non-functional Requirement Description The system shall allow extension for future functionality needs. Rationale Certain functionality will not be implemented with the first phase of the new system but is expected to be added shortly afterward. Known as inter-site sign-on (ISSO), this feature has been requested by areas such as the Texas Exes (texasexes.org) and Blanton Museum (blantonmuseum.org). Source Basic system expectation Notes
CASA.15.1
The system shall support authentication across multiple authorized domains.
Texas Exes, Blanton Museum
Also Texas Performance Arts, Stark Center, UT RecSports.
CASA.15.2 CASA.15.3 Functional Requirement The system shall support authentication for non-web-based applications. Some systems do not currently have access to centralized authentication. The addition of this functionality would move the university further toward single sign-on and improve the overall level of security and consistency in university authentication. Proxy authentication -- in which a user logs on with his/her ID and then takes actions under a group ID -has been requested for both department and business EIDs. ITS Applications, ITS Systems
Deleted in version 2.0. The DMG plug-in is another application needing this.
CASA.15.4
The system shall support proxy authentication.
Engineering, individual departments such as Classics
CASA Requirements
UT Austin
26

ID CASA.15.5
Description The system shall separate the web-based authentication interface from an authentication service API to bolster extensibility.
Rationale Although web-based SSO functionality is an important function for the authentication service, it should not have an outsized impact on the architecture of the authentication system.
Notes Added in version 2.0.
CASA.15.6
The system shall provide support for out-of-the-box integration with third-party applications commonly used on our campus, such as Drupal, WordPress, Blackboard, Xythos, Confluence, and Jira.
Commonly used applications that do not currently participate in the central authentication service because of integration difficulties
CASA Requirements
UT Austin
27

CASA Requirements v2 1

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CASA Requirements v2 1

Diunggah oleh

Hak Cipta:

Format Tersedia

Centralized Authentication System Assessment

Document Version 2.1 Prepared by CW Belcher, ITS June 29,2010

Centralized Authentication System Assessment

CASA Customer Steering Committee

Added in version 2.0.

Basic system functionality

Centralized Authentication System Assessment

Source Derived from design decision

Basic system functionality

The system shall support person EID authentication.

Basic system functionality

CASA Customer Steering Committee

CASA Customer Steering Committee

Centralized Authentication System Assessment

Type Functional Requirement

Source Derived from the existing system and customer expectations.

Notes Added in version 2.0.

The system shall support EID username/ password-based authentication.

Basic system functionality

The system shall support authentication factors other than username/password.

CASA Customer Steering Committee

The system shall support multifactor authentication.

CASA Customer Steering Committee

Centralized Authentication System Assessment

Type Functional Requirement

Source Basic system functionality

CASA Customer Steering Committee

Added in version 2.0. See also CASA.1.11.4.

CASA Customer Steering Committee

Added in version 2.0. See also CASA.1.11.5.

EID system authentication status business rules

The system shall provide appropriate messages upon an authentication attempt.

Centralized Authentication System Assessment

Type Functional Requirement

Source CASA Customer Steering Committee

The user should be returned to the original destination once authenticated.

Basic system functionality

These defenses should also be resistant to a denial-of-service attack.

Centralized Authentication System Assessment

Section 2 Session Management

Basic system functionality

Basic system functionality

UT Austin Secure Web Application Coding Guidelines, section 2.1.6

Centralized Authentication System Assessment

Section 3 Logout Functionality

Derived from functional design of the existing authentication system

Centralized Authentication System Assessment

Section 4 Authentication Logging

Basic system functionality; ISO

Non-functional requirement Non-functional requirement

Centralized Authentication System Assessment

Type Functional requirement

Source Derived from design of the existing authentication system

Centralized Authentication System Assessment

Section 5 Protected Resource Identification

Centralized Authentication System Assessment

Section 6 Authorization Functionality and mod_auth_eid

CASA Customer Steering Committee

Added in version 2.0.

Centralized Authentication System Assessment

Section 7 Authentication Log Interfaces

CASA.7.1 CASA.7.2.0 CASA.7.2.1 CASA.7.2.2 CASA.7.2.3 CASA.7.2.4 CASA.7.3.0 CASA.7.3.1 CASA.7.3.2

Centralized Authentication System Assessment