Single Sign On (SSO) Use Cases
SSO reduces password fatigue for users having to remember a password for each application. With SSO, a user logs into one application and then is able to sign into other applications automatically, regardless of the domain the user is in in or the technology in use. SSO makes use of a federation services or login page that orchestrates the user credentials between multiple applications.
Before we look at some of the use cases let us get some familiarity with common authentication schemes:
Basic and Digest Authentication
Basic and Digest authentication were some of the earliest authentication schemes used on the web between clients and servers. In basic authentication, when a client made a request for a resource, the server would send an HTTP error code 401, indicating that the client was unauthorized. The server would indicate what header was acceptable, basic or digest, in the WWW-Authenticate header. The client then fills the Authorization header and sends a new request to the server, formatting the password using base-64 or an MD5 hash depending on basic or digest authentication. The communication is simple but insecure and easy to manipulate.
Form-based Authentication (FBA)
From personal experience, you probably already know that this is the most commonly used mechanism to get users to authenticate prior to gaining access to an application. When logging into an application, you’re presented with a form to enter your user name and password. This form is then transmitted to the server using the internet protocols. Of course, not only can this form be intercepted and compromised, but also may be used to send malicious information to the server. There are a whole class of security devices (Web Application Firewalls) and code checkers to secure against compromise.
[You might also like: Single Sign-On (SSO) for Cloud and On Premise Apps]
NTLM
Still in use in legacy Microsoft environments, NTLM uses a challenge-response mechanism and uses three messages to authenticate a user with the application server. NTLM is less commonly used now due to the possibility of reflection attacks.
Kerberos
Developed by MIT, uses symmetric keys and requires use of a trusted source called Key Distribution Centers (KDC). On Windows, a variant of Kerberos is used as the preferred method of authentication and KDC is integrated with Windows security while Active Directory is used as the user database.
Kerberos Constrained Delegation (KCD)
KCD is used when the client is authenticated by a non Kerberos mechanism and Kerberos is used in the enterprise domain.
Security Assertion Markup Language (SAML)
SAML is an XML- based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, aka an Identity Provider (IdP), and a SAML consumer, named a Service Provider (SP).
[You might also like: Global Server Load Balancing (GSLB) Use Cases]
Now that we have some familiarity with authentication mechanisms, time to review some of the use cases:
Use case: All Applications On-Premise, Authentication On-Premise
In an enterprise, there are many applications and they may use different technologies to authenticate users. Some of the common ones in use are NTLM, SAML, Kerberos and form-based authentication. In order to provide SSO, you would need a central point of authentication, which can provide a single login page, understand a variety of authentication mechanisms both on the client as well as on the application side to act as a bridge between them.
Use case: Cloud or On-Premise Application, Authentication On-Premise, Using Federated Identity
If the enterprise has the identity management infrastructure (IdM) on-premise and enterprise applications are hosted in the cloud or on-premise, federated identity (SAML) may be used. In such a scenario, on an access attempt to an application, the user is redirected, by the Service Provider (SP), to the identity provider (IdP) on premise. On authentication, the user carries the identity assertion to the SP. In this usage scenario, the SP is the SAML consumer and the IdP is the SAML provider.
Use case: Cloud or On-Premise Application, Authentication in the Cloud, Using Federated Identity
If the enterprise uses a 3rd party infrastructure in the cloud as the identity management infrastructure (IdM) and enterprise applications are hosted in the cloud or on-premise, federated identity (SAML) is the preferred way for authentication. In such a scenario, on an access attempt to an application, the user is redirected, to the identity provider (IdP) in the cloud. The identity provider typically operates as a business service – Identity As A Service (IDaaS). On successful authentication with IDaaS, the user carries the identity assertion to the SP. In this usage scenario, the SP is the SAML consumer and the IDaaS is the IdP and SAML provider.
Conclusion
SSO is great for convenience and improves productivity while adding a single point of control over identity across multiple applications. You may also want to enhance the convenience of SSO with multi-factor authentication (MFA) to add a layer of security to application access, making it more difficult to hack. We will discuss MFA in a future blog.
For more details:
Agile Security: What Does It Look Like
The Technology Behind Radware’s Web Application Security Solutions
