Single Sign On Business Case

Transcription

1 Single Sign On Business Case Project Name: Project Requestor: Project Director: Single Sign-On Steve Cuthbert Dave Ostrom 1.0 Introduction Single sign-on (SSO) is a property of access control of multiple, related, but independent software systems. A user logs in once and gains access to authorized systems without being prompted to log in again at each of them. Consider the following example: Jane is a dislocated worker receiving training funds, unemployment insurance, and food Stamps while looking for work and providing child care to another DWS customer. For Jane to access all of the systems managing these services, she would need at least five different log on accounts. Using Single Sign On, Jane would be authenticated once when she accesses a DWS system that is providing her service. When she requests access to other authorized DWS systems, an exchange of information would take place behind the scenes to establish her credentials. Once established and authorized, she would be allowed to enter any authorized system. From her perspective, entry across systems would be seamless. Authenticated customers would be directed to a landing page providing an Overview/Summary of the customer s information, authorized services, required tasks, DWS communications specific to authorized services, or if not registered with any service, a list of possible services. NOTE: The design of a landing page will be determined by a specific committee. 1.1 Problem / Opportunity Statement Many DWS customers access multiple DWS systems. These systems require the user to be authenticated and authorized for each system accessed. In order to be granted access, users must prove their identities. For the most part this is done by providing different authentication credentials; e.g., userid, password, PINS, etc, to each and every web application. This is an obvious inconvenience to the user. Each of these web applications requires the redundant development and management of authentication. Currently, authentication varies from system to system i.e., username and password, address and password, social security number and user defined pin, case number and DWS defined pin, etc. resulting in the end user having to manage multiple usernames and passwords in various formats. This hinders the objective of DWS to integrate services under a single umbrella. Various Gartner studies have estimated that 25% to 35% of calls made to help desks are related to password resets. Analysts estimate costs at approximately $25 to $40 per call with four password reset calls per user per year. Various DWS web application user password activities are managed by Single Sign On Project Business Case Page 1 of 5

2 front line DWS workers. If a customer has a determined number of unsuccessful login attempts, the account is locked and the password must be reset by a DWS worker. DWS web applications that create PINS require a user to return an for verification of their account. Often these s initiated by DWS fall into Spam or Junk Mail folders. People using the auto-delete Spam/Junk Mail never receive the DWS to verify their account. These people must call a DWS worker to have their password reset. Users who must manage large numbers of passwords either ignore recommended strong password rules by adopting easy-to-remember formulas or keep a written record of their complex passwords as a memory aid. The simple passwords are easy to hack, and the password lists are easy to steal. Either way, security is compromised. 1.2 Business Value Simplified login reduces the many confusing username/password options users must navigate today to a few secure methods standardized across all DWS systems; effectively reducing the number of calls associated with password support and creating a seamless, secure, integrated environment for DWS customers. 2.0 Current Environment DWS has 14 customer-facing systems that require user s to register and create accounts for access. Each of these systems has varying credential requirements for authentication. Some do not actually authenticate at all. System Not only are these web applications not developed on the same platform, but the authentication protocols are also not the same. Unemployment Suite of Applications - CUBS Employment Exchange (Job Seeker) - UWORKS Employment Exchange (Employer) - UWORKS Job Training Provider - UWORKS Supportive Services - equery Authentication SSN / PIN address / password address / password Username / password Case # / PIN Data Elements to Create Acct SSN, DOB, gender, mother s maiden name, PIN First and last name, SSN, DOB, Gender, address UI ID and FEIN DWS issued Provider # and name Case #, PI DOB, address Platform ASP.NET/with mixture of C# and vb.net Unemployment Suite of Contact Info ASP.NET/with mixture of C# and Applications - CATS address / password vb.net Child Care Provider address / password License # and contact info Appeals SSN / PIN Employer ID / PIN.NET Almost all of these systems can be accessed by the same individual but in a different role. Users of these systems include: Unemployment Insurance Claimants Job Seekers Employers Single Sign On Project Business Case Page 2 of 5

