SAML Authentication: Single Sign-On (SSO) for Cloud Apps

What is SAML?

SAML (security assertion markup language) is an XML-based standard for web browser single sign-on (SSO) that eliminates application-specific passwords. SAML uses single-use, expiring, digital "tokens" to exchange authentication and authorization data between an identity provider and cloud application service provider that have an established trust relationship.

How SAML Works

SAML for Web browser SSO involves three parties. There is a user, an identity provider (IdP), and a cloud application service provider (SP). The IdP stores information about the user in a database like Active Directory. The user connects to the SP and attempts to authenticate. If the SP recognizes the username, it delegates authentication to the IdP. The IdP validates the user against its identity database. It then sends a SAML assertion about that user to the service provider. The SP then gives the user access to the application.

SAML, SAML Authentication, SAML SSO, SAML Single Sign On

Benefits of SAML

SAML exchanges security and identity related information such as authorization and authentication, using signed digital certificates and Public Key Infrastructure (PKI) to ensure the integrity of data. SAML eliminates the possibility of passwords theft/reuse, thereby increasing security. And because it’s based on an open standard, SAML is interoperable with many different cloud application service providers.

SAML Integration with Centrify

As organizations adopt cloud-based apps, they need to tighten security and maintain compliance. They need centralized identity management. Centrify Identity Service provides SAML integration for cloud app single sign-on. SAML eliminates the need to enter a different username and password for each application. SAML SSO uses existing identity infrastructure — Active Directory, LDAP, the Centrify Cloud Directory, or external users.

Active Directory SAML, SAML SSO Solutions by Centrify
It can also enable SSO from federated business partners. Because administrators don't need to create a new directory infrastructure, they can begin provisioning users in minutes.

Centrify provides a generic SAML template to connect to custom SAML apps. Centrify also provides preconfigured SAML connectors for popular applications including Salesforce, Workday, Concur, AWS, Google Apps, Zendesk and Dropbox, and hundreds of others. Centrify also supports other protocols like WS-Federation for apps like Office 365.

Benefits of Centrify's SAML Integration

  • Provide SSO using authentication with Active Directory, LDAP, the Centrify Cloud Directory, or external users
  • Secure your applications through deep integration with One Time Password Multi-factor authentication
  • Simplify IT management with a single application interface and user directory
  • Increase employee productivity with a single portal to access all their applications using existing credentials
  • Reduce password loss and minimize IT help desk password resets
  • Automatically provision and de-provision users and apps by Active Directory group
  • Increase application ROI with automated license provisioning and de-provisioning

SAML Walkthrough Video


Introduction to SAML

