CASI Project Charter. Centralized Authentication System Implementation. Executive Summary. Business Need and Background

Transcription

1 Prepared by Kara Nicholas, ITS Executive Summary The (CASI) project involves the development and release of a new UT EID- based authentication, to replace the aging Central Web Authentication (CWA). CASI follows the recommendations of the System Assessment (CASA) project. The CASI project will be comprised of three separate workstreams: 1) Creation of the new authentication and transition of at least two client services to use the new, 2) Transition of Fat Cookie services and modification of mod_auth_eid, and 3) Transition of UT Direct services and retirement of the CWA and Fat Cookie. Business Need and Background The University of Texas at Austin has over 5 million electronic identities and manages hundreds of applications that help the owners of those identities conduct their business with the university. These applications include third- party s like Blackboard and Webspace, as well as many custom built applications covering subjects from class registration to travel vouchers to donor activity and academic pursuits. It has become standard practice to have these applications authenticate using the UT EID and password so clients do not have to remember and manage multiple identities and passwords. Our current central UT EID authentication infrastructure was developed in the 1990 s, and it is having increasing difficulty keeping up with today s demands for authentication, as outlined below. This service can no longer be updated effectively and is at the end of its useful life. A new must be put in place to address the following issues: Improved uptime for authentication that is not tied to the mainframe/broker maintenance cycle. When the original EID authentication was created in the mid s, it was designed for authenticating Web applications that ran against the mainframe. Under those circumstances it did not matter if the mainframe was down for authentication, because the applications using authentication were down as well. Over time, more and more applications 1

2 that are not tied to the mainframe s uptime and maintenance cycle have started using UT EID authentication, generating a need for greater availability than is required for both the mainframe and broker. Improved session management. The current centralized authentication provides varying levels of single sign- on support to users. Within UT Direct, authentication sessions are managed in a way that allows them to be automatically refreshed wherever the user is working within UT Direct. However, when working with EID authenticated services outside of UT Direct, users experience inconsistent session management and are required to re- authenticate in the middle of work tasks, resulting in significant obstacles to productivity. Improved logging. Today, members of the Information Security Office (ISO) are hindered when investigating suspicious authentication activity by the limited amount of information logged by the current authentication. For audit and security purposes, a more complete log of authentication activity is needed. Improved security and privacy. Today s authentication relies on HTTP cookies called the Secure Cookie and the Fat Cookie. These cookies are not encrypted, and one of these cookies (Fat Cookie) contains confidential information such as the UIN and user role information. This situation can be remedied by transitioning to an authentication that uses truly opaque cookie values. In addition, we have many s that use EID credentials outside the UT Direct and Fat Cookie environments (for example through direct LDAP authentication). The developers of these s are handling credentials in their applications and may not be aware of special security needs for processing credentials, a risk which strikes at the heart of the integrity of the EID credential itself. Finally, these s outside the UT Direct/Fat Cookie environment present varied authentication points and screens to their users. Training users to enter their EID credentials into non- standard screens increases the potential for successful phishing exploits. Capability for multi- factor authentication. The University has had a need for some time for higher levels of authentication or assurance for sensitive applications. For example, we might require people that have particular access to sensitive data or high dollar value transactions to present an additional factor of authentication. A true second factor of authentication is used by many of our peers, and we need to provide a that is extensible enough to support this functionality in a cost- effective manner. Improved support for lower assurance and/or third party authentication. The University s authentication must meet the needs of many disparate groups that have different requirements for levels of authentication and assurance. The institution s authentication requirements must also be consistent with the associated risk of the resources being protected by authentication. As third- party authentication options have grown, the University s need to incorporate these third- party options also increases. Broader support. As mentioned previously, today s EID authentication was architected in the 1990 s and was designed to support authentication for Web- based applications running on UT Direct. The Fat Cookie extended this to Web applications on other select platforms, but it still is supported on a relatively small number of platforms. Today we need a bigger tent to 2

