Single-Sign On to HR

Single sign on (SSO) is a type of access control used to connect users of distributed systems to other applications without the need to authenticate to each individual system. By using one credential set, users are able to access a host of applications by providing their security credentials one time. Their credential set is then securely passed along to other systems in order to authenticate the user.

The HRIS allows your vendor to initiate Single Sign On (SSO) from the vendor's application to the HRIS authenticated using shared keys between the two systems. The can be accomplished by displaying the HRIS Application in an iFrame from the Vendor's Site or Application, or through a button click that signs the user into the Employee or Administrator Portal.

The HRIS also has established SSO integrations to specific vendors. These integrations allow a user to Sign on to a third party application through SSO with a third party vendor using a Link Button embedded in the Administration or Employee Portals.

Clearly the benefit of implementing SSO is the ease and reliability of connecting to multiple applications across different environments by using one credential set. Users only need to remember one credential set and can seamlessly connect to multiple applications and services. User password management is decreased because the number of credential sets a user needs to remember has been limited to one.

SSO works by establishing a trust between two distributed applications. The two applications exchange unique user identification information to each other and use that information to determine the identity of a user. During this exchange of information, no user names or passwords are sent to each application to limit the possibly of a compromised credential set.
With the HRIS, we can control user authentication in two ways:

  1. Users can log into the system with a user name and password
  2. Users can auto-login using SSO and have their user ID automatically passed to HRIS from a calling application

To understand how the second method works, you first need to have some background information on how an information system is architected. Each information system assigns a user a unique ID that uniquely identifies each user to a specific application. When a new user is created in an information system, a new unique ID is created for that user. No user will have the same ID as another user and this ensures that the system can identify specific users.

SSO to HR

When a user enters a host application, they will enter a user name and a password to authenticate them to the system. Once they are authenticated, they’re user ID is usually stored for the duration of their session while using that system. Infinity performs its SSO by obtaining the unique ID from a host application and using that credential set to identify and authenticate a user to the application.
To do this, the HRIS application needs a credential set to compare to its database of users configured in the system.

Credential Set

Vendor ID

A credential set is a data object which stores and passes information that uniquely identifies a user of the system. The vendor ID is one property of the credential set. The vendor ID is a unique ID that is generated by HRIS. This ID is given to the IT department of an organization and is used to identify a company or group in the HRIS system.

User ID

The user ID is the second property of the credential and it represents the unique ID provided by the host application. For example, if a user logs into a payroll application and then wants to seamlessly log into the HRIS application, the user ID from the payroll system would be the ID that is transmitted to HRIS. This will allow HRIS to correctly identify the user that is currently in session for the payroll application.

How are Credential Sets Transmitted

The HRIS system utilizes a browser post model which it uses to transmit information to its web servers for authentication. The browser post model is a process that allows an application to call a resource of another system and also pass information to that system. In this case, the credential set is passed to HRIS for processing. Note that the credential set does not contain the actual user ID and password of any user. It only contains their unique ID from the host application and the vendor ID of the group or company.

When a browser posts information to a server through the HRIS browser post model, it is doing this across HTTPS. This means that the information being transmitted is protected more than a normal request over HTTP. The definition and description of the HTTPS protocol is outside the scope of this document but can be researched online at http://www.w3.org/Protocols.

The browser post model is described in the workflow diagram below. For a more detailed document on the browser post model and how to program SSO for InfinityHR, please consult our technical document Programming SSO for HRIS.

Step 1 - Generate User IDs

In order for employees to have access to SSO, User IDs must be generated within HRIS. While these User IDs will not be used in the SSO Mapping, the HR User IDs serve as an important value to identify the user and their actions throughout the HR Application.

To generate User IDs for a company:

Employee Management - Username Format

To generate a User ID for an employee:

Demographic Info - Account

Step 2 - Map Users

In order to authenticate the user for Single Sign On, the vendor must identify a value from the vendor's system that will be recognized by the HRIS as belonging to the employee. This field is called the User ID field, and it can be any value that is unique to the employee. The Vendor will need to share this User ID value with the HRIS by mapping the User ID to an HR User.

Importing Data From a Data File

Mapping User IDs between systems can be accomplished in two ways. The first is through importing the user using the Import module.

The import type used is "User Accounts" and the layout is Single Sign On User Accounts.

Imports can be set up for scheduled import by following the instructions in the Custom Import Documentation.

Syncing Data through Web Services

Alternatively, the Web Service API can be used to map users from the Vendor's system to the HRIS. This is a more sophisticated method that requires the consumption of SOAP API web methods and looping through collections to identify and update the employee mappings.

The web methods you will use are as follows:

Authenticate()
GetEmployeesAll()
MapEmployeesForSSO() (or UpdateEmployees() which will update the Employee ID Value in HR)

Depending on the method of implementation, the code may need to loop through each employee and call MapEmployeesForSSO after populating the necessary EmployeeInfo object based on identifying employees with a shared value, like SSN.

Once the users are mapped through either method, you can write the necessary scripts to complete the SSO in the next step.

Step 3 - Post to Web Form

Browser Post Back Model Overview

The browser post back model is the primary means used to connect multiple applications to the HRIS application. This model assumes you have prior understanding of how an http request is made. The main idea is that your application will be making a call to the HRIS login web page and will pass both the Vendor ID which is provided by HRIS and the User ID which is the unique user ID from the host application.

Credential Set: Vendor ID

A credential set is a data object which stores and passes information that uniquely identifies a user of the system. The vendor ID is one property of the credential set. The vendor ID is a unique ID that is generated by HRIS. This ID is given to the IT department of an organization and is used to identify a company or group in the HRIS system.

Credential Set: User ID

The user ID is the second property of the credential and it represents the unique ID provided by the host application. For example, if a user logs into a payroll application and then wants to seamlessly log into the HRIS application, the user ID from the payroll system would be the ID that is transmitted to HRIS. This will allow HRIS to correctly identify the user that is currently in session for the payroll application.
Infinity Software Solutions, Inc.

Constructing the Launch Page or Control

Once you have access to the variables you are going to be passing to HRIS, the next step is to build a launch page or control that will be placed in your application to launch the HRIS application in a web browser. There are several ways to do this depending on your needs, the type of host application, etc.. Below are some samples of how a launch page would look coming from different types of applications.

Encoding the Credential Set

The credential set must first be base 64 encoding using UTF8 encoding before sending the credentials to HRIS. This is done to avoid sending the raw values for Vendor ID and User ID in the browser post.

Form Variables and Action

The following form variables must be posted to the HRIS system for a valid connection.

  1. VID – This is the Vendor ID that is provided to you from HRIS
  2. UID – This is the unique User ID for the user in your system

Form Action

Production Environment

[url]/ssologin.aspx

Launch Page: Web Application

In this example, a simple html page is created and a submit input control is used to perform a browser post to HRIS. Notice the form variables are input controls as well that hold both the Vendor ID and User ID. The form action is set to the HRIS login page and the form method is set to post.

SSO_-_00.png

Note that the input variables are not set declaratively in the form but are set at run-time. This will allow the developer to first base 64 encode the parameter values. The encoding should be set to UTF8.
Below is an example in C# of what the encoding would look like in your launch page.
Infinity Software Solutions, Inc.

Sample Code

SSO_-_01.png

Was this article helpful?
0 out of 0 found this helpful