Single Sign On Requirements

Single Sign On

Requirements

Table of Contents

2.1 Individual users: October Implementation ... 2

2.2 Business users: November Implementation ... 2

3 OpenID User Accounts ... 2

3.1 OpenID Provider ... 2

3.2 Create or Use Existing OpenID Account ... 2

4 Authentication/Verification ... 3

4.1 Login with OpenID ... 3

4.2 OpenID Token ... 3

4.3 User Validation ... 3

5 User Session Management ... 3

6 Existing Application Integration ... 4

7 New Development of Applications ... 4

8 User Entry Points ... 4

8.1 Applications – October implementation will be application based. ... 4

9 Navigation ... 6

9.1 Mapping Application ID’s to Users ... 6

9.2 Accessing multiple applications during a logged in session ... 6

9.3 Home Page Sign In – November Implementation ... 6

10 My DWS Page ... 6

10.1 Individual Services ... 7

10.2 Business Services ... 7

11 Required Data Fields (UMD) ... 7

12 Requested UMD API ... 9

13 Use Case Scenarios ... 9

13.1 New DWS User ... 9

13.2 Existing UMD User ... 9

13.3 User Maintenance via My DWS page ... 10

Appendix A ... 11

My DWS page Mock-Up ... 11

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.

3.2.1 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.

3.2.2 Single OpenID Account

A user may elect to have a single OpenID account to access DWS services registered to that user.

3.2.3 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.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.

4.1.1 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.

4.1.2 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.

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 18th_{, users registered with any of the services noted below must use}

OpenID credentials to authenticate.

8.1.1 UWORKS

 Search for Jobs

 Jobs I’ve Viewed

 View/Edit My Resume

 Employment/Education Assessment

 Apply for Training Services

8.1.2 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.

8.1.3 MyCase November Implementation:

Beginning November 8th_{, users registered with any of the services noted below must use}

8.1.4 UWORKS

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

8.1.6 Training Provider

8.1.7 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.

9.2.1 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 8th_{, 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.

10.1

Individual Services

10.1.1 Jobs

10.1.2 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)

10.1.3 MyCase

 Display information “MyCase contains information about your Food Stamps, Medical, Financial and/or Child Care case

 Display link to MyCase.

10.2

Business Services

10.2.1 Employment Exchange

10.2.2 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

10.2.3 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

10.2.4 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

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 Complete Initial Claim using CUBS Web

Step 2 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 Step 2a Get OpenID account

Step 3 UMD is queried via UMD API for an existing OpenID Step 3a If none, create a UMD account

Step 4 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.

13.2

Existing UMD User

Step 1 User visits jobs.utah.gov to search for a job

Step 2 UWORKS application prompts user for OpenID credentials Step 3 Authenticated user is queried in UMD by UMD API

Step 4 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

13.3

User Maintenance via My DWS page

Use cases assumes User has already authenticated.

13.3.1 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

13.3.2 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)

Appendix A