3 accommodate the many types of applications and platforms needing to authenticate with UT EID. In addition, there are numerous types or forms of UT EID authentication that occur on campus today. Beyond the multiple ITS- managed s, there are even more authentication options on campus that do not use UT EID credentials because of problems with the Fat Cookie or other issues. Some of these s pose a potential security risk because they use the UT EID as a user name and encourage users to manually synchronize their official UT EID passwords with the passwords stored in these s. Each mechanism represents an additional security concern, and an additional place where logging needs to be implemented. A modern centralized authentication service will allow us to reduce the number of EID authentication points, improving overall security and usability. Project Description The CASA project identified and vetted the requirements for a new centralized web authentication. This effort also yielded a recommendation to use an open source authentication product, OpenAM, as the foundation for that new. The CASI project will build upon the CASA deliverables in its development of a replacement for the current Centralized Web Authentication. The CASI project activities will be managed in three interrelated but separate workstreams. The first workstream includes the design and development of the new authentication itself. This effort will include the creation of production service support, including an acceptable use policy, service level agreement, and technical support packages, with documentation, for selected client platforms. Once the new has been built, it will be rolled out to a small number of early adopters, which will allow the collection and analysis of production service data prior to the large- scale transition. The project's second workstream involves the coordination and implementation of transitioning services currently using Fat Cookie authentication to use the new authentication. This work includes identifying the full list of individuals, services, and client platforms which will be affected in the transition of the 175 Fat Cookie- authenticated production servers and securing IT governance backing for a complete transition away from Fat Cookie. Detailed transition planning, including decisions about transition timing and the list of client platforms which will be supported under the new authentication, will be undertaken. The CASI project team will also customize customer support installation packages and documentation for each supported client platform and provide assistance to customers as they transition. In addition, documentation will be created for end users and for the ITS Help Desk to clarify expectations about the new and potential impacts to customers. Further, the second workstream also includes the revision of the centrally- distributed Apache module mod_auth_eid. This work follows a CASA customer steering committee decision endorsing the centralization of all authentication processing within the new authentication ; the current version of mod_auth_eid provides on- the- fly authentication and authorization functionality. This module will be revised to provide only authorization functions, and with this change, a significant portion of the Fat Cookie developer community will need to rework the authentication schemes for applications. This 3

4 effort will require a related but separate planning, architecture, and communications effort to be carried out successfully. The third project workstream includes the transition of the UT Direct platform, which hosts hundreds of services. The technical work required by developers of individual UT Direct applications to support the new platform will be minimal, since authentication is handled at the UT Direct portal layer. However, this workstream will involve significant work by ITS Systems, which will be making three technical changes: transition to UT Direct to use OpenAM authentication, implementation of a replacement for the webtoken which provides user information to mainframe services, and transition of the UT Direct machines to Apache web server. The current CWA is closely integrated with UT Direct itself, so the transition of UT Direct to OpenAM must occur in concert with the final retirement of the CWA, including Fat Cookie authentication. Project Goals The primary success criteria for the CASI project will be: Workstream 1: Creation of the New Authentication System The production deployment of the new centralized authentication Transition of at least two client services to use the new authentication in Production Workstream 2: Fat Cookie Transition and mod_auth_eid Modification Transition of all services currently using Fat Cookie authentication to the new authentication or alternative authentication mechanisms Transition of all services that use the current version of mod_auth_eid to its successor service or the new centralized authentication Workstream 3: UT Direct Transition and CWA Retirement Transition of all services currently using UT Direct authentication to the new authentication Retirement of the legacy CWA, including the Fat Cookie 4

5 Work Sequencing Overview The diagram below illustrates the high- level activities included in each project workstream and the relative sequencing of those activities. Schedule and Milestones Note: Schedule for design- phase and subsequent milestones will be determined during the workstream planning phase. Milestone/Deliverable: Workstream 1 - New Authentication System Target Date Approve project charter and customer steering committee membership 5/27/2011 Complete project planning for Workstream 1 7/22/2011 Begin design planning and documentation Complete design documentation Complete design review and validation Complete plan for implementation Begin implementation Complete development of Test environment Complete testing of Test environment Complete development of Qual environment Complete testing of Qual environment Complete development of Prod environment 5

