casa requirements v2 1

8/2/2019 CASA Requirements v2 1

1/27

Centralized Authentication

System AssessmentDocument Version 2.1

Prepared by CW Belcher, ITS

June 29,2010

CASA Requirements

Executive SummaryThe 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.

Organization

This requirements specification is organized into the following sections:

Section 1 Login Functionality Section 2 Session Management Section 3 Logout Functionality Section 4 Authentication Logging Section 5 Protected Resource Identification


2/27

Centralized Authentication System

AssessmentDocument Version 2.1

CASA Requirements UT Austin 2

Requirements

Section 1 Login Functionality

I D Type Descr ip t i on Rat iona le S ource Notes

CASA.1.0 FunctionalRequirement

The system shall provide loginfunctionality through a login webinterface and through anauthentication service API.

This is a basic function of anauthentication system

Basic systemfunctionality

The login web interface is meantfor use by person authenticationprincipals using web-basedapplications. The authenticationservice API is meant for use byperson principals using non-webapplications and by non-personprincipals (e.g., machine-to-machine authentication).

CASA.1.1

Deleted in version 2.0.


The system shall check for a validauthentication session beforeredirecting to login web interface.

This is basic functionality fora single sign-on system:

user should not bepresented with the login

page if s/he already has a

valid authentication session.



The system shall allow protectedapplications to trigger re-

authentication of the user.

At sensitive points in certainbusiness process, some

applications need to require

that the user reassert theiridentity.

CASA CustomerSteering Committee

Added in version 2.0.


The system shall redirect anunauthenticated user to the loginweb interface when the userbrowses to a protected resource.

Authentication should behandled through the loginweb interface.



3/27





CASA.1.4 Constraint The authentication system shalluse an existing high-availabilitydata store for authentication datasuch as UT EID, password, andauthentication status.

The new authenticationsystem will take advantageof a centralized UT userdata store and will not storeuser data beyond what isnecessary for authentication

logging.

Derived from designdecision It is assumed that the UT EID willbe the user name for theauthentication system.

CASA.1.5 Constraint The system shall allow access tologin functionality to users fromoutside the UT network.

The current authenticationsystem login and logoutpages can be accessed fromoff-campus, creating a basiccustomer expectation of thesame from the replacement

system.



The system shall support personEID authentication.

Only person EIDs will beallowed to authenticatethrough the web interface.The web single sign-onenvironment is for use bypeople, not machines.



The system shall supportmachine-to-machineauthentication.

The core authenticationmachinery should supportnon-person authentication.



For example, applications thatneed to authenticate with serviceslike the XML Gateway.


The system shall enable anapplication called by another

application to independentlyverify the authenticated user'sidentity.

An application that does notdirectly interact with the

user should not have toaccept another application'sassertion of the user'sidentity.




4/27





CASA.1.17 FunctionalRequirement The system shall provide basicidentity information about theauthenticated user to theconsuming application. "Basicinformation" refers to UT EID,UIN, display name, affiliations,

entitlements, and EID class.

Most applications using theauthentication system willneed to know the EID orUIN of the authenticateduser to operate properly. Inaddition, providing other

commonly used basic

information about the user(such as name, affiliation,entitlements, and EID class)will allow the consumingapplications to avoid theexpense of retrieving thisinformation from anothersource.

Derived from theexisting system andcustomerexpectations.



The system shall support EIDusername/ password-basedauthentication.

The current authenticationsystem relies uponusername/password-basedauthentication, creating abasic customer expectationof the same from thereplacement system.



The system shall support

authentication factors other thanusername/password.

There are emerging needs

for other authenticationfactors on campus, such ascertificates, one-time-passwords, etc.



This requirement is distinct from

CASA.15.2, which refers toauthentication with multiplefactors at the same time.


The system shall support multi-factor authentication.

Access to certain sensitiveUT services and/or datawould benefit from a higher

level of security.




The system shall makeinformation about last valid andlast invalid authenticationattempts available to EID usersupon request.

