Multi-Factor Authentication

Transcription

1 Executive Summary Done: 1. Based on the team s initial assessment, the team recommends that we use Symantec s product. Unless the team identify serious issues during proof of concept (target completion date: July 31), we expect that we ll choose Symantec s product as our multi-factor authentication solution. The final purchasing decision will not be made until after we complete the proof of concept. 2. Major decisions made: a. Services that need to be delivered: i. Authentication (IAM): first day of pilot ii. Provisioning (UW Digital ID): first day of pilot iii. Contingency access (UW Digital ID): first day of pilot 1. Self-service (100% functional) 2. Help desk iv. De-provisioning (UW Digital ID): first day of pilot 1. The functionality needs to be there whether it is done manually or automatically v. Reporting/auditing (UW Digital ID, IAM, HRS Security): TBD b. Contingency access options: i. Challenge questions: available and will be recommended to users ii. SMS: available iii. Voice: available c. Authentication method: campus credential + token (OTP): no pin will be required 3. The project s wiki site ( Factor+Authentication+Home) has been reorganized so that project stakeholders have a clear way to obtain official project information. The main page contains two main sections: i. Official Documents: everything that is listed under this section is official information. Only project managers and project leads should be allowed to post information under this section. ii. Working area: ideas, thoughts, unfinished documents the information is not official. Any team member can use this section to share their ideas and thoughts. 4. An FAQ page (Attachment A, has been created to provide answers to some of the frequently asked project questions. As more decisions are made and more information is available, this page will be updated with new decisions and information. 1

2 To Do: 1. Campus communication a. LRA b. Help Desk c. Identify Managers d. HR Directors e. Core Users 2. Decisions need to be made (by Project Leads or Project Sponsors) on the following decision points by July 12 th in order for the team to meet the December 15 th deadline: a. Deploying multiple instances or a single instance of the service (Appendix A) b. How will we authorize OTP users in the UWDID application? c. How often may a user request a static OTP? d. When a credential is reported lost or stolen, should it be immediately revoked? (Recommendation: Yes, lost means permanently lost, not I forgot it at home). e. Does the user have to be credentialed when being issued subsequent tokens after the initial token? (Software or hardware)? f. How many and what type of challenge questions will be required for contingency access? g. There is a gap regarding EMP direct database and Interactive reporting access. Must this gap be addressed by December 15 or is this an item that we can address after the December date? Tentative High-level Timeframe Absolute deadline for HRS implementation (all campuses) is December 15, Any activities between now and December 15 have flexible target dates: Requirements Verification: April 30 Integration Design Option April 30 Proof of concept including Target Date: July 31 Design Review and Approval (User) Development Purchasing decision Target Date: August 5th Integration/Development: Target Date: August 31 Testing: Target Date: September 14 Pilot Target Date: September 15 to October 1 We need to be sensitive to campus s LRA s workload at the beginning of the semester. Staggered Deployment: Target Date: October 1 to December 15 2

3 Project Management Project management is responsible for identifying and tracking project tasks; identifying potential dependencies that impact the deliverables; communicate project status and manage project documentation (charter, requirements, plans etc.) Completed Activities Reorganized project wiki page Created an FAQ ( ) page Scheduled Symantec conference call (06/18) Scheduled RSA conference call (06/19) Ongoing/Upcoming Activities Continue working on the FAQ page Identify campus Help Desk managers Identify pilot campuses Application Integration and Deployment This tier is responsible for developing and reviewing processes, verifying requirements, testing and support during pilot and deployment phases. Completed Activities IAM-TAG presented the Integration Scenarios for OTP vendors Ongoing/Upcoming Activities Participate with vendor reviews UW-Digital ID UW-Digital ID is responsible for designing, documenting and providing training on issuance, maintenance and support of Tokens. Completed Activities Tested the Symantec Web API (Part of Proof of Concept) with the following functions: o Adding a user o Updating a user o Deleting a user o Adding a credential o Updating a credential o Removing a credential o Authenticating a credential (for testing purposes only) o Setting a temporary OTP o Sending temp OTP via SMS 3

4 o Sending temp OTP via Voice o Clearing a temp OTP Completed the first draft of issuance procedure Ongoing/Upcoming Activities Continue proof of concept with Symantec o Identify and document issuance and reissuance processes (the initial draft is completed; the process may need to be modified depending on the findings from the proof of concept) o Identify and document contingency access process (the initial draft is completed; the process may need to be modified depending on the findings from the proof of concept) o Develop self-service function for contingency access o Work with IAM and Security teams on reporting/auditing function Help identifying campus LRAs (start a list) Initiate communication to campus LRAs Middleware / IAM Middleware is responsible for building the agreed upon business solution once approved by the Multi-Factor Authentication governing bodies. Completed Activities Started proof of concept o Can authenticate users Ongoing/Upcoming Activities Continue working on proof of concept o Work with UW Digital ID and Security teams on reporting/auditing function (Proof of concept) o Work on authentication shim Work with UW Digital ID team on standard audit log o Work on building interface to Shibboleth o Work with HRS security to identify a way to automatically generate core user information o Work with Identity Management Team on adding additional Shibboleth attribute to identify core users Identify OTP integration strategy Continue working on technical requirements this won t be clear until we work on proof of concept with the vendor Help identifying campus Identify Managers Help identifying campus LDAP contacts Project Dependencies 4

5 Purchasing an OTP solution Solution functionality on providing a temporary form-factor for contingency access Customer s participation in communication process 5

6 Project Governance Structure Executive Committee Project Sponsor Lorie Docken John Krogman Project Lead Chris Liechty Stefan Wahe Project Manager Ching-tzu Chien Al Crist Julie Gordan Larry Henderson Customer Key Stakeholders CIO Council (Lorie Docken) HRS Functional Support (Larry Henderson, Mike Gollmar, Brad Bruegger, Rachel Holmquist) SFS Controlers (Julie Gordon) UW-TISC (Chris Liechty) UW-MIST (Stefan Wahe) ISIS MMT (Ilene Seltzer) OCIS (Jim Lowe) ITLP Project Team (Jeff Savoy, Mike Gollmar) IAM Steering Committee (Elena Pokot) Purchasiing Ruth Ginzberg End User HRS, SFS, and other potential common system users Vendor Team Lead Stefan Wahe John Kotolski Nick Davis Josh Campbell Team Lead SFS Josh Campbell John Kotolski Stefan Wahe Team Lead HRS Service Center John Kotolski Brad Krause Derrian Jones Mike Gollmar Team Lead Ty Letto Mike Roszkowski Bob Stenson Jeremy Scott Ryan Larscheidt Mark Weber Team Lead Joe Tarter Nick Davis Chris Spencer Andrew Hoffmann Other Support Training Communication HRS(Tim Miller, John Kotolski, Diane BlaskowSki) SFS (Ben Integration Design Team IAM Technical Advisory Team (Tom Jordan) IAM Support Team (Ty Letto) UW-Digital ID (Chris Spencer) Service Owner UW-Digital ID (Joe Tarter) DoIT Security Application Support/Security IAM Project Team UW-Digital ID Other Project Documentation All project documentation (project plan, status report, meeting notes, etc) is stored in the project s wiki site ( Factor+Authentication+Home). The site serves as the official source of project information. All project stakeholders except for those who do not have wiki accounts have been granted site access. These individuals need to login to at least once to have their wiki account created. Project Charter: 6

7 Communication Plan: Appendix A: Decision Document 1. Deploying multiple instances (one per campus) or a single instance of the service Symantec s solution (VIP Manager) requires us to set up 16 instances (one for each campus). The July 16 th new release may allow us to only set up one account. However, if the team has to wait until July 16 th to decide on the integration approach, there s a huge possibility that we will not be able to meet the December 15th deadline. IAM-TAG presented the Options for One-Time Password Integration with HRS diagram (Attachment B) back in April The team decided that we would start with option 1 (OTP as a Wisconsin Federation Service) as a short term solution and then move to option 2 (OTP as a Campus Login) as the long-term solution (with the transition plan). We also don t want to preclude vendors that provide option 4 (OTP at the Network). The current version of VIP Manager does not allow us to implement option 1 and will force us to implement option 2 right away (if we cannot wait for its July 16 th new release which may allow us to only set up one instance). A decision needs to be made on whether we want to deploy multiple instances now for the HRS phase. Option 1: Deploying Single Instance Advantages: 1. Can be implemented in timeframe requested 2. Can be extended to SFS 3. Allows campus-by-campus migration to performing OTP 4. authentication for campus applications in the future 5. Does not require a change to the login interface for anyone other than HRS professional users. Risks: 1. Will work only for Wisconsin Federation apps will not work for local campus applications unless the application is integrated into the Federation. 2. Will not work for InCommon Federation apps 3. It is not available with Symantec s product until July 16, 2013 this may cause us not to meet our December deadline. Option 2: Deploying Multiple Instances Now 7

8 Advantages: 1. Provides long-term flexibility: is extensible to campus application as well 2. Can be used for InCommon or other external federation applications Risks: 1. Requires a change to each campus login server 2. OTP login option would be visible to all campus IdP users, not just HRS professionals 3. Creates service complexity and thus supportability UW Digital ID was designed with the goal of providing a -consistent- service experience across all system campuses. That consistent experience has the additional benefit of simplifying the service design, documentation, and supportability. In addition, the team needs to stay focus on implementing multi-factor authentication for HRS by December 15, With it stands, UW Digital ID team is not clear how that is possible with the multi-le service instance model. 8