6 Complete installation package(s) for early adopter client administrators Complete production service documentation (AUP, SLA, etc.) Complete transition of early adopter clients to new authentication Milestone/Deliverable: Workstream 2 - Fat Cookie/mod_auth_eid Complete plan for Fat Cookie transition and mod_auth_eid revision Complete list of services and contacts for the Fat Cookie and mod_auth_eid transitions Secure IT governance support for full transition from Fat Cookie authentication Complete identification and transition plans for full range of Fat Cookie client platforms Complete installation packages for all Fat Cookie client platforms Complete testing of installation packages for client platforms Complete transition plans for mod_auth_eid-authenticated services Complete modifications to mod_auth_eid Complete testing of modified mod_auth_eid Complete plan for dual-authentication support Begin transition of Fat Cookie services to new authentication Begin transition of mod_auth_eid services to new version of mod_auth_eid Complete transition of all mod_auth_eid services to new version of mod_auth_eid Complete transition of all Fat Cookie services to new authentication Target Date Milestone/Deliverable: Workstream 3 - UT Direct Transition/CWA Retirement Complete plan for UT Direct transition Complete design and plan for UT Direct server transition to Apache web server Complete design and plan for webtoken replacement implementation Complete transition plan for UT Direct services to new authentication Complete development of webtoken replacement Complete installation package for UT Direct platform Begin transition of UT Direct servers to Apache Complete testing of the webtoken replacement Begin transition of UT Direct services to new authentication and to webtoken replacement Complete transition of UT Direct servers to Apache Target Date 6

7 Complete transition of all UT Direct services to new authentication Complete retirement of the Central Web Authentication, including Fat Cookie authentication Complete project and release resources Scope In Scope The deliverables for the project will be as follows: Workstream 1: Implementation of the New Authentication System Project plan for the new implementation workstream System design documentation Procurement of third- party support for OpenAM Authentication implementation in Test, Qual, and Prod environments Production service documentation, including acceptable use policy, service level agreement, and authorization policies and technical schemes for the new authentication Identification and recruitment of early adopter client services Complete support package, including installer and documentation for administrators and developers, for early adopter client platforms Transition of at least two early adopter client services to the new authentication Creation of maintenance and stewardship documentation and processes Workstream 2: Fat Cookie Transition and mod_auth_eid Modification Project plan for the Fat Cookie and mod_auth_eid transitions workstream Roster of all Fat Cookie services and contacts Roster of all mod_auth_eid- authenticated services and contacts Fat Cookie client transition plan and communications Mod_auth_eid client transition plan and communications Design documentation for new version of mod_auth_eid Technical transition packages for all Fat Cookie client platforms Modifications to mod_auth_eid 7

8 Transition of Shibboleth login page to use OpenAM Support plan for dual- authentication interim period, including documentation for end users, Help Desk, and client support contacts Transition of all mod_auth_eid- authenticated services to the new version of mod_auth_eid Transition of all Fat Cookie client services to the new authentication Workstream 3: UT Direct Transition and CWA Retirement Project plan for the UT Direct transition workstream Design documentation and transition plan for UT Direct server move to Apache web server Design documentation for the webtoken replacement Design documentation and transition plan for UT Direct server move to new authentication UT Direct client transition plan and communications Technical transition package for UT Direct client platform Transition of the UT Direct servers to Apache in all environments Implementation of the webtoken replacement in all environments Transition of all UT Direct client services to the new authentication and to the webtoken replacement Retirement of the Central Web Authentication, including the Fat Cookie Project retrospective and documentation wrap- up Out of Scope Implementation of multi- factor authentication Implementation of a hook in the login process to enable IT Acceptable Use Policy renewal Implementation of authentication impersonation/proxy functionality Logging of EID authentication data from sources other than the new centralized authentication, such as TED, the mainframe, and Austin Active Directory Transition of EID- based mainframe login to centralized authentication machinery (for ST and FI COM- PLETEs) Implementation of centralized authentication access by UT- related services with servers outside the campus network 8