Providing this informationwill help users to identifymisuse of the system by anattacker who has tried to orhas successfully

compromised their account.

UT Austin SecureWeb ApplicationCoding Guidelines,sections 1.2.2 and1.2.3.


5/27





CASA.1.9.0 FunctionalRequirement The system shall not establish anauthentication session upon anunsuccessful authenticationattempt.

Unsuccessful authenticationattempts should not movethe user further along in theauthentication process.


CASA.1.9.1 FunctionalRequirement

The authentication service shallrefuse to establish anauthentication session uponunsuccessful authenticationattempt.



See also CASA.1.11.4.


The web-based authenticationinterface shall return the user tothe login web page uponunsuccessful authentication

attempt



See also CASA.1.11.5.


The system shall only

authenticate users who areeligible to log in.

To comply with the business

rules of the EID system and

maintain consistentbehavior between thecurrent and newauthentication systems.

EID system

authentication statusbusiness rules

To log in, EID accounts must not

be 1) locked, 2) in initial status,

or 3) required to change

password.


The system shall provide

appropriate messages upon an

authentication attempt.

This is a basic usability

requirement, to provide

feedback to the user orconsuming application.

Usability guidelines

CASA.1.11.1


CASA.1.11.2


CASA.1.11.3



The authentication service shallreturn an appropriatecode/message to the consumingapplication upon successful orunsuccessful authenticationattempt.




6/27





CASA.1.11.5 FunctionalRequirement The web-based authenticationinterface shall provide anappropriate message to the userupon unsuccessful authenticationattempt.

CASA CustomerSteering Committee Added in version 2.0.No message will be provided tothe user by the webauthentication interface uponsuccessfulauthentication.


The web-based authenticationinterface shall direct the user tothe originally-requested resourceupon successful authentication.

The user should be returnedto the original destinationonce authenticated.



The system shall include

defenses against brute forceattempts to guess passwords orlock accounts.

Basic system

functionality; UTAustin Secure WebApplication Coding

Guidelines, section1.1.6, 9.1.1, 9.1.7

These defenses should also beresistant to a denial-of-serviceattack.


7/27




Section 2 Session Management



The system shall automaticallymanage the authenticationsession.

This is a basic function of anauthentication system.



The system shall renew theauthentication session uponactivity within a predeterminedperiod.

The authentication sessionshall be maintained asactive so long as the usercontinues use before thesession times out.



The system shall require re-authentication of a sessionautomatically after apredetermined period of userinactivity.

Inactive authenticationsessions must be invalidatedafter a certain period oftime, as a security measureto reduce the risk of anotherindividual acting as theauthenticated user.



The system shall includedefenses against attempts tohijack authentication sessions.

A session should beinvalidated when it appearsthe session has beenhijacked by another user.



The system shall require re-authentication of an applicationsession after a pre-determinedperiod of continuous sessionactivity, unless that application

has received approval forextended-length sessions fromthe ISO.

This is a general securitymeasure to mitigate the riskof unauthorized use of anindividual's credentials.

UT Austin SecureWeb ApplicationCoding Guidelines,section 2.1.6


8/27




Section 3 Logout Functionality



The system shall provide logoutfunctionality.


Basic systemfunctionality; UTAustin Secure WebApplication CodingGuidelines, section2.1.4


The system shall provide amechanism to invalidate theauthentication session.

This allows the user or theapplication consuming theauthentication service todefinitively end the session.



The web-based authenticationinterface shall redirect the user tothe URL specified by the webapplication that initiated thelogout request after theauthentication session isinvalidated. If no post-logoutredirect URL is specified, theweb-based authenticationinterface shall redirect the user tothe UT home page.

This functionality is includedin the current authenticationsystem, creating a basiccustomer expectation of thesame from the replacementsystem.

Derived fromfunctional design ofthe existingauthenticationsystem


9/27




Section 4 Authentication Logging



The system shall logauthentication attempts.