Corey Williams: Hi, I'm Corey Williams from Centrify. I'm joined today by Paul Moore, who is CTO and co-founder of Centrify. We're here today to discuss a little bit about SAML. What it is, how it can be used, and why you should care. As I talk to customers, and as we interact with a lot of people, they've heard of the term SAML, but they don't know quite what it means. What the single sign on process looks like, why it might be important to them. Is that something you can help explain for us today?
Paul Moore: I'm just gonna go up to the board and lay the overall framework of what SAML is trying to do.
Corey Williams: Okay.
Paul Moore: So SAML covers a lot of use cases. What I'm gonna talk about is the use case that seems to be coming into use now, which is where we've got a multi-tenanted SaaS service, and we wanna be able to use that. There are cases that came up before SaaS things existed, but the SaaS one is a very clearly understandable case, and is the main use case you see today. So I'm going to imagine that we have some cloud service over here, which. let's say it's some online CRM system, which provides multi-tenanted services to businesses who use it. By multi-tenanted, I mean, all sorts of companies use the services of that, and it feels to them like they own a slice of that.
Corey Williams: So this could be SalesForce, NetSuite, Concur, Webex.
Paul Moore: Those kind of services, yeah. This is SalesForce let's say, and over here we have a customer. I'm drawing a very high level here, that doesn't represent anything technical. We have customer one here, and they have a user population who want to access the services of this SalesForce. The classic way that would be done in the pre-SAML days, would be that the CRM system would have a big database of users and passwords, and other information about users. Maybe their rights and so on, but let's just focus on users and passwords. Then when somebody from customer one tries to sign in ... So here's customer one user, he signs in. And when I connect to here, this system would look in the user password database to see am I a user? Which tenant do I belong to within SalesForce? And whether I should be allowed in or not. Standard way you would do things.
Paul Moore: In fact, it doesn't differ that much from how an on-premise system would work. There's the additional complexity of the fact that this system has to divide itself into pieces, but the authentication mechanism is just like it was an on-premise system. When the user logs in, his user password is sent to this application, and the application verifies it against its own user password database. There are a few problems with this. Each player in this game has their own set of problems they need to deal with.
Paul Moore: If we just look first of all at the administrator. This is the customer site here. We look at the administrator of this customer. His problem is that if this user ... Let me just draw, here's our administrator here, and here's the end user. If this user leaves the company, C1, we no longer want them to have access to this data, to whatever data it is inside here. The problem is that this person here, this administrator, has no control over, or maybe even no visibility directly into this thing. Maybe they could go and do it by hand to this one thing, but imagine that really C1 is using multiple SaaS services. Having to keep track of which ones this user can use very quickly adds up to quite a complicated problem.
Corey Williams: So it becomes a fire drill for the IT administrators to find out all of the services he has access to, and then go and figure out how to get them out of those systems.
Paul Moore: Right, I mean he really wants just to have one switch to say, "This person no longer works here." There's also more subtle ones, which is let's say this person changes job role. You might need to change some permissions or something about them over here. And again, because this isn't integrated with the systems over here, it doesn't flow very well, there's no way of doing that.
Paul Moore: This person's view of the world is now, "Well I've got a different user ID and password I have to remember here." Again, I've only got one, but again, more and more, our companies are using different SaaS applications. Maybe this person's using five, six, seven, eight, different SaaS applications. Maybe they have the same user ID, maybe they don't. It's easy to lose track of what you've got. They're inconvenienced by it. Then over here, I'm gonna draw one person. What this person's view of the problems are. The owner, and builder, and engineers creating this service, they have to deal with the fact that now they're maintaining user password database, which in itself is a big security liability. If you follow the press, there's all sorts of things, another 10,000 user names and passwords were leaked somehow.
Paul Moore: They'd rather not have to manage all the infrastructure of doing that, and then also dealing with all the complaints. For example, these people keep forgetting their user and password, so now we have to run user password reset capabilities here. There's just a whole bunch of engineering that they don't want to deal with. These people are focused on being an awesome CRM system, they don't wanna have to worry about the security aspect of it. Although it works, none of the players in the game are actually happy with their result. This is what SAML is trying to solve, and in fact successfully solves.
Paul Moore: Let me show you a revised flow now of how that would work. We presume that this customer, let's suppose they have active directory. Nothing particular about active directory, but as we know, it's a very common directory system. I have over here AD. This is of course, managed by my administrator. Somewhere up here, we have something called an "identity provider." We'll look later on in detail about how that's implemented, where it works, but something which is connected to this system here.
Paul Moore: What happens now, is when this user wants to log on, what they do is they connect here first. This system knows who this user is because they're vouched for by the company's active directory. It knows, and we'll come back to how it knows, that this user wants to connect to SalesForce, in our example. What this system does is, it issues a token to the user, which describes the user. The main thing it says is, "This is user one." This is then sent to the SalesForce. This token is sent over here. Now this system-
Corey Williams: Does that token contain ... I'm assuming it contains information about who the user is so that the CRM system knows, but does it contain the password for the user to get in?
Paul Moore: No, no. As I said, the primary thing is, it says in a trustable way, we'll come back to how it's trusted, that this system asserts that this user really is Then this information flows up here, and this system knows for sure that that is Now this system allows Jane to do whatever she needs to do within that system without having to know about his user and password. Just pointed out, the password doesn't flow up there. There's no password database over here. Now everybody's much happier, because the administrator can simply disable a user in active directory. Now the identity provider will no longer issue these tokens on behalf of users that are no longer employees.
Paul Moore: Jane's life is simplified because she just has to log in once to this system with the same user and password as she would use to get to active directory, which is the one she uses for in-house resources as well. The people at the SalesForce side of things no longer have to worry about maintaining potentially leakable databases of users and passwords.
Paul Moore: Another interesting thing while we're just looking at this SAML token. We definitely have in here the user. We said this is Jane at whatever. We can put other information in there. So we could, for example, say what groups she belongs to, job grade, any sort of information that might be useful and meaningful to the target application.
Paul Moore: For example, you might get different permissions inside here depending which department you work for. If you work for the sales department, you get one set of rights in here, if you work for the marketing department, you get a different set of rights in there. So this token can contain more than just your identity. It can contain information about you. The identity provider is configured in such a way that it knows for each application that you're gonna talk to, which pieces of information need to be sent to the final application.
Corey Williams: One of the things that I've noticed is that you've changed the normal place that a user logs in to, by having them go to the IDP first. Is that the only way to do it? How does that affect the end user?
Paul Moore: Excellent, excellent question. Yeah, in this one I've drawn, again, just kinda get our feet wet, is where the user has explicitly come to the identity provider. A very common mechanism, and maybe even a more common mechanism, is where the user goes directly to the application. The most common case clearly there, is somebody sends them a piece of email, they click on it, or maybe they have some bookmarks and they click on those, which have the URL of this destination.
Paul Moore: Now the user arrives, and what happens, is this service will detect that I don't know who this is. There's no tokens connected in there, either a SAML token explicitly, or some other tokens, cookies, whatever, that this service may have used. I don't know who this is. But it can tell who the user has come from. It knows that this is a user of this customer.
Corey Williams: It might know that because it's, as opposed as just going to; or it might ask them.
Paul Moore: It's a classic problem of SAML called realm discovery. A user I don't know, arrives at me, and I have to send them back to their home. I've got this chicken and egg problem. I need to find out who they are, but to find out who they are I need to send them back to their home. But to find out where to send them back to, I need to know who they are. A very common situation, just to expand on what you just said, is that in a multi-tenanted system, you might have, but that might be set up actually as for the tenant called Acme.
Paul Moore: And in that case, when the user arrives at that URL and they don't know who it is, then they will convert this name here to some destination over here. Or as you pointed out, they might even ask them; or another common one is you ask the user just to enter their name, but don't ask for a password or anything. And simply then based on the name they've entered, redirect them. I've seen all different types.
Corey Williams: Yeah, I've experienced both.
Paul Moore: So somehow, by hook or by crook, this system works out where your home is. So you then get redirected back to here, which will then sign you in again. And again, depending on exactly how these work, you might get silently authenticated, which we can discuss a little further later; or you may be prompted with a user and password; or maybe the IDP's already got you logged on via cookies and things and it's remembered who you are. But importantly, at this moment, it can still verify you as still a valid user. Then it issues a token, and you'll then be redirected back here, with your same SAML token.
Paul Moore: The user experience, in general in that case, is they'll open a URL. They'll see maybe the title bar of the web browser go click, flick, flick, flick as it gets redirect here, redirect back there. If they're already authenticated to the IDP, they won't see any further interaction, they don't have to do anything. If they're not authenticated to the IDP, they might be challenged for a user and password here. Then they'll be smoothly routed back to this one. Throwing in some terminology, this is what's called SP Initiated.
Corey Williams: So the SP is the-
Paul Moore: Service provider.
Corey Williams: So the application or resource
Paul Moore: The thing providing the service. So this is called SP Initiated because the authentication flow is initiated by the user landing here. This one I drew first is called IDP Initiated because the user started out by talking to the IDP. The IDP was the one that decided, "Oh, we need a SAML token," and then sent you off over there. Some SAML applications only support IDP Initiated, don't support SP Initiated. It's a little more complicated as we saw because of the realm discovery problems. This one is very easy to implement. The IDP Initiated is very easy to implement for a service. So, there are none the other way around that I've come across which they support SP Initiated, but not IDP Initiated.
Corey Williams: Now once the user has authenticated through either of these mechanisms or processes, from that point forward, do they have to go through this again, or do they get to continue to access that resource? How often do they have to go through this redirection?
Paul Moore: So there's two aspect. So one of the things ... There's a kind of mini elephant going on here, which of course is ... There are other services over here. So we've talked about service one, so over here, we've also got service two, service three, service four.
Corey Williams: Right.
Paul Moore: Other services, I know this wasn't exactly what you're asking, but I think it's an interesting point. Is that this user now, when we first went here, somehow we ended up being authenticated here. When the user now goes off to this second service, they're not asked to re-authenticate by the IDP, unless the IDP wants to get very fussy. There's no requirement. So once I'm authenticating once to my IDP, I can go to all of the services I need to use without having to authenticate again. However, then there's the inverse problem, which is, eventually, we do want to make sure that the user's still an employee. Okay, you authenticated once. Three years later I'm still using the same access. That kind of blows away the original problem we had here, which was this person wants to be in control.
Paul Moore: So what happens there is, when in the SAML token, there's another thing in here, which is, excuse my confusion of colors here, is the lifetime of the token. So it might say two hours. And what that means then, is when this token is received by this service, it will go, "Okay, this token is valid for two hours." At the end of two hours, it will redirect the user back via this process, back through here. And again, in general, it will silently reissue the tokens just like we did the first SP Initiated one, and simply flow back there and you'll get another two hours. The user might see again his address bar flick, flick, flick a couple of times, but the experience is usually seamless.
Paul Moore: For those of you that know kerberos, kerberos has a similar idea, which is kerberos tokens, which are renewable, but also have expiry times on them. So you can keep on renewing them. People go, "So if I can keep on renewing them for as long as I like, why even bother having an expiry time?" The point about it is, it expires after two hours, but it's still renewable. The system will automatically reissue another one, but it still verifies that you're a valid user. It just makes you come back to the definitive identity store every now and then.
Paul Moore: Okay so what I'm going to do now is wipe this off, and just talk about, in detail, just a little bit of how I drew arrows showing how tokens flow backwards and forwards. That brings us to the topic of ... I'm sure people have seen these things. Talk about active profiles, and passive profiles, and things like that. And how does some of that magic work? What does it mean and what are the use cases and so on? I just wanted to get rid of a lot of those arrows and so on, and start again. So we'll come back to our, let's call it SalesForce.
Paul Moore: So the first use case we had was, we had a web browser with a user wanting to access it. We had a complicated flow going on. The user wanted to connect, but then this had redirected somewhere else, so we had the IDP over here. So the user connected over there, and then I got redirected to here, and then this thing redirected me back again. That whole flow between these three players, and sometimes even more players, is called the passive profile. This is using SAML speak ... Let me just step back a little bit. SAML covers two things.
Paul Moore: So the first thing that SAML talks about is the payload format. So remember I drew a picture of a token and said it contains your user identity, expiration times, various attributes of the user department and so on. So the first thing that SAML describes is the content of that payload. And just as an FYI, that's an XML payload, a whole bunch of ASCII angle brackets. With it's signed in particular ways and so on, so the first part of the SAML specification describes just the contents of that. It doesn't describe how it gets from here to here, or from here to here, and so on.
Paul Moore: The second major section of it is how it gets transported. And that explains, since all these parties have to cooperate and flowing these messages around; how if this is going to redirect you over here, how that redirect should look like. Because this person has to know what that redirect's going to look like. And then when it's finished, how it knows where to redirect the user back to and so on. So there are a lot of other bits of the SAML protocol, SAML specifications, but the two key parts: the payload format and the transport format. In fact, it's interesting, there are some places where the payload is used, but a complete different set of transports are used. For example, you might be using WS-Trust, which is a different set of protocol specifications, but still carrying SAML tokens around. More commonly, you see now SAML being used for both.
Paul Moore: So the one that you see almost all the time is what's called the passive profile. Profile meaning transport works. And the reason it's called passive, is because the player in this game, which is the web browser, is kind of being pushed around by these two parts here. It's not doing anything active at all. It doesn't really understand what's happening, it just says, "Take me to this website." So if this person pushes it that way, then this thing pushes it back the other way. And then sometimes in fact, this one push you even back again and so on. There's a kind of bouncing backwards and forwards. This is really very classically passive player in that process. Really, 95 percent of the real deployments in the real world are the passive profile.
Paul Moore: The other one that is in an interesting state now because of the evolution of mobile computing and things, has really made this very interesting now, is what's called the active profile. And in that case, what we've got is some ... Let's say we have an iPad. It doesn't necessarily have to be an iPad, but a mobile device, some mobile device. They're all roughly like this nowadays. And on here, I actually have rather than a passive web browser, I didn't really know what was going on. I've actually got a piece of code hosted on here that understands that I'm going to communicate directly with this thing. I'm not doing a web browsing thing here, I'm doing some form of API call.
Corey Williams: So a rich mobile app, instead of the browser on mobile device?
Paul Moore: Yes, so if we take the SalesForce case, this could be either a SalesForce or a third party application that's explicitly calling whatever the API structure here is. Rest API types, or whatever they might be. So this is an active piece of code specifically written to work in here. It's still got the same problem though. It still needs to authenticate. There's still a user using this application, which has to be authenticated. Within SAML, there's what's called an active profile, and the active profile is all about how this application would go about asking ... So what has to happen is this guy has to ask to get a token from here, and then send the token off to this one.
Paul Moore: Now, this is a very rapidly evolving space. So SAML active profile definitely works here. There's still a few holes in that, the holes particular are the obtaining of the token by the application from the IDP, is well specified by the active profile. Sending it from here to here, exactly how that should be sent, is not well decided within the industry at all. Should I send it as part of the URL? Should I send it in HTP header? Should I make it look like a cookie? There's no universal agreement about how a SAML token should flow there, but there are other protocols in this space, which I'm not going to discuss in detail, but just to mention them by name. The most important one is one called oAUTH again is designed to address this problem of a rich client wanting to call the applicant into faces of another one.
Paul Moore: Originally oAUTH was much more consumer-focused, SAML very enterprise focused, but there's a kind of enrichment of oAUTH going on. There's still a lot of differences between the two, and there are some other ones coming along. There's one called JWT, which I know is pronounced not like it's spelled like JOT is how you pronounce it. Again, trying to fill the same space as SAML is trying to fill.
Paul Moore: For example, just since we Centrify, Centrify has a tool kit which fits exactly into this slot here to enable you to get tokens and then to send them over here. We've kind of gone with one of the non-formerly standardized ways of presenting tokens over here, but at the same time, we don't force the programmer to send it in a particular way. If this thing is already set up to accept SAML tokens via it's API course, they can send it however they like. So those are the two most common use cases you see out there, but this is by far the most common. 95 percent, five percent.
Corey Williams: Whether it's the passive profile or the active profile, in both cases, we're dependent on the service provider to actually support using these tokens and so forth. Is there anything we do to help the ISV's make that easier? You mentioned something about the STK on the mobile side, do we offer that same type of help on the service side?
Paul Moore: So first of all, to answer the basic question, which is, this player has to know that they're in a SAML space. It's not something that we can impose upon them from outside. They have to build their security infrastructure such that they accept all this, because an area that we haven't discussed yet, which is, how did we establish the trust between the two and so on? They have to do a fair amount of work to do that. A lot of the big SaaS applications, SalesForce we'll take, already has done that, but there's a lot of applications that haven't done that yet.
Paul Moore: Plus as an aside, all that we've been talking about, SaaS applications, if I have my own in-house applications, my own HR system, my own CRM system, there's no reason why I can't use the same infrastructure to talk to my own in-house applications. And there, definitely there's an opportunity to add SAML awareness to those because you get all the additional benefits of not having to maintain your own user database and so on. So certainly we at Centrify, we have various STK's, all to support various languages, which you can slot into here to help you support different SAML types in different languages, which is your Java or Ruby, or PHP, or whatever. There are a lot of libraries out there already. The things we supply are not anything proprietary, they're just helping you get going and receive the value of SAML.
Corey Williams: So the one thing that we haven't discussed is how the identity provider, the IDP, and the service provider, the application, actually know about each other; they know what messages to send to each other, and that they can trust those messages.
Paul Moore: Okay, so let me just start with my two players again, which is over here we have C1, and then we have their IDP. So, what we want to do, if you remember ... We won't discuss the exact flow of the tokens. The net effect was, this system in consultation with an identity system in here, produces a SAML token, which I drew like this. And what we need is, when this token arrives here, that this system can inspect this token and know two things. A, it definitely came from over here. And B, that it hasn't been tampered with since it was issued by this one here.
Paul Moore: So what happens is, the IDP has a cert, plus the private key that goes with the cert. This is X509 just to make sure we ... And somehow out of bound from this communication, and it varies from implementation to implementation on this side. This certificate is installed up here. So somewhere within SalesForce, we have the C1 cert, not the private key, just the certificate. So typically what will happen is, let's say the administrator here will download the cert from some web page here, go over here and do an upload, or maybe there's some programmatic way it can be done. Again, it varies from provider to provider. The exact nature of the end effect is the same. The configuration of that plus some additional configuration about their customer C1. Remember he needs to redirect user back over here, so it needs to know the URL's to redirect back to and so on. For the trust purposes, the key one is this.
Paul Moore: So when the IDP issues this certificate here, it signs it, and I shall do a little sparkle here to say this is a sparkly signed SAML token, saying, "Signed using this certificate." I'd love to go into how digital signatures work, but that's kind of a little out of script. The net effect of that is, this token, A, a receiver of it can tell that it was issued by somebody who has the private key that uses this cert, that goes with this cert. So I know that only the person that has this piece of information could have done it. The first thing.
Paul Moore: The second thing is I know it can't have been tampered with because the content's assigned. It also was attest to the fact that the contents are the same as when it left here as when it arrived.
Corey Williams: So the only place it could have come from is C1's account, IDP?
Paul Moore: Right, of course the thing is predicated on you keeping that private key, private.
Corey Williams: Sure.
Paul Moore: If this escapes, then who knows what will happen, but it's well known within the certificate space that you have to keep your private keys private. That's why they're called private. So the nice thing is, it's leveraging existing technology, digital certificates, digital signing using certificates and so on. So it's actually a pretty robust and well understood mechanism out there. It's one of the reasons why SAML is relatively easy to implement, because they didn't have to reinvent a lot of trust technologies.
Corey Williams: Great, thank you, Paul. Well we hope that this has been a helpful video in learning about the basics of SAML and how it's implemented within the SaaS application space. For more information and additional videos that talk about how Centrify implements SAML for all your SaaS applications and more, please visit Thanks a lot.