What is Single Sign-On (SSO)?
SSO is a session and user authentication service that permits a user to use a single set of login
credentials across multiple applications in an organization.
Challenge cyber-attack through SSO
Advanced authentication can be easily and quickly deployed with SSO framework. Cyberintruders mainly target usernames and passwords, and they have a penetration opportunity every time a user logs in to a new application. Since users generally log in once every day and only use one set of credentials, SSO limits the number of attack surfaces. Enterprise security is enhanced by limiting the login process to one set of credentials.
Cost optimization through SSO
SSO also saves time and aggravation on password resets, lowering IT expenditures. When each program demands a unique login and password for each employee, there is a good risk that they will not recollect them, and support tickets for password resets will pile up. With SSO users only have to remember one set of credentials with SSO, which reduces the frequency of support tickets. Furthermore, most SSO solutions allow users to reset their passwords on their own, eliminating the need for IT intervention.
Introduction of SSO and its features from Summit v6.2
SSO is almost mandatory across financial institutions, and Finastra Summit supports it. Even so, the activation is not quite as seamless as the service it provides. GreenPoint Summit took on the challenge of implementing SSO for Summit at a large global bank, and encountered and resolved the hurdles. Up until Summit v6.1, an institution could implement their own authentication logic as a part of
two-factor authentication. The workflow is described below.
- Summit v6.1 front-end passes user login credentials to the eToolkit server for authentication
- When a client customizes the extendable authentication process, the eToolkit server invokes a client-extendable authentication function, which is part of the Security Extendable API. Clients can implement their proprietary authentication logic in this function
From Summit v6.2 onwards, SSO functionality was implemented with the following capabilities:
- Supports for OpenID Connect (OIDC) Authentication workflow
- OIDC is an authentication protocol built on OAuth 2.0 that can be used to securely sign in a user into an application
Multiple challenges were faced while implementing the Azure SSO.
GreenPoint Summit, the Summit speciality services team at GreenPoint Financial, worked on a full upgrade to v6.2. As part of the upgrade project, the Azure SSO was implemented in a client environment.
There is an Azure ID and Summit User ID mismatch…
The first issue encountered was a difference in the way User IDs are used for authentication between Azure and Summit. To begin with, a basic setup of SSO was attempted. This revealed the initial differences between these systems.
- Summit v6.2 uses Azure preferred_username claim for user authentication. This claim represents the user in Azure. It can be an email address, phone number, or a generic username without any specified format. Its value is mutable and subject to change over time. The preferred_username claim was configured in the client Azure environment.
- In a client environment, this preferred_username is set to the email id of the user. However, the Summit login ID is already a specific User ID. This created a mismatch between the User ID returned by Azure and Summit User ID because of which the SSO was unsuccessful.
The next solution that was tried was to enable the SSO authentication through ‘sso_mapper’.
The sso_mapper utility is used by the Open ID Connect feature to encrypt information from the input text file and add it to the dmSSOMAP table.
Unfortunately, the length of the generated value could not be stored in the table as the value by sso_mapper was greater than the column length. Therefore, the insertion into the dmSSOMAP table was unsuccessful.
To resolve this issue, an OIDC custom claim ‘on_premises_account’ was introduced in Summit, with the same being added to the Azure client environment.
This allows clients to add a User ID as the value of this claim. Summit fetches this value in the backend from the decrypted token and uses it to check in dmUSER if the user exists and allows authentication. The mismatch issue between the two systems was resolved using this approach, based on knowledge of Azure and Summit.
Find out about the other challenges encountered by GreenPoint Summit during SSO integration in our next release.
