Single Sign On Requirements

Transcription

1 Single Sign On Requirements Updated August 23, 2010 Table of Contents 1 Vision Implementation Individual users: October Implementation Business users: November Implementation OpenID User Accounts OpenID Provider Create or Use Existing OpenID Account Authentication/Verification Login with OpenID OpenID Token User Validation User Session Management Existing Application Integration New Development of Applications User Entry Points Applications October implementation will be application based Navigation Mapping Application ID s to Users Accessing multiple applications during a logged in session Home Page Sign In November Implementation My DWS Page Individual Services Business Services Required Data Fields (UMD) Requested UMD API Use Case Scenarios New DWS User Existing UMD User User Maintenance via My DWS page Appendix A My DWS page Mock-Up NOTE: This document is subject to change based on developing Business Requirements.

2 1 Vision The vision of single sign-on for jobs.utah.gov is four-fold: 1. Provide a consistent, intuitive experience for users accessing DWS services online. 2. Integrate easily with existing jobs.utah.gov applications. 3. Serve as a common trust network; allowing applications to accept user verification completed by those with more stringent guarantees 4. Become a platform for future State of Utah enterprise authentication services. 2 Implementation Initial implementation of this project will be limited to certain user types. A User s requirement to use Single Sign On is based on the user type, or user s purpose for visiting jobs.utah.gov. The future direction for external users will be to use Single Sign On OpenID for authentication for DWS customer facing web applications that require a user to log in. 2.1 Individual users: October Implementation Users that could be/currently receiving UI benefits, applying for jobs, or receiving public assistance or any combination of the three will use an OpenID user account for accessing CUBS web, UWORKS Self Service and MyCase. 2.2 Business users: November Implementation Users that could be/currently transacting business with DWS for/as an Employer, Training Provider, or Child Care Provider or any combination of the three will use an OpenID user account for accessing CATS, UWORKS, and Child Care. 3 OpenID User Accounts 3.1 OpenID Provider OpenID user accounts will be determined by the user based on the OpenID provider the user has selected. 3.2 Create or Use Existing OpenID Account The user must have an OpenID account to authenticate with DWS Create New Account A user may chose to create a new account instead of using an existing OpenID account. This is solely the choice of the user Single OpenID Account A user may elect to have a single OpenID account to access DWS services registered to that user Multiple OpenID Accounts A user may elect to have multiple OpenID accounts to access a single or multiple DWS services. A user may elect to have multiple OpenID accounts to access multiple services. For example: a person who is receiving eligibility services and also Posts jobs for an employer, may choose access their eligibility case information with one OpenID and use a different OpenID account to Post a job for an employer.

3 3.2.4 Disassociate Application ID from Existing UMD ID Allow User to Disassociate Application ID from Existing UMD ID 4 Authentication/Verification 4.1 Login with OpenID The user will enter their OpenID credentials on the OpenID provider s login page. DWS will not collect and pass OpenID credentials Failed Authentication Users that fail authentication will be denied access to any application that requires authentication and must be provided instruction for re-entering OpenID credentials, and/or creating an OpenID account Successful Authentication Users that are successfully authenticated will be directed to the application based on the user entry point. If the user entered via an application, the user will be directed to that application, otherwise the user will be directed to My DWS. 4.2 OpenID Token After the user s OpenID has been authenticated, the user id s token along with any application identifier (not SSN) must be stored. UMD shall map one OpenID to many Application ID s. UMD shall map many OpenID s to one Application ID s. UMD shall map many OpenID s to many Application ID s. 4.3 User Validation Each application is responsible to validate the user. Each individual application will prompt users to provide their OpenID credentials as needed. 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. 5 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. SSO shall support a configuration for ending a session due to hard time-outs (e.g., the SSO login will time out 90 minutes after first created). SSO shall support a configuration for ending a session due to soft time-outs (e.g., the SSO session will time out after 20 minutes of inactivity). SSO shall support ending a session due to logout by the user. SSO shall support both application logouts and overall session logouts. SSO shall not require the user anything beyond a standard browser; ie Firefox, IE, Chrome, etc. SSO shall require cookies.

4 6 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. Each individual application will determine when to call the Login Page based on the application rules that require a user to login. 7 New Development of Applications Development of new applications that require authentication must use the SSO protocol. 8 User Entry Points 8.1 Applications October implementation will be application based. October Implementation: Beginning October 18 th, users registered with any of the services noted below must use OpenID credentials to authenticate UWORKS Search for Jobs Jobs I ve Viewed View/Edit My Resume Employment/Education Assessment Apply for Training Services CUBS Suite of Applications Obtain 1099 Tax Information - View your UI benefits paid and tax amounts withheld File New or Reopen Claims File a new claim or reopen an existing claim for unemployment or emergency compensation File Weekly Claims File weekly claims for unemployment benefits Complete a Weekly Filing Statement Complete statements for issues created when filing a weekly claim File Appeal Appeal your benefit disqualification Current Claim Status Review status of current claim Electronic Correspondence Center View or sign up to receive UI correspondence electronically UI Benefit Estimate - See how much you may be eligible to receive Eligibility Review Complete your requested review on-line NOTE: CUBS IVR is not part of Single Sign On. IVR users will continue to login and authenticate using a SSN and PIN. The CUBS web application must continue to require users to establish a PIN MyCase November Implementation: Beginning November 8 th, users registered with any of the services noted below must use OpenID credentials to authenticate.

