Introduction to SAML - Chalktalk on what is it, how it is used

hi I'm Corey Williams from Centrify I'm joined today by Paul Moore who is a CTO and co-founder of Centrify and we're here today to discuss a little about sam'l what it is how it can be used and why you should care so as I talk to customers and as we interact with a lot of people they've heard of the term sam'l 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 this for us today it's going up to the board and sort of lay the overall framework of what Sam I was trying to do okay okay so sam'l covers a lot of use cases what I'm going to talk about is the use case that seems to be coming into use now which is where we've got a multi-talented sass service and we want to be able to use that there are cases that came up before sass things existed but is the sass 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 some cloud service over here which let's say it's some online CRM system which provides multi-tenant 'add services to you know the businesses who use by multi-tenant that I mean all sorts of companies use the services of that and it feels to them like they own a slice of that so this could be Salesforce NetSuite Coker Web Apps those kind of services yeah so and what we have over here so this is this is Salesforce let's say and over here we have a customer I'm drawing a very high level here that just doesn't represent anything technical so we have customer one here and they have a user population that who want to access the services of this Salesforce the classic way that would be done in the pre sam'l days would be that the CRM system would have a big database of users and passwords and other information about users you know maybe their rights and so on but let's just focus on users and passwords and then when somebody from customer one tries to sign in so here's his customer one user he signs in and when I connect to here this system would look in the user password database to see a my abuser which tenant do I belong to within within Salesforce and whether I should be allowed in or not it's a standard where you would do things and 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 up into pieces but the the authentication mechanism is just like it was an on-premise system so when the user logs in his user password is sent to the 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 so 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 is he's our administrator here and here's the end user if 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 no visibility directly into this thing and maybe they could go and do it by hand to this one thing but imagine that really c1 is using multiple SAS services having to keep track of which ones this user can use very quickly adds up to quite a complicated problem so that's so it becomes sort of 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 right him and he really wants just have one switch to say this person no longer works here I mean and 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 is an integrator with the systems over here it doesn't work it doesn't flow very well there's no way of doing that this person's view of the world is now well I've got a different user ID and password I have to remember here right and again I've only got one but again more and more companies are using different SAS applications maybe this person's using five six seven eight different SAS applications maybe they have the same user ID maybe they don't they look it's easy to lose track of what you've got so they're inconvenienced by it and then over here I'm going to draw a one person what this person's view of the problems are I mean of course it I mean 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 right if you follow the press's all sorts of things you know another ten thousand usernames and passwords will leak somehow they'd rather not have to manage all the infrastructure of doing that and then also dealing with all the complaints that so for example these people keep forgetting their users in passwords so now we have to run user password reset capabilities here this is 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 have to worry about the security aspects of it so although it works none of the players in the game are actually happy with with their results so this is what sam'l is trying to solve and in fact successfully solves so let me show you a revised flow now of how that would work so 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 so I have over here ad and this is of course managed by my administrator and the 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 so what happens now is when this user wants to log on what they do is they connect here first and 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 all the it knows that this user wants to connect to Salesforce in our example and so what this system does is it issues a token to the user which describes the user main thing it says is this is user one and this is then sent to the set Salesforce that this token is sent over here now this system 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 like the password for the user to get it in no no so yep as I said the primary thing is it says in a trust of a way come back to how it's trusted that this this system asserts that this user really is Jane at Acme widgets com and then this information flows up here and this system knows for sure that that is Jane at Acme widgets com and now this system allows Jane to do whatever she needs to do within that system without having to know about as user and password and readers point out the password doesn't flow up there there's no password database over here so now everybody is much happier because the administrator can simply disable a user in Active Directory and now the identity provider will no longer issue these tokens on behalf of users that are no longer employees James life is simplified because she just has to log in once to this system with the same user and password as you would use to get to Active Directory which is the one she uses for in-house resources as well and the people at the Salesforce side of things no longer have to worry about maintaining potentially a couple databases of users and passwords so the the another interesting thing while we're just looking at the sam'l token we definitely have in here the user so 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 we could job grade any sort of information that might be useful and meaningful to the target application so for example you might get different permissions inside here depending whether you which department you work for so 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 and this so this token can contain more than just your identity it contain information about you and the the identity provider is configured in such a way that it knows for each application that you're going to talk to which pieces of information need to be sent to to the final application now one of the things that I've noticed is is that you've changed the the normal place that a user logs into by having them go to the IDP first is that the only way to do it how does that how does that affect the end user excellent excellent question so yeah and this one I've drawn again just to kind of get our feet wet is where the user has explicitly come to the identity provider a very common mechanism and maybe even the more common mechanism is where the user goes directly to the application let's the most common case clearly there is somebody sends them a piece of email they click on it or maybe they have a some bookmarks they click on those which have the URL of this this this destination 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 sam'l token explicitly or some other token cookies or whatever that this service may have used I don't know who this is but it can tell who who the users come from so it knows that this is a custom this is a user of custom this customer and so it might know that because it's Acme CRM com yes as opposed to just going to WWE CRM does not this is the or might ask it not there's it's a classic problem of sam'l called realm discovery ok how do I know a user I don't know arrives at me and I have to send them back to their home right and so I've got this chicken and egg problem I need to find out who they are but if I know who they are 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 so a very common situation just to expand on what you just say is that in a multi-talented system you might have you know CRM calm but that might be set up actually as Acme CRM calm for the cuts for the tenant called Acme and in that case with the user arrives at that URL and they don't know if 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 I've seen all yeah it's very smoothly up but so somehow by hook or by crook this system works out where where where your home is and 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 the user and password or maybe the IDP has already got you logged on via cookies and things it's remembered who you are but importantly at this moment it can still verify you're still a valid user and then it issues a token and you'll then be redirected back here with your with your same sam'l token so 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 click click click 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 and then they'll be smoothly routed back to this one so just what let's throwing in some terminology this is what's called sp-initiated so the SP is the service provider so this is the application or resource of the thing providing the service right so this is called SP initiated because the 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 sam'l token and then sent you off over there and some some sam'l applications only support IDP initiated don't support SB initiated it's a little more complicated as we saw because of the realm discovery problems it's 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 come across which they support sp-initiated but not IDP initiated now once the user has authenticated through either of these mechanisms or processes from that point forward the they do they have to go through this again or do they get to you know continue to access that resource how often does do they have to go through this redirection so there's two aspects that so one of the things we there's a kind of little 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 to service 3 service for other services I know this wasn't exactly what you're asking but I think it's interesting point is that this user now when we first went here for 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 IEP - unless the IDP wants to get very fussy but in there's no there's no requirement so once I'm authenticated once to my DP I can go to all of the services I need to use without having to authenticate again however then is the inverse problem which is eventually we do want to make sure that the user is still an employee we don't want okay you're authenticated once three years later I'm still using the same access right that kind of blows away the original problem we had here which was this person wants to be in control so what happens there is when in the sam'l 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 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 by 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 a couple of times but the the experiences is usually seamless for those of you that know Kerberos that Kerberos has a similar idea which is Kerberos tokens which renew a renewable but also have expiry times on them so you can keep on renewing them people go if so if I can keep on renewing them as 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 in identity store every now and then 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 you know flowed backwards and forwards and that brings us to the topic of you know I'm sure people are seeing these things talk about active profiles and passive profiles and things like that and and how does some of that magic work and you know what does it mean and what are the use cases and so on so I just wanted to get rid of a lot of those those arrows and so on and start again so we'll come back to our that's that's just let's call it Salesforce and so the first use case we had was we had a web browser with a user wanting to access it and we had a complicated flow going on do you know the user wanted to connect but then this then redirected somewhere else so we had the IDP over here so the user connected over there and then I got redirected to here then this thing redirected me backing in that whole flow between these three players and sometimes even more players is called the passive profile this is using a sam'l speak let me just step back look sam'l covers two things so the first thing that sam'l 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 sam'l 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 sam'l specification describes just the contents that doesn't describe how it gets from here to here or from here to here and so on the second major section of it is how it gets transported and that explains since all these parties have to cooperate in flowing these messages around how the if this is going to redirect you over here how that redirect should look like because this person has to know what that reader is 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 sam'l protocol sam'l specification but the two key parts the payload format in the transport format and in fact it's interesting there are some places where the payload is used but complete different set of transport to use for example you might be using ws-trust which is a different set of protocol specifications but still carrying sam'l sam'l tokens around more commonly you see now sam'l being used for both so the one that you see almost all the time is what's called the passive profile a 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 right and then so 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 and so on there's a kind of bouncing backwards and forwards and this is really very classically passive player in that in that process and really you know 95 percent of the real deployments in the real world are the passive profile 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 let's B we have an iPad doesn't necessarily have to be an iPad but you know a mobile device or some some mobile device there will look roughly like this nowadays and on here I actually have rather than a passive web browser and really know what's 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 so a rich mobile app like instead of the browser on yes yeah so it's so in 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 you know REST API types or whatever they might be this is so this is a this is an active piece of code specifically written to work in here it still got the same problem though it still needs to authenticate which there's still a user using this application which has to be authenticated and there's an there's a width in sam'l there's what's called the active profile and the active profile is all about how this application would go about asking the so what they 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 now this is a very rapidly evolving space so sam'l active profile definitely works here there's still a few holes in that this for execut anning of a 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 at an HTTP header should I make it look like a cookie that's different and there's no universal agreement about how a sam'l 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 in my name the most important one is one called OAuth an OAuth again is designed to address this problem of a rich client wanting to call the app the application interfaces of another one originally OAuth was much more consumer focused sam'l very enterprise focus 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 spelt like jot is how you is you how you pronounce it again trying to fill the same space as as sam'l is trying to fill but for example just since we're Centrify Centrify has a toolkit which fits exactly into this a lot here to enable you to get tokens and then to send them over here and we've kind of gone with one of the non formally 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 sam'l tokens via API calls they can they can send it however they like so those are the most common use cases you see out there and this but this is by far the most common 95% fighters whether it's the passive profile the active profile in both cases were dependent on the service provider to actually support using these tokens and so forth is there anything we do to help the ISVs make that easier you mentioned something about the SDK on the mobile side do we offer that same type of help on the on the silver side so on so first of all to answer the basic question which is this this player has to know that they're in a sample space they 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 in area 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 SAS application sales force will take already has done that but there's a lot of applications in it you know that haven't done that yet plus as an aside although we've been talking about SAS applications if I have my own in-house applications you know my own HRC system you know my own CRM system there's no reason why I can't use this same infrastructure to talk to my own in-house applications and there definitely there's an opportunity to add sam'l 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're Centrify we have various SDKs all to support various languages which you can slot into here to help you support different different sam'l types in different languages of your Java or Ruby or PHP or whatever I mean there are a lot of libraries out there already it's really not the things we supply and not you know anything proprietary they're just helping you get get going and receive the value of sam'l 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 okay so let me just start with my my two players again which is over here we have c1 and then we have their IDP so what we want to do is remember that we won't discuss the exact flow of the tokens the net effect was this system in in consultation with an identity system in here produces a sam'l token which I would true 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 this one here so what we what is what happens is the IDP owns has a cert plus the private key that goes with the cert this is x.509 just to make sure we and somehow out-of-band 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 just the certificate so typically what will happen is let's say the administrators here will download the cert from some webpage here go over here into an upload or maybe this some programmatic way it can be done it again it varies from from provider to provider you get the exact nature the end effect is the same there's the configuration of that plus some additional configuration about the cut that their customers see one remember he needs to redirect users back over here so it needs to know the URLs to redirect back to and so on but the for the trust purposes the key one is this 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 sign sort of signed sam'l token saying signed using this certificate I'd love to go into how digital signatures work but that's kind of little out a script but 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 belong that uses this cert the belongs to this that goes with this cert that so I know that only the person who has this piece of information could have done it the first thing second thing is an I know it can't have been tampered with that the content because the contents are signed it it also as attests to the fact that it's the contents are the same as when it left here is when it arrived so the only place we could have come from is C ones I IDP right yes of course the thing is predicated on you keeping that private key private sure you know if this escapes then who knows what will happen but but I mean people is well known within the certificate space that you have to keep your private keys private they call private so it's the nice thing is it's leveraging existing technology you know the well you know digital certificates this digital signing using certificates and so on so it's actually a pretty robust and well understood mechanism out that's one of the reasons why sam'l is relatively easy to implement because they didn't have to reinvent a lot of trust technologies right thank you Paul well we hope that this has been a helpful video in learning about the basics of sam'l and how its implemented within the SAS application space for more information and additional videos that talk about how Centrify implement sam'l for all your SAS applications and more please visit www.mptv.org/outdoorwisconsin

Channel: Centrify

Views: 368,126

Rating: 4.844172 out of 5

Keywords: SSO, SAML, Single Sign-On, Centrify User Suite, realm discovery, Security Assertion Markup Language, Security (Taxonomy Subject), cloud identity, Computer Security (Industry), cloud security, user authentication, paul moore, SaaS, Software As A Service (Industry)

Id: S9BpeOmuEz4

Length: 32min 2sec (1922 seconds)

Published: Mon Dec 30 2013