By Rajat Bhargava Posted July 19, 2016
Often, SAML is the protocol of choice to authenticate users into web applications. The open standard was created in the early 2000s. It became more widely adopted as new web applications appeared later in the decade.
While the specification is quite complex at a high level, we can simplify it into two parts. There are service providers (generally web applications) and identity providers (the identity authority). The two components securely communicate to determine whether access should be granted to an individual.
Untangling The Connection To Web Apps
A new problem started to appear during the early 2000s.
Applications that organizations were using started to shift from the internal network to the web. IT organizations didn’t know how to connect their internal user databases or directory services to applications that were hosted outside of the firewall and on the web. The term “cloud” wasn’t in wide use at this point!
So, a new thought process emerged: how can IT securely federate identities to applications hosted on the Internet with on-premises identity providers? The SAML specification was one approach addressing that very question. At the time, the most common directory services were the commercial Microsoft Active Directory solution and the open source OpenLDAP.
Internal And External Dialogue
SAML solutions securely expose internal directory information to external applications (typically SaaS websites). A typical workflow involves an end user logging into a web portal with directory-based credentials and initiating single sign-on to an external application. The portal then dispatches a secure message representing the user’s identity, such as an email address or username, which the external application verifies. The end user is seamlessly logged into the targeted application without having to provide a password.
Because the environment in which SAML was originally created included a separate directory server on-premises, the model required integration with the directory. The original SAML single sign-on solutions were on-prem solutions that sat next to the directory server. Over time, many SAML SSO solutions moved to the cloud. In a sense, they were now closer to the web applications that they supported. Meanwhile, the identity provider continued to remain on-premises, behind the firewall.
Redefining SAML Identity Providers
Recently, a new generation of SAML identity providers has emerged that are cloud based and virtual. Often called Directory-as-a-Service platforms or Identity-as-a-Service, these SaaS-based directory services are leading the way to create an integrated, True Single Sign-On™ experience for end users.
A single set of credentials now works for a user’s devices, on-prem and cloud applications, and access to the WiFi network.
The benefit for IT organizations is huge. They no longer need separate directory services and SAML solutions. They are integrated into one solution and include other protocol support such as LDAP and RADIUS. The Directory-as-a-Service platform becomes the core authentication, authorization, and management platform for user management.
If you would like to learn more about how your SAML identity provider can become your broad-based, cloud-based directory services solution, drop us a note. We’d be happy to walk you through how SAML works. Or, feel free to give JumpCloud’s Directory-as-a-Service a try for yourself. Your first 10 users are free forever.