5 8.1.4 UWORKS Post a job order

6 8.1.5 CATS File Tax Reports Report New Hires Register a New Employer Make a Tax Payment Amend a Tax Report View/Edit Account Information Training Provider Child Care Provider 9 Navigation 9.1 Mapping Application ID s to Users A user may be authorized and registered for multiple services with DWS. The application must map the application ID to the user at the initial authorization and store UMD. Application ID shall not be mapped to unauthorized users. 9.2 Accessing multiple applications during a logged in session An authenticated user must seamlessly access any application for which that user is authorized during the logged in session Querying UMD The authenticated user attempting to access an application, must be queried in UMD to determine the specific application id. 9.3 Home Page Sign In November Implementation Beginning November 8 th, the jobs.utah.gov home page will include a Sign In option. Users who Sign In from the home page will be directed to a Customer Home Page. NOTE: Adding the Home Page Sign In does not eliminate the Application based single sign on. Application based single sign on will remain functional. 10 My DWS Page The My DWS Page provides a central location of all DWS services of which a user is currently registered. The My DWS Page is dynamic, information displayed is relevant to registered services. In addition to the data displayed for registered services, the User must have access to update their profile. Updatable data includes: Assigning additional OpenID s Removing additional OpenID s The My DWS page data is grouped according to services; first group is Individual Services, the second group is Business Services.

7 10.1 Individual Services Jobs Unemployment Insurance Benefits Data includes: Claim status / Program: Active, UI (or EU) Claim begin date: mm/dd/yy Claim end date: mm/dd/yy Weeks remaining: ## Maximum benefit amount: $###,### Remaining balance: $###,### Weekly benefit amount: $### Issues preventing payment: None (or Yes) MyCase Display information MyCase contains information about your Food Stamps, Medical, Financial and/or Child Care case Display link to MyCase Business Services Employment Exchange Unemployment Insurance Employers Display the following links: File quarterly taxes Make a payment Amend a tax report Register a new employer Electronic correspondences The dynamic information would be as follows: Informing user if one or more of their employer accounts needs to file a quarterly report Informing user if one or more of their employer accounts has an amount due Informing user if one or more of their employer accounts has unread electronic correspondence Training Providers Provider Number Link to the training provider reports page Number of students that have paid money in the last 30 days Amount of money received in the last 30 days Time when next recertification is due Child Care Providers 11 Required Data Fields (UMD) OpenID (multiple) Field type = String Application/Application ID (multiple) Field type = Hash table of String, String Last login datetime Datetime field

8 NOTE: is not required for DWS Single Sign On.

9 12 Requested UMD API Methods/Functions of API: 1. Search for User by OpenID Returns last logged in datetime 2. Get application specific id by OpenId/Application 3. Create account with OpenID 4. Add OpenID to existing account 5. Remove OpenId from existing account 6. Add application id to existing account 7. Remove application id from existing account 8. Merge two UMD accounts by OpenID NOTE: Remove OpenID must retain one OpenID 13 Use Case Scenarios 13.1 New DWS User A new customer files an initial unemployment insurance claim. Step 1 Step 2 Step 2a Step 3 Step 3a Step 4 Complete Initial Claim using CUBS Web At the end of filing the claim, the user is required to enter their OpenID credentials and authenticate, OpenID is stored in DWS SSO Session Get OpenID account UMD is queried via UMD API for an existing OpenID If none, create a UMD account Map CUBS Web application id to UMD Account, via UMD API Extension: Job Search no UWORKS account Step 5 User clicks link to Register for Work Step 6 UWORKS application queries UMD using UMD API for application Id, based on users OpenID Step 6a If application id is not found in UMD, user must register for authorization Step 6b At the completion of registration the UWORKS application id is assigned to the UMD account, via UMD API Step 7 User is granted access to UWORKS without additional login Existing UMD User Step 1 Step 2 Step 3 Step 4 User visits jobs.utah.gov to search for a job UWORKS application prompts user for OpenID credentials Authenticated user is queried in UMD by UMD API UMD returns UWORKS application ID and user is granted full access to UWORKS Extension: User also is an eligibility recipient of food stamps Step 5 User clicks the My Case link to access case information Step 6 My Case application queries UMD for application ID via UMD API Step 7 UMD returns My Case application id and user is granted full access to My Case Step 7a My Case may require additional user validation

10 13.3 User Maintenance via My DWS page Use cases assumes User has already authenticated User wants to register additional OpenIDs to UMD account Step 1 User clicks link to add additional OpenID Step 2 User is prompted to enter OpenID credentials Step 3 Upon successful authentication, user s secondary OpenID is added to existing UMD account via UMD API User wants to remove secondary OpenID from UMD account Step 1 User clicks link to remove additional OpenID (At least one OpenID must exist users cannot remove all OpenIDs) Step 2 OpenID is removed from existing UMD account via UMD API

11 Appendix A My DWS page Mock-Up

12