9 Project Management and Governance Role Name(s)/Title(s) Responsibilities Executive Sponsors Customer Steering Committee James Lewis, LAITS (AIC Chair) Brad Englert, ITS Greg Atkinson, FIS Cam Beasley, ISO David Burns, Business John Chambers, Computer Science Cesar de la Garza, Development Paul Grotevant, Undergraduate Studies Ladd Hanson, UT Libraries Nathaniel Mendoza, TACC Aaron Reiser, ITS Roy Ruiz, TRECS Charles Soto, Communications Tim Tashjian, Registrar Robert Trent, ITS Julienne VanDerZiel, ITS Approve project charter Approve project scope changes Vet requirements changes Review project progress Review and accept project deliverables Project Manager Kara Nicholas Create and manage project and transition plans Track and report on project progress Manage customer and stakeholder communications Project Team Other Stakeholders Audrey Barnes Scott Doane Kevin Dorff Paula May Sadia Rodriguez Dustin Slater Oliver Soell Autumn Shields Architecture and Infrastructure Committee Business Services Committee Research & Education Committee Administrative IT Leaders Campus server administrators and developers ITS Help Desk EID holders Create technical design documentation Contribute to customer and technical transition plans Create communications plans and documents Test new authentication Implement new authentication Create customer support documentation Provide customer transition support 9

10 Project Facilities and Resources The Operational IT (OIT) Committee has approved a capital hardware and vendor support budget for service development and recurring costs, based upon estimated server requirements. The detailed hardware needs will be determined during the Design and Planning phase, including a decision on whether to use virtual machines or physical servers. New servers will be purchased if required. The project team will be staffed from existing ITS Applications, ITS Systems, ITS OCSM and Information Security Office resources. Impact Analysis CWA client service s administrators and developers across the university in academic and administrative areas, as well as in ITS will be required to transition their services to the new authentication. EID holders during the dual- authentication period may experience discontinuity between services using different authentication s. The ITS Help Desk will provide primary support for authentication- related questions during the transition and may experience an increase in support calls. Technical service contacts around campus may also provide this support. The new centralized authentication 's reliance upon the utexas Enterprise Directory (TED) for authentication data will increase the criticality of TED and may require modifications to that service. Assumptions Ability to implement OpenAM successfully On- going support of the Digital Identity Management Strategy group Governance and executive support for ensuring retirement of all CWA client services, including Fat Cookie services Resource availability Constraints The new authentication will be built with OpenAM, following the CASA project recommendation. Risks Reliance upon a third- party product with which ITS has limited experience Reliance upon new hardware, supporting tools, etc. 10

11 Inability to implement intended functionality with OpenAM or significant customization required for implementation Excessive customization of OpenAM source code Significant obstacles to refactoring mod_auth_eid Obstacles to resource availability, including coordination of multiple Systems resources key to the project but not belonging to the core team Resource bottlenecks based on limited skill sets Coupling UTDirect servers migration to Apache at the same time that the servers are transitioned to the new authentication Inability to secure an acceptable support agreement for OpenAM Even with a support agreement for OpenAM, the new authentication will lack commercial vendor support Implementation planning around key university processing periods Inability to transition all Fat Cookie services within the specified timeframe Revision History Version Date Description v0.1 5/5/2011 Draft completed v1.0 5/10/2011 Revision based on director's feedback. Accepted without revisions by project sponsors. v1.1 7/1/2011 Revised CSC membership based on AIC feedback. v1.2 10/3/2012 Updated to reflect new executive sponsor, CSC, and project team members. Signatures Name Role Signature Date 11