CASA.4.1 Constraint The system shall be configured todisable authentication servicesshould authentication logging fail.(This implies that theadministrators of theauthentication system will need amechanism to authenticatethemselves that does not rely onthe authentication system itselfwhen accessing the system for

repairs or maintenance.)

To ensure the integrity ofauthentication functionality,as the recording ofauthentication activities isbasic for an authenticationsystem.


The authentication mechanismused by administrators needs tobe audit-able.


The system shall log allauthentication attempts, bothvalid and invalid.

A record of allauthentication activity isrequired for historical,forensic, trend analysis, andother functionality.

Basic systemfunctionality; ISO

CASA.4.3 Non-functionalrequirement

The system shall maintain arecord of all authenticationattempts for at least 90 days.

The ISO has requested thisdata retention period for allauthentication attempts.

ISO, Legal Affairs,and RecordsRetention

CASA.4.4 Non-functionalrequirement

The system shall maintain arecord of last valid and lastinvalid authentication attemptsindefinitely.

This requirement supportsCASA.1.8.

UT Austin SecureWeb ApplicationCoding Guidelines,sections 1.2.2 and1.2.3


10/27





CASA.4.5 Functionalrequirement The system shall record thefollowing data for eachauthentication attempt: user ID,session identifier, user's IPaddress, identifier of the serveror application that initiated theauthentication request, IPaddress of the server accessed,target URL, date/time, andwhether the attempt wassuccessful.

These fields support a) userauthentication history, b)last valid/invalidauthentication information,and c) forensic queries.

Derived from designof the existingauthenticationsystem

We need to disclose to users theinformation being logged by thissystem.


11/27




Section 5 Protected Resource Identification



The system shall allow distributedserver managers to identify thespecific resources on thoseservers that should be protectedby the centralized authenticationsystem.




12/27




Section 6 Authorization Functionality and mod_auth_eid



The system shall replace theauthentication functionality, butnot the authorizationfunctionality, ofmod_auth_eid.

The current authenticationsystem includesauthorization functionality(by way ofmod_auth_eid),so a clear determination ofwhat, if any, authorizationfunctionality the newauthentication system willprovide is required.

Derived from designof the existingauthenticationsystem and theCASA CustomerSteering Committee

CASA.6.1 Deleted in version 2.0.




The system shall replace theauthentication functionalitycurrently provided by the

mod_auth_eidApache WebServer module.

The CASA CustomerSteering Committeeendorsed a clear delineationof authentication andauthorization functionality.The scope of the newauthentication system willinclude authenticationservices provided bycentrally developed toolslike mod_auth_eid, but willexclude authorizationservices these tools mightprovide.



CASA.6.5 Constraint The system shall not replace theauthorization functionalitycurrently provided by themod_auth_eidApache WebServer module.

See CASA.6.4 CASA CustomerSteering Committee



13/27




Section 7 Authentication Log Interfaces



The system shall provide aprogrammatic interface thatmakes authentication logginginformation available toauthorized consumers, such asEID system stewards, the EIDAdministrative support webapplication, and the ISO.

This is a basic interfacerequirement of the system.



CASA.7.2.0 Deleted in version 2.0.









14/27




Section 8 Distributed Access Functionality

I D Type Descr ip t i on Rat iona le S ource NotesCASA.8.0 Functional

RequirementThe system shall allow distributedservers and applications toparticipate in the centralizedauthentication system.



The centralized authenticationsystem must be usable byservers/ applications that aredistributed across campus. Asystem that requires centralizedhosting of servers/ applicationsdoes not meet this requirement.

CASA.8.1 Constraint The system shall ensure that onlyauthorized authenticationconsumers (servers/applications)can interact with theauthentication system.

To maintain systemsecurity.



The system shall include amechanism for revoking a clientserver's access.

In situations such as theviolation of theauthentication systemAcceptable Use Policy,stewards need to be able torevoke a client's access tothe system.




The system shall support the webserver and operating systemcombinations that account for80% of the installed server/OSplatforms currently using thecurrent UT Direct and Fat Cookie

