Single Sign-On and zero trust networks depend on securely passing identification details back and forth between users, identity providers, and service providers. SAML is the glue that lets that happen.
Trust No One
Like George Smiley in John Le Carré’s Tinker, Tailor, Soldier, Spy, you should trust no one and suspect everyone. Just because someone is authenticated, and inside your network perimeter, it doesn’t definitely mean they are who they purport to be. Nor that they should be trusted.
The emerging model of security isn’t about strongly guarded multi-layered perimeter defenses. Identity is the new perimeter.
Zero trust networks force authentication repeatedly as a user moves through the network, accesses applications, and reaches out to cloud-based services. Of course, no one wants to have to re-authenticate time and time again. Automation is the obvious answer. Once a user has been positively identified and it is established that they are who they say they are—and not, for example, someone using the genuine users’ credentials from an IP address the real user has never used—passing their credentials automatically makes sense.
To do that securely a standard is required to request the credentials, to predictably pass the credentials, and to receive and verify or reject them. The Security Assertion Markup Language is an XML-based standard developed Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards. At the time of writing, the current version is SAML 2.0.
This is how it is used to pass security information between online subscribers to the SAML model.
RELATED: Can You Trust Zero Trust?
What SAML Is
SSO is an authentication service that enables painless logging in with a single identity to multiple systems. With SSO, users are freed from having to manually enter credentials every time they want to access an asset or resource.
Users are authenticated and validated by a central server when they attempt to log in. Authentication is fulfilled using a mix of user information, credentials, certificates, and multi-factor authentication tokens.
SSO is often leveraged by zero trust networks to satisfy their need for continuous authorization and authentication. SSO needed a solution to allow users to reach cloud-based services located outside the corporate network and beyond the reach of zero trust. A standard for the federation of security credentials was needed.
SAML quickly gained traction and found favor with cloud-based service providers. Heavy hitters such as Google, Microsoft, IBM, Red Hat, and Oracle advised on, adopted, and championed SAML.
Using SAML, an organization can send security information such as identities and access privileges to a service provider in a secure, standardized way.
SAML Communication Scenarios
There are three main entities in a SAML communication.
The end-user. This is the person who wants to use the remote resource, asset, or cloud-based service. An identity provider, or idP. The idP provides online resources to give authentication to end-users over the network. A service provider must trust the idP. Users who have been identified and authenticated by the idP are trusted by the service provider, who provides the end-user with access to the service.
When an end-user logs in to their corporate account and uses any of their shortcuts or dashboard links to access remote resources, they are authenticated against the idP. The idP sends a SAML message to the service provider. This initiates a SAML conversation between the idP and the service provider. If the idP verifies the end-user’s identity, the service provider accepts the end-user as bona fide and grants them access to their services.
If the end-user hasn’t been authenticated by the idP before they make a request to the service provider, the service provider redirects them to the idP so that they can log in and establish their identity. The idP then communicates with the service provider to authenticate the end-user, and redirects the end-user to the service provider.
The identity providers are the middlemen in the entire process. Without them, the system won’t work. There are organizations servicing that requirement, delivering identity provider services that businesses can partner with to make use of their SAML services. Other organizations will guide you through becoming your own identity provider.
SAML Assertions
A SAML Assertion is the XML document sent by the idP to the service provider. There are three different types of SAML Assertions — authentication, attribute, and authorization decision.
Authentication assertions verify the identification of the user. They provide some related metadata too, such as the time they logged in and what factors were used to log in and establish the authentication. Attribution assertions are used to transfer the specific pieces of data that provide information about the user to the service provider. These pieces of information are known as SAML attributes. Authorization decision assertions contain the ipD’s decision on whether the user is authorized or unauthorized to use the service. This is subtly different from authentication assertions. Authentication assertions say the idP knows who the individual is. Authorization decision assertions say whether that individual has the necessary privileges to access the requested service or asset.
What about OAuth and WS-FED?
SAML is most often used by businesses to securely and—at least, from a user’s point of view—simply gain access to external services the business pays for. Service providers like Salesforce, Go Daddy, Dropbox, Nokia, and many government and civil departments use SAML.
OAuth, or open authorization, is an open-standard authorization protocol mostly used by consumer apps and services. Rather than have to create an identity when you’re creating an account, an OAuth-enabled platform may let you “sign in with Google”, or Facebook, or Twitter. Effectively you’re using Twitter or Facebook or whomever as the identity provider. It lets you use an organization that’s trusted by the platform you’re creating the account on to vouch for your identity. It does this in a way that doesn’t require your Google, Twitter, or Facebook password to be shared. If the new platform suffers a data breach, your credentials are not exposed.
Web Services Federation does the same job as SAML. It federates authentication and authorization from service providers to a common, trusted identity provider. It has less penetration than SAML, even though it is supported by identity providers such as Microsoft’s Active Directory Federation Services, but it hasn’t made significant headway with cloud providers.
Halt, Who Goes There?
SAML facilitates single sign-on with one federated identity, which is leveraged by zero trust networks.
It’s like a private being able to say to the sentry, “The Colonel will be along to vouch for me in a moment.”