3 Providers Supportive Services customers Scenario In today's economy, a UI claimant that is on furlough could be receiving Dislocated Worker funds, Food Stamps and be looking for another job. To register for these services with DWS, the user would be required to login to the Unemployment Suite of Applications to file their weekly UI Claim; the Employment Exchange to register for work and search for a job; and the Public Assistance application to access their food stamps case information Each requiring separate usernames and passwords. For everyone who files an initial UI claim, they will almost always file continued claims (which is how payment is made). Also those who file continued claims will eventually have an eligibility review and could likely have an appeal. Everyone who files a UI claim and is not deferred is required to complete a work registration within five business days, using UWORKS to search for jobs. 3.0 Business Requirements 1. Users must use a single username and password to access all DWS systems for which they are registered, authorized, authenticated and verified. 2. Users manage their own password activities, including creating passwords, resetting passwords, changing passwords, etc. DWS applications/customer directory will not store passwords. 3. Users only have access to services for which registration and authorization are granted. 4. Users must not have to log into a DWS website to access information that they can currently access without a login. 5. SSO shall not affect the availability of services provided in the DWS offices. 6. SSO must be a seamless transition for users of current DWS web applications requiring username/ address/case number/ssn/employer ID and passwords/pins for access. 7. The jobs.utah.gov home page and all subsequent pages must identify the logged in user and provide a log out button. 4.0 Technical Requirements 4.1 Authentication/Verification User validation will be the responsibility of individual applications. For example: to file for unemployment, users must provide a verified ssn and Utah driver s license (or Identification Card). Once a user identity has been established, individual applications will prompt users to provide their OpenID credentials. Users who do not have an OpenID, will be guided through the registration process. DWS must adhere to OpenID Exchange guidelines as to which OpenID providers the agency will accept based on their level of trust. After a user s OpenID has been authenticated, the single sign on service will store the user id s token along with any application specific identifier (not SSN). Users with verified OpenID credentials that visit jobs.utah.gov may or may not be prompted to re-authenticate, depending upon the security Single Sign On Project Business Case Page 3 of 5

4 requirements of the individual applications. We envision that most applications will require users to re-authenticate. 4.2 User Session Management To facilitate single sign on between DWS applications, user information must be shared. This will be accomplished via shared user session management. Each DWS application must include user session management and user session timeout, configurable at the application level. Users logging out of the browser session automatically logs the user out of all DWS web applications. 4.3 Existing Application Integration Implementation of Single Sign On service will have minimal impact on existing applications. Where possible, Single Sign On service will be modified to meet the need of the existing application code. This includes but not limited to using existing user primary keys and adding fields to the Single Sign On database as needed. 4.4 New Development of Applications Development of new applications that require authentication must use the SSO protocol. 5.0 Future Environment Web Single Sign On will be implemented for DWS internet applications that require external users to provide some form of authentication and require authorization for access. DWS customers will be self-sufficient in navigating DWS websites and authorized services. 5.1 Single Sign-On Process Flow Below are the steps of a typical Single Sign On registration scenario. 1. User visits one of the jobs.utah.gov online services. 2. User registers with the online service 3. Online service validates user information 4. User is prompted to provide OpenID credentials. a. If OpenID credentials do not exist, the user will be guided through the OpenID registration process. In the case of existing registered users, the user will be prompted to enter their OpenID credentials and the application will prompt for any additional user verification data. 6.0 Potential Risk If a user s OpenID is compromised, our applications would be subject to unauthorized access. To mitigate this risk, DWS applications will require the user to provide additional data that identifies the user. 7.0 Solutions Analysis and Estimation 7.1 Solutions Analysis Single Sign On with OpenID Single Sign On Project Business Case Page 4 of 5

5 Use OpenID issued by third party OpenID providers who are members of the Trust Network to authenticate users. Develop DWS web applications using Single Sign On protocol accepting authentication by Trust Network OpenID providers. 7.2 Cost Estimates and Assumptions Assumptions: 1. Legacy systems will be modified to use Single Sign On protocol. 2. Web applications will be implemented in phases Costs: The costs include: - Development of OpenID integration - Integration of existing applications with Single Sign On service - Separate cost incurred for integration of each application 7.0 Recommendations Begin implementation of a Single Sign On protocol to include Phase I applications implemented by September 30, Phase I - Unemployment Suite of Applications - CUBS - Employment Exchange UWORKS - Supportive Services (equery) Phase II Unemployment Suite of Applications - CATS Child Care Provider Appeals Applications identified as out of scope include: eshare Refugee Data Collection Single Sign On Project Business Case Page 5 of 5