authentication service.

Support for Apache on RedHat Linux, Apache onSolaris, and IIS on Windowswill satisfy this requirement.

Basic requirementfor successfulreplacement of thecurrentauthenticationsystem



15/27




Section 9 Robustness

I D Type Descr ip t i on Rat iona le S ource NotesCASA.9.0 Non-functional

RequirementThe system shall be robust. This is a basic expectation

of a critical infrastructuresystem.

Basic expectation forcritical infrastructuresystem

CASA.9.1 Constraint The system shall be architectedto provide 99.9% uptime on anannual basis (approximately 8.75hours of downtime per year).

This is a criticalinfrastructure system whichacts as the gateway for alarge number of other UTsystems, many of them alsocritical.

Authenticationstewards

The new data center's overallavailability will be 99.9% untilOctober 2011, when hostavailability will increase to99.94%.

CASA.9.2.0 Non-functionalRequirement

The system shall perform wellunder peak loads.

This is a basic expectationof a critical infrastructuresystem.




The system shall be architectedto take no more than one secondto process authenticationrequests.

User experience


The system shall be architectedto support a peak load of 200authentication (login) requestsper second.

Current system peak isapproximately 94logins/second. 200logins/second will provideroughly 100% headroom.

Historical loadstatistics

CASA.9.2.4 Non-functional

Requirement

The system shall be architected

to support a peak load of 3.2million hits (protected resourceaccess attempts) per hour.

This is based on a UTDirect

server hit peak of 1.6million on January 19,2010; this figure does notinclude all Fat Cookieresource access attempts.3.2 million hits/hour willprovide roughly 100%headroom.

Historical load

statistics



16/27






The system shall be architectedto recover from certain types offailure without affecting operationof the authentication services.

This is an architecturalmechanism to support thehigh expectations forsystem uptime, reliability,and accuracy.



The system architecture shallsupport the deployment ofsystem components on multipleservers.

This is an architecturalmechanism to support thehigh expectations forsystem uptime, reliability,and accuracy.

Derived from designdecision


The system shall allowrepurposing of servers acrosspersonalities and environments.

Allows quick replacement offailed servers and obviatesthe need for extensivedebugging before re-deploying a server. Alsoenables easy addition ofservers under high,temporary load.



The system shall functionaccurately and reliably.

This is a basic expectationof a critical infrastructuresystem.


CASA.9.4.1 Constraint The system shall include separateand distinct environments fordevelopment and unit testing,system and integration testing,and production operations.

Having separateenvironments allows forinstability in the non-production environments,while maintaining

production stability; it alsoallows fully prod-liketesting, which is necessaryfor thorough reviews whichdo not affect customers.



The system shall provide real-time status monitoring capabilityfor all system components.

For use by system stewards,real time monitoringinformation is necessary forproblem identification andresolution.



17/27






The system shall provide statusmonitoring for all systemcomponents that is accessible toUT operators.

A basic requirement forsystems hosted in the UTdata center.

UT Data Center


The system shall include adefined process for updatingsoftware and serverconfigurations in coordinationwith client servers that minimizesthe visible impact on end users.

While most updates to theauthentication system willnot affect client software,some updates will requirecoordination with theauthentication clients, andthe system uptimerequirements cannotaccommodate expecteddowntime in these

situations.



The system shall provide thecapability to notify themaintenance team via emailwhen system errors occur.

Error reporting is necessaryfor analysis of systemperformance, accuracy, andareas potentially needingimprovement. Some typesof errors may require timelyassistance and should beconveyed in a manner thatallows this (e.g., email).



The system shall include areproduce-able process forbuilding and configuring system

servers.

With multiple servers inmultiple environments, it isof the utmost importance

that all are exactly thesame, for system reliability.The management ofbuilding, configuring, andchanging servers needs tobe automated as much aspossible, for consistencyand speed.



18/27






The system shall include areproduce-able process forbuilding and deploying systemcode.

