SSO is an organization access control solution that allows users to authenticate once (typically once per session) and get access to all enterprise resources connected to the SSO system, the solution provides federated access to multiple independent software with one set of credentials . Typically to achieve this magic, multiple techniques are used behind the scenes, depending on what methods each resource supports.
Type of Single Sign On Configurations:
Kerberos Authentication
- Initial sign-on prompts the user for credentials, and gets a Kerberos ticket-granting ticket (TGT).
- Additional software applications requiring authentication, such as email clients, wikis, and revision-control systems, use the ticket-granting ticket to acquire service tickets, proving the user’s identity to the mailserver / wiki server / etc. without prompting the user to re-enter credentials.
Kerberos is a client-server authentication protocol that allows mutual authentication – both the user and the server verify each other’s identity – over non-secure network connections.
The Kerberos protocol uses a symmetric key derived from the user password to securely exchange a session key for the client and server to use. A server component is known as a Ticket Granting Service (TGS) then issues a security token (AKA Ticket-Granting-Ticket TGT) that can be later used by the client to gain access to different services provided by a Service Server.
Learn More About Single Sign-On (SSO)
Smart-card-based Authentication
A smart card is a secure microcontroller that is typically used for generating, storing and operating on cryptographic keys. Smart card authentication provides users with smart card devices for the purpose of authentication. Users connect their smart card to a host computer. Software on the host computer interacts with the keys material and other secrets stored on the smart card to authenticate the user.
In order for the smart card to operate, a user needs to unlock it with a user-PIN.
Smart cards are considered a very strong form of authentication because cryptographic keys and other secrets stored on the card are very well protected both physically and logically, and are therefore extremely hard to steal.
The added security provided by the smart card comes at the expense of the user experience, as smart cards need to be physically carried around by the user and inserted into the host computer every time they want to authenticate with it. Users are also limited to host devices that have the card interface software installed.
Smart cards are also expensive to administrate, as they require software installation on the host computer and physical distribution to the users.
Integrated Windows Authentication (IWA)
Integrated Windows Authentication uses the security features of Windows clients and servers. Unlike Basic or Digest authentication, initially, it does not prompt users for credentials. The current Windows user information on the client computer is supplied by the web browser through a certificate exchange involving hashing with the Web server. If the authentication exchange initially fails to identify the user, the web browser will request the user for credentials.
Integrated Windows Authentication itself is not a standard or an authentication protocol. When IWA is selected as an option of a program implies underlying security mechanisms should be used in a preferential order. If the Kerberos provider is functional and a Kerberos ticket can be obtained for the target, and any associated settings permit Kerberos authentication to occur (e.g. Intranet sites settings in Internet Explorer), the Kerberos 5 protocol will be attempted. Otherwise NTLMSSP authentication is attempted. Similarly, if Kerberos authentication is attempted, yet it fails, then NTLMSSP is attempted. IWA uses SPNEGO to allow initiators and acceptors to negotiate either Kerberos or NTLMSSP. Third party utilities have extended the Integrated Windows Authentication paradigm to UNIX, Linux and Mac systems.
Security Assertion Markup Language (SAML)
Security Assertion Markup Language Security Assertion Markup Language (SAML) is a standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password: No need to type in credentials No need to remember and renew passwords No weak passwords Most organizations already know the identity of users because they are logged in to their Active Directory domain or intranet.
It makes sense to use this information to log users in to other applications, such as web-based applications, and one of the more elegant ways of doing this is by using SAML. SAML is very powerful and flexible, but the specification can be quite a handful. OneLogin’s open-source SAML toolkits can help you integrate SAML in hours, instead of months. We’ve come up with a simple setup that will work for most applications. Security Assertion Markup Language (SAML) is an open standard that defines a XML-based framework for exchanging authentication and authorization information between an identity provider (IdP) and a service provider (SP), to enable web-based single sign-on (SSO) and identity federation.
Security information is expressed in the form of portable SAML assertions that applications working across security domain boundaries can trust.
In a typical scenario, a user requesting access to a service provider is redirected to an identity provider capable of authenticating the user and providing a SAML assertion that allows the service provider to make its access control decisions. The SP and IdP must have a trust relationship established prior to exchanging SAML assertions.
