Pacific Timesheet is one of many application services that can connect users with SAML 2.0-based single sign-on and identity management services at your organization.
If your organization is already using single sign-on this way, or if you plan to, this article is for you.
What is it?
SAML 2.0 allows user authentication and single sign-on so users can gain easy yet secure access to your enterprise applications, whether they are inside your network or in the cloud. And it's something you're going to be hearing more about in the years to come. This non-technical SAML 2.0 primer will give you the basics for when this comes up at the water cooler or in management meetings.
SAML or Security Assertion Markup Language allows users to authenticate one time to a home network (or in SAML-speak an “Identity Provider”). With that one login the user can gain access to as many applications (“Service Providers”) as they are permitted without having to login again. Simple, sweet and magical, right?
So how does SAML 2.0 do it?
There’s a lot of complicated stuff under the hood of the SAML 2.0 authentication engine, but here’s a simple walk through that should make sense even for you Luddites out there.
How Simple Single Sign-On Works
Step1: User Logs Into Network
This is the initial authentication step for any user. It establishes a session on an organization’s network that allows the user to roam around and do things he’s allowed to do. It also stores some information in the browser that can be used later to authenticate who he is to other services or applications.
Step 2: User Tries to Access Application
A user can access an application by clicking on a browser bookmark, a link on his desktop or even a link from an organization website or application portal.
Step 3: Identity Provider-Service Provider Super-Secret Handshake
Before the user reaches the service, the Identity Provider (Your Network) and Service Provider (An Application) Exchange SAML Messages. This is really amazing. In less than a blink of an eye the Identity Provider and Service Provider do a secret handshake and mysteriously exchange some super-secret information through their palms in a hyper secure way so no onlookers will ever be able to use, copy, sell or publish the handshake in any way ever. This happens somehow in the user’s browser.
Step 4: Deconstructing The Super-Secret Handshake
When the user tries to access the Service Provider’s application (where he would otherwise have to log in) the Service Provider instead transmits an authentication request message to the Identity Provider using the SAML protocol, asking the Identity Provider to authenticate the user’s identity. The Identity Provider responds with its own request for the user’s credentials. If the Service Provider replies with the right credentials the Identity Provider responds back that the user should be allowed in, or logged into the application. This final message includes some certificate proving that this authentication message was indeed sent by the Identity Provider.
In the Identity Management world, there are lots of cross checks and triple checks to make sure every provider is who they say they are. And when they say something to each other, SAML 2.0 has checks to make it is actually the provider talking. Nothing is assumed and everything is verified a bunch of times.
In short, the application asks the knower of all identities, in a very complicated way, “Is this the right guy?” And the knower of all identities responds, “Yup! Let ‘em in!" using some technical gibberish that no intercepter of that message could decifer.
The security standards of SAML 2.0 are generally considered the highest in the land, yet technically accessible to extend and support. This means that the largest number of Identity Management Systems and tools can work with SAML 2.0. So your organization should be using SAML 2.0 or planning to in the next couple of years.
In this case, assume that the Identity Provider is an Active Directory, LDAP or some other identity management mechanism running inside of your organization’s network. Identity Management systems and tools like Ping Identity, Okta, OneLogin, Azure Active Directory and others run outside your network to manage handshakes with applications and services in the cloud.
More Complicated SSO: Federated AuthenticationFederated authentication is an important extension of Single Sign-On. You’ve already probably experienced federated authentication as an online consumer. This is when you sign up for a new service and a website gives you the option to use your Google or Facebook account to login. The first time this probably stopped you in your tracks with thoughts like:
“What does my Google or Facebook login have to do with this company?”, or
“How the hell does this work?”
Federated Identity is a method of using the identity credentials of one trusted provider for a user to gain access to another unrelated application or service. Federated Identity can also connect Identity Management systems with each other.
How does this work?
Single Identity Provider
In Federated Identity, the user's credentials are always stored with a single identity provider. This could be Google, Facebook, Active Directory Federated Services, etc. In this scenario, the user registers, or is registered, with a web service or application at first by using his already established credentials (login and password) from one of these identity providers. So when he comes back two weeks later to log into a web service or application, he’s prompted to enter his identity provider credentials. In turn, the service provider connects with Google or Yahoo as the trusted identity provider and validates the user’s credentials, and then lets him into the service.
Cool beans. The user can use his Google, Yahoo, Facebook, Active Directory or other identity provider credentials to get into all sorts of service accounts to get things done.
Extending the Number of Identity Providers
The trend appears to be giving users more choices in the identity providers they can use, rather than forcing them to use one chosen by the service. We have profiled various other Identity Management and Single Sign-On providers that you might want to learn more about: PingIdentity, Okta, OneLogin, Microsoft Active Directory Federated Services, and Microsoft Azure Active Directory.
Questions? Comments? Suggestions?
If you have any questions, technical or not, let us know in the comments section below. Do you have any plans to extend the use of single sign-on in your organization?
If you'd like do this privately, log a question through our public portal or the private customer portal.
Pacific Timesheet & SAML 2.0
