Single Sign On

Overview

Single sign-on (SSO) is a mechanism of access control that can be applied on multiple related, but independent software systems. With this mechanism a user logs in once and gains access to multiple systems without being prompted to log in again for each individual application. Conversely, single sign-off is property mechanism whereby a single action of signing out terminates access to multiple software systems.

As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication.

Ephesoft Transact has been tested with the following SSO-related components:

  • SAML 2.0 — An XML-based protocol that entails security tokens for authentication and authorization. Ephesoft Transact supports SAML 2.0, and has tested and certified the following identity providers that are compatible with Ephesoft Transact:
    • ADFS
    • Okta
    • PingFederate
    • SSOCircle

For additional information about configuring SAML 2.0 SSO with Ephesoft Transact, please refer to the following document:

Manually Configuring SAML 2.0 SSO for Ephesoft Transact 4.5.0.x

  • CAS-based SSO Framework — CAS is an Enterprise Java solution for web application authentication that also provides the benefit of Single Sign-On (SSO).

For additional information about CAS-based SSO with Ephesoft Transact, please refer to the following document:

SSO | CAS-Based SSO Framework

  • Transport Layer Security (TLS) — Ephesoft Transact 4.5.0.x supports TLS versions 1.0, 1.1 and 1.2.

Benefits

  1. Reducing password fatigue from different user name and password combinations.
  2. Reducing time spent re-entering passwords for the same identity.
  3. Reduced Logins For Discreet Systems
    1. Corporate Systems
    2. Shared Intranet/Web Applications
    3. Web Logon Aggregators
  4. Reduced cost to reset a password
  5. Reduced time spent logging into multiple systems each time
  6. Reduces multiple authentication, unnecessary user clicks, forgotten passwords, multiple profiles.
  7. Limited time and resources to develop IT solutions.

Challenges

  1. As single sign-on can provide access to many resources/systems at once using a single credential (“keys to the castle”). This may be misused in case the credentials are available with other person.
  2. Single sign-on also makes the authentication systems highly critical; a loss of their availability can result in denial of access to all systems unified under SSO.

Supported Identity providers

Ephesoft Transact has been tested with the following SSO-related components (refer to the Overview at the start of this document for additional information):

  • SAML 2.0 — with the following identify providers:
    • Okta
    • PingFederate
    • SSOCircle
  • CAS-based SSO Framework

If you would like to deploy SSO with another identity provider, please feel free to contact Support by emailing us at tickets@ephesoft.com

Designs

Follow are the basic design patterns used to implement single sign on solutions.

1.  Ad-hoc Encrypted Token — Not currently supported

Applications use symmetric and public key cryptography to encrypt the application data that are used for SSO. Refer to the following illustration:

400px-3.1_SingleSignOn_10001

This SSO design can be integrated with Ephesoft using Active Directory only. A key store has to be maintained in all the applications which are to be unified under SSO. Thus such a provision must be available on applications which are to be unified under SSO.

Pros:

  1. This is easy to set up and implement.
  2. There is no dependency on another system.

Cons:

  1. This is not a unified solution.
  2. Each site has to manage the cryptographic key.

2. Using Third-party SSO Agents or Identity Management Systems (IdPs) — Supported Method

This approach supports identity providers (IdPs) such as OAM, SiteMinder, and so on. 

In this approach, the Ephesoft application uses the service provided by SSO agents. Refer to the following illustration.

400px-3.1_SingleSignOn_10002

The Ephesoft solution is currently based on this design (design # 2).

Description

Ephesoft application can now be configured using following security types:

  1. Ephesoft default Security using LDAP, AD, Tomcat.
  2. SSO authentication and Authorization at Ephesoft end using LDAP, AD etc.
  3. SSO authentication and authorization.

The security type for the Ephesoft application can be configured in the web.xml file.

The following properties must be configured in the web.xml file:

1.       authenticationType — context parameter for defining the security type mentioned above.

This property can be configured with the following values:

  • 0 — Ephesoft default Security using LDAP, AD, and Tomcat
  • 1 — SSO authentication and Authorization at Ephesoft end using LDAP, AD, and so on
  • 2 — SSO authentication and authorization

Refer to the following illustration:

2.       When configuring the authenticationType parameter cited above with a value of  1 or 2, then following parameters also must be configured:

A.      The following parameters needs to be configured for the authenticationFilter filter:

  • requestUsernameHeader — This is used for defining the header name used by the SSO agent to set the user-name of authenticated user in the request. The same header name will be used by the Ephesoft application to fetch the desired information from the SSO agent. (This must be used for both types of security types, that is, 1 and 2.)
  • logoutUrl — This is used for defining the logout URL where user will be redirected by the Ephesoft application after the user logs out by clicking on Sign-out button in the application. The complete URL is expected for this parameter value. (This must be used for both types of security types, that is, 1 and 2.)
  • requestGroupnameHeader — This is used for defining the header name used by the SSO agent to set the group name which belongs to the authenticated user in the request. The same header name will be used by the Ephesoft application to fetch the desired information from SSO. Only one group name is expected for this header value. (This must be used only for security type 2.)
  • requestSuperAdminHeader —This is used for defining the header name used by the SSO agent to set whether the group name belonged to the super admin role or not in the request. The same header name will be used by the Ephesoft application to fetch the desired information from the SSO agent. The values supported for this header are true and false. (This must be used only for security type 2.)

Refer to the following illustration for examples of these parameters:

400px-3.1_SingleSignOn_10004

B.      All the <security-constraint> and <login-config> settings must be commented or deleted because these components are managed by the SSO agent.

C.      A default_group property has been added in the application.properties file. This setting defines a default group to be used in case the group name is not provided in the request header. (This must be used only for security type 2.)

IMPORTANT: For security types 1 and 2, any realm configured for the Ephesoft application (configured for earlier shared releases) needs to be removed.

Defining Session Timeout Settings

Ephesoft Transact must be configured with the following settings, along with other configurations communicated from Ephesoft:

Remove the new session timeout feature in cases where the authentication type is set to 1 or 2.
Perform the following steps:

1. Comment the SessionTimeoutFilter and SessionTimoutServlet entries in  the web.xml file.

Refer to the following illustration as a sample of these settings:

2. Remove the entry of session-timeout.js from all the html files.

Refer to the following illustration as a sample of this setting:

Conclusion

Ephesoft can now be integrated with single sign on (SSO) systems for purpose of authentication, authorization or both.