To ensure code consistencyand stability acrossenvironments and from onebuild to another, thereshould be a build anddeployment process which isautomated as much aspossible.



19/27




Section 10 Security

I D Type Descr ip t i on Rat iona le S ource NotesCASA.10.0 Non-functional

RequirementThe system shall be secure. This is a basic expectation

of a critical infrastructuresystem.

Basic expectation forcritical infrastructuresystem; ISO


CASA.10.2 Constraint The system shall limitcommunication with theauthentication system servers toauthorized applications andservers using a securemechanism.

This will reduce theopportunity for non-authorized access to thehighly sensitiveauthentication systemservers.



CASA.10.4 Constraint The system shall provide asecurity framework that ensuresonly authorized users andprocesses have access to loggingdata and the capability to updatelogs.

Access to logs must belimited to authorized usersfor data integrity and accesscontrol.


CASA.10.5 Constraint The system shall ensure thatauthentication sessionsestablished in one authenticationsystem environment (meaningTest, QA, Production) cannot beused in other authenticationsystem environments.

This safeguards againstindividuals affecting Prodsystems (protected by Prodauthentication) withanything other than a Prodlogon.


CASA.10.6 Constraint The web-based authenticationinterface shall adhere to theuniversity's Secure WebApplication Coding Guidelines.

The authentication systemhas access to highlysensitive data such as EIDpasswords and must adhereto current security practices.This set of guidelines maybe used as a checklist forverification.

ISO


20/27





CASA.10.7.0 Constraint The system shall protect theconfidentiality of non-publicidentity information.

The authentication systemwill have access to highlysensitive data, such as EIDpasswords, in othersystems, and these datamust be protectedappropriately and with thesame degree of care insidethe authentication system.


CASA.10.7.4 Constraint The system shall be incompliance with the university'sMinimum Security Standards forSystems for Category I data.

The system must follow UTsecurity policies.

ISO Added in version 2.0.

CASA.10.7.1 Constraint The system shall not exposepassword characters in plain textin any part of the system or itsinterfaces.

No password echofunctionality should beallowed.

UT Austin SecureWeb ApplicationCoding Guidelines,section 1.1.3

CASA.10.7.2 Constraint The system shall not store EIDpasswords in any form.

While the system willrequire access toauthentication credentials,architectural decisionsdictate that this informationwill not be stored within theauthentication system.Among other rationales, thislimits security and dataintegrity concerns by not

duplicating information.


CASA.10.7.3 Constraint The system shall not use SocialSecurity numbers (SSNs) withinits internal processing.

University policy prohibitsthe use of Social SecurityNumbers without expressbusiness need.

UT AustinInformationResources Use andSecurity Policy V.10


The web-based authenticationinterface shall include measuresto aid users in detecting phishingattempts.

The system should provide away for users to verify theauthenticity of the loginpage.




21/27




Section 11 Usability and Accessibility


CASA.11.0 Non-functionalRequirement

The web-based authenticationinterface shall be usable andaccessible.

This is a basic expectationof any UT system.

Basic systemexpectation

CASA.11.1 Constraint The web-based authenticationinterface shall meet the TexasAdministrative Code 206.70Accessibility Standard.

To meet state legalrequirements.

State of Texas policy


The web-based authenticationinterface shall be usable.

This is a basic expectationof any UT system.



The web-based authenticationinterface shall conform to MIT

web site usability guidelines.

Usability is difficult tospecify, making a checklist

for basic concerns essentialfor verification.



The web-based authenticationinterface shall provide messagesthat are appropriate for theintended user audience.

As an example, a messageintended for an end usershould use non-technicallanguage, while a messageintended for a systemsteward might include errorcodes, line numbers, etc.This will enhance the degreeto which messages areunderstandable and useful.

Usability guidelines


22/27




Section 12 Parallel Operation


CASA.12.0 Constraint The system shall provide thecapability for the new andexisting authentication systemsto run in parallel.

