Wikipedia: Is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Conversely, single sign-off is the property 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.
Enterprise Single sign on as it always should had been
Single sign on is a core feature of Soffid IAM. But despite how other products behave, Soffid single sign on is not a standalone product detached from Identity and Password management tools, and now we shall prove how superior this approach is.
Login process
The first feature of a single sign on is to identify the user in a non intrusive way. There are many ways to do it, and Soffit let the user and administrator to choose between a large range of mechanisms:
• User and password. Of course, it’s the simplest way to go.
• Smart card X509Certificate. Soffid is able to manage any smart card device with an PKCS#11 interface. Using the smart card PIN, Soffid tries to use the private key stored at the smart card, and sends Soffid server a digitally signed challenge along with its X509Certificate. Soffid unique approach is able to bind this X509Certificate to any user based on the certificate attributes. This approach makes the use of public PKI extremely easy to deploy, enabling the use of national or government issued ID Cards.
Of course, Soffid can also manage any kind of self issued certificates.
• Coordinates card. Used as an extra security layer, a coordinates card can be requested in order to get access to some privileged desktops or applications.
• Kerberos is also accepted, enable the user to log on at the single sign on session without any intervention required. This feature enables an Active Directory seamless deployment.
Credential injection
Credential injection is the usual task of a single sign on environments. This task is accomplished in two steps:
• Step 1: User interface detections. At this step, the SSO tool is continuously monitoring the user interface to detect for credential requests.
• Step 2: Once a credential request interface is detected, the tool should be able to send those credential in an application accepted way.
The first step needs to balance between accuracy and performance. The detection engine should not introduce a noticeable overhead on the system, but on the other hand, it should not be wrong and detect a trusted application instead of a generic one.
In order to make a high performance, extremely accurate engine, Soffid makes extensive use of XML patterns. We have a tool that translate the application user interface into an XML pattern that can be customize by Soffid administrators. This XML patterns are suitable for web, java or native windows applications with slightly differences.
Once customized and released to SSO desktops, those patterns are compiled in a binary format for each user process, streamlining the user interface detection engine. The final result is a high performance, extremely accurate behavior.
The second step needs to be flexible and powerful. At this phase, a little overhead is accepted as long as it is going to be triggered once, just when the credential user interface is about to displayed. At this phase, the engine should be able to enter text on any text box component, as well as introduce delays, click on check boxes or buttons or simulate any hot key press.
To accomplish this step, Soffid delivers an efficient ECMA script (also known as Javascript) interpreter that enables the Soffid administrator to define the desired behavior. With this approach, no application will resist.
In conclusion, Soffid ESSO engine brings users and administrator a responsive, flexible and powerful single sign on tool with a very low impact on overall performance.
More than just ESSO. A step further.
Sometimes, due to technical or functional reasons, a user has two or more accounts on a system. In such a case, the traditional SSO solutions are not able to manage it in a proper way. With Soffid ESSO, the user will be presented the list of accounts that are suitable for the current application. After selecting one of them, Soffid will use them to perform log on on behalf of the user.
But this multiple accounts management goes a step further. As long as you can define shared and high privileged accounts on Soffid IAM console, the user will only be able to choose from the actual list of authorized accounts. This enables the administrator to define a DBA account that can be used by any company DBA, but ensuring that no one knows its password. By the other side, Soffid IAM can change it’s password daily without any service disruption as long as Soffid ESSO engines are notified on the fly. DBA users don’t need to restart its SSO session in order to login with the new credentials as soon as they are changed.
Keep passwords private
One convenient way to get passwords private is to disable the ability to login with the same user from two devices at the same time. If desired, Soffid ESSO will be able to enforce this control. Whenever a user logs in, Soffid will check for existing SSO sessions. If there is any other active session, the existing session will be noticed of this fact, but will let the new session to close the existing one and go ahead.
With this check point, the security administrator will be confident the passwords are not shared as long as it is useless.
Nevertheless this control cannot be applied for everyone. There are some people that need to use more than one desktop at a time. For this four handed guys, the Soffid IAM console can enable them to have a multi session profile.Conversely, single sign-off is the property 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.