Implementation plans forthe new system, given thecriticality of the service,require that its use bephased in over time andoverlap with the currentsystem.

Derived fromimplementationdecision


The service shall providedocumentation describing theeffects of running the new andthe existing authenticationsystems in parallel.

Some authenticationbehaviors will change duringparallel operation and arelikely to be puzzling to endusers.



The web-based authenticationinterface shall provide adistinction between the new loginpage and the existing login pageto aid in technical support.

The Help Desk staff and IDMteam are likely to need todistinguish whichauthentication system auser is using.





The web-based authenticationinterface logout process shallremove all authentication-relatedcookies generated by the existingCentral Web Authentication

system.

During parallel operation,system overlap should bemade as transparent aspossible. A logout behaviorthat applies only to one

system has the potential toconfuse users.



The web-based authenticationinterface shall permit the existingCentral Web Authenticationsystem's logout process toinvalidate a user's activeauthentication session.

During parallel operation,system overlap should bemade as transparent aspossible. A logout behaviorthat applies only to onesystem has the potential toconfuse users.




23/27





CASA.12.8 Constraint The system shall not generateFat Cookies.

The Customer SteeringCommittee hasrecommended that the FatCookie be retired as part ofthe implementation of thenew authentication serviceand that the new systemspecifically not generate FatCookies.



This constraint implies that theuse of Fat Cookie must be retiredbefore the existing authenticationsystem can be decommissioned.


The system shall providemechanisms for the followingplatforms/environments that useFat Cookie to participate in thecentral authentication service:

Java, Ruby, Python, Mason(Perl), PHP, Cold Fusion, andIIS/.Net web applications.

To successfully retire FatCookie, mechanisms mustbe provided to replace theFat Cookie functionality inthe major platforms and

environments where FatCookie is used on campus.

Derived fromexisting Fat Cookiecustomer base



24/27




Section 13 Documentation



The service shall includedocumentation to support thosewho use or may want to use theauthentication system.

This is a basic expectationof all UT services.



The service shall providetechnical documentation that istargeted to systemsadministrators and campusdevelopers.

The authentication systemserves different customerbases with widely differentneeds, each of which needsnon-overlappinginformation.



25/27




Section 14 Provisioning (section deleted in version 2.0)










26/27




Section 15 Extensibility



The system shall allow extensionfor future functionality needs.

Certain functionality will notbe implemented with thefirst phase of the newsystem but is expected tobe added shortly afterward.



The system shall supportauthentication across multipleauthorized domains.

Known as inter-site sign-on(ISSO), this feature hasbeen requested by areassuch as the Texas Exes(texasexes.org) and BlantonMuseum(blantonmuseum.org).

Texas Exes, BlantonMuseum

Also Texas Performance Arts,Stark Center, UT RecSports.



The system shall supportauthentication for non-web-basedapplications.

Some systems do notcurrently have access tocentralized authentication.The addition of thisfunctionality would movethe university furthertoward single sign-on andimprove the overall level ofsecurity and consistency inuniversity authentication.

ITS Applications, ITSSystems

The DMG plug-in is anotherapplication needing this.


The system shall support proxyauthentication.

Proxy authentication -- inwhich a user logs on with

his/her ID and then takesactions under a group ID --has been requested for bothdepartment and businessEIDs.

Engineering,individual

departments such asClassics


27/27





CASA.15.5 Functional

Requirement

The system shall separate the

web-based authenticationinterface from an authenticationservice API to bolsterextensibility.

Although web-based SSO

functionality is an importantfunction for theauthentication service, itshould not have an out-sized impact on thearchitecture of theauthentication system.

CASA Customer

Steering Committee



The system shall provide supportfor out-of-the-box integrationwith third-party applicationscommonly used on our campus,such as Drupal, WordPress,Blackboard, Xythos, Confluence,

and Jira.

Commonly usedapplications that donot currentlyparticipate in thecentralauthentication

service because ofintegrationdifficulties


casa requirements v2 1

Documents