A Developer's Guide to SAML

hey everyone welcome to a developer's guide to saml my name is nick gam and i'm a senior developer advocate with octa today we are going to spend some time discussing the fundamentals of saml on everything a developer will need to know in order to successfully implement it first let's go ahead and discuss what is saml to define saml it stands for security assertion markup language it's a standard commonly used for single sign-on and we'll get into what that is in a second it's a very widely adopted standard for single sign it was the one of the more original standards and one of the most popular uh for the longest time uh it is prone to certain security uh flaws and and exploits if not implemented correctly so we'll get into you know exactly how to do that momentarily um and and you know it is a little bit less popular day because of those flaws but it's still very relevant and widely used so first let's go ahead and discuss uh what single sign-on is we in order to understand what saml is we first need to really understand what saml does um so we're gonna go ahead and hop onto the whiteboard and and just start laying out um a diagram for single sign-on and as we go through this talk i'm gonna keep adding to this diagram uh in order to you know discuss you know where saml fits in the overall concept so what is single sign-on let's say we have a user here let's say this user needs to access multiple applications that exist in the cloud draw my little clouds so this user could attempt to access these applications individually manually but there are some real inherent security flaws here not to mention the convenience factor this user has to memorize and log into multiple different accounts there's multiple different profiles involved it really is not the best solution so one way of improving on this would be to add a centralized point of identity a centralized authentication point and what this does is this allows that source of truth that centralized point of authentication to handle all of the authentication to individual apps so that the user doesn't have to at this point the user simply authenticates directly to that centralized point of authentication that is single sign-on the user signs on once one time to this centralized authentication point and then they are given access to all of the applications that they should have access to and they don't have to memorize and remember different uh credentials different profiles they don't have to manage anything that centralized identity solution does the work for them okay great well that's single sign-on but how does saml work well before we get back to the whiteboard let's step through some of the most important saml terms that we'll need to understand first an identity provider is that centralized point of authentication that source of truth that identity store that we discussed within single sign-on the service provider is the application that the user is trying to sign into when the service provider sends a communication to the identity provider this is called a saml request when the identity provider responds back or sends a communication to the service provider this is called a sample response within the saml response there is going to be multiple statements about the user these statements that are asserted are called assertions these assertions are all signed using the xml signatures also known as dsig and they are sent the sample response is sent to be processed at the service provider to a specific endpoint called an assertion consumer service so the assertion consumer service is really responsible for receiving the saml response from the identity provider checking the assertions signatures and validating the entire document it's the most important part when implementing saml in the service provider perspective within the saml response there's going to be other pieces of information about the user uh such as their first name their last name whatever profile information that we might want to send along about the user's identity these identity pieces of information are called attributes a couple of other concepts within saml that you know are really important to know would be things like the relay state so the relay state is a way for the identity provider to remember where a user was before authentication so if the user is browsing anonymously through the service provider and they decide to trigger something that requires authentication they will be redirected to the identity provider at that point the identity provider is going to validate the user's identity and redirect them back to the service provider's assertion consumer service it would be very inconvenient at that point if the user were to then be dropped onto a home page again and have to re-navigate to where they're originally browsing so the relay state allows the service provider to send along in that saml request where the user was before they triggered authentication the identity provider preserves that relay state and then sends it back to the service provider the assertion consumer service then can determine where that user needs to go after authentication has been completed uh a sample trust really is the configuration between the identity provider and the service provider there are certain pieces of information that are shared such as a signing certificate as well as an entity id also known as an issuer typically comes from the identity provider different information uh is is shared between the two parties so that they can have a trust that allows them to validate uh the communications the requests and the responses going back and forth and we'll discuss that uh more of some of what those verifications are going forward here and then finally metadata is a very important sample term metadata is a convenience uh feature that really allows self-configuration between the identity provider and the service provider and what that means is instead of having to manually grab a certificate different endpoint urls and issuer information etc from the identity provider to plug into your service provider manually and vice versa the metadata allows you to just share either a xml configuration file or share the urls to these xml configuration files and then the service provider and identity provider can self-configure themselves based on the information within these configuration files uh it makes it a lot less manual and a lot more convenient so let's get back to that whiteboard and really add these uh saml concepts to our single sign-on diagram and and really build out uh the idea there okay so we have our identity provider also known as an idp and we have our service providers which are the applications the user is trying to sign into also known as an sp when the identity provider communicates to the service provider that communication is called a saml response one really important thing to know about saml is that there are multiple different places in which the user could kick off the authentication process very commonly with workforce identity providers you tend to have a centralized user portal where a user has a list of applications that they can click on and that kicks off the process without them ever going to the service provider first this is called idp initiated make it in it idp initiated really has the user going to the identity provider and kicking off that saml response automatically go here and then straight over into the application that they are trying to access now the other flow or the other place that a user could trigger authentication uh would be starting at the service provider and at that point the service provider will send the user to the identity provider so in this case this communication here from the service provider to the identity provider this is where the saml request comes in so notice in idp initiated there is no sama request in sp initiated which is what this flow is called service provider initiated there is a request to the identity provider and then of course what comes back from the identity provider is the same saml response that is triggered from idp initiated so as you can see the saml request and the saml response are the two most important communications that happen within saml the identity provider needs to understand how to receive a saml request and how to produce and create a saml response the service service provider or the assertion consumer service at the service provider needs to understand how to receive that sample response and validate it but then also potentially how to generate a sample request if service provider initiated wants needs to be supported it's important to note that not every single service provider will support service provider initiated some only support identity provider initiated and some service providers don't support identity provider initiated at all some of them only want users to start at their application so this is entirely up to the product and to the developer who's implementing saml to decide whether they want to support service provider initiated or identity provider initiated so let's go ahead and dig into what this request and this response actually look like so this is a pretty common example of a sample request saml is all xml both the request and the response so the id within the sama request is generated by the service provider and this identity provider will respond to this id within its saml response issue instant is a time stamp for this request and this is a point of verification for the identity provider for example they could only accept requests within a specific time frame the destination is pointing to the identity provider and this is another point of verification this is the identity provider url literally the place we're sending this saml request to the identity provider can then check the destination to ensure that it is the intended recipient of the sama request now the assertion consumer service is basically in identifying uh where this response needs to go to after the user has authenticated um this is a point of verification as well because it the identity provider can check that the place we are telling it to send the user is where we expect to be sending the user based on the saml trust that we have configured and then finally we have the issuer for the service provider um or the issuer for the identity provider rather and and this is really just a predefined string that's set up within the the saml trust it's normally a url formatted string normally it's the entity id or the issuer that comes from the identity provider the important part is that they match the the issuer that is being sent along in the sample request needs to match what the id provider expects and then the issuer will also be sent in the sample response you know to the service provider once again it needs to match finally this xml is stringified encoded and passed in the query string to the identity provider when it redirects the user and then that's where the identity provider authenticates the user and prepares the sam response so this is a pretty common example of what a saml response will look like now keep in mind that this response is being sent to our service providers assertion consumer service by our identity provider after the user has authenticated notice the id this id will be in response to the id that we generated within our saml request we have the destination which should be our search and consumer service this allows us to verify that this response was meant for us we have the issuer which is that unique string typically the entity id from the identity provider that we are just comparing as a touch point for our saml trust we have multiple assertions within the saml response asserting information about the user and these assertions are all signed notice the signature over each one of these assertions keep in mind that each assertion should be signed we have the subject which is in reference to the user who we're signing in the name id will contain the unique identifier or the username of the user finally we have conditions or a conditional window the not before or not on or after give us timestamps that really allow us to have a validity window for this sample response so the identity provider can really define how long this response is good for before we no longer should be accepting it at the assertion consumer service other attributes could potentially and are potentially going to be within the saml response as well these will contain things like the user's name address or other profile information now real quick before we kind of jump into best practices in saml design i wanted to touch on something that is very common within single sign-on which is provisioning so provisioning is essentially a means of keeping user profiles in sync from the identity provider to the service provider the identity provider should always represent your source of truth so it should be persisting or pushing or updating your service provider in some way now there's two most common ways of doing this would be just in time provisioning and real-time provisioning um let's go back to the whiteboard real quick and just add those concepts you know to our diagram just so we can see the different provisioning options within single sign-on so just in time provisioning works just as it sounds when the identity provider is sending a saml response to the service provider if that user does not exist at the service provider just in time provisioning or jit would create that user's account over within the service provider now if the account does exist but the attributes within the saml response contain different information than the user profile within the service provider then jit would also be responsible for updating that user's profile within the service provider now there's another type of provisioning that's really popular and this is called real-time provisioning now real-time provisioning works just as it sounds by having the identity provider hold the responsibility of keeping the user profile within the service provider updated in real time so as things are changed within the identity provider the identity provider makes those changes to the service provider this is typically implemented using a standard like skim or just straight platform integrations between the two products every single time an event is triggered an update event is triggered in the identity provider that event triggers a push to the service provider so that when the sample response is sent to the service provider there's no need for jit or updates or anything because everything will already be in sync it's important to note that saml doesn't require provisioning to function just in time could be used to keep the user's profile data within the service provider in sync with what's being sent over by the identity provider but the service provider could also choose not to accept any attributes from the identity provider and just keep its profile information about the user separate at this point the identity provider wouldn't send over attributes and the saml response would just be used for authentication alone so that's how saml works at a high level it's basically a standardized way of using xml to facilitate single sign-on but there's still some very important things to take into consideration when doing a saml implementation let's take a look at some saml best practices first it's important to understand the most common weak points within a sample implementation the primary weak point is a flawed assertion validation incorrectly implemented at the service provider within the assertion consumer service essentially if the assertion consumer service isn't validating every single point of validation within the saml response there are weak points and exploits that could potentially take place another very common weak point is the xml parser itself a lot of times xml parsers contain more features than you actually need and those features if left open or enabled provide a a point of exploit for a bad actor and then of course using insecure libraries that aren't properly implementing parsers and aren't properly implementing you know saml in the most secure ways using these best practices is another very common uh weak point within a sample implementation saml might be complex and it might be a flawed but it can be extremely secure if implemented properly so that really is the first thing to focus on limit as much of your xml parser as possible when implementing your assertion consumer service specifically focus on things like document type definition fetching or dtd fetching this is going to protect you against xml external entity attacks where the sample response could be intercepted by a bad actor and then modified to instruct your parser to load external files or resources this could for example be used to load extremely large files which would then allow someone to replay this modified response and ddos your search and consumer service forcing it to download large files over and over and over again it also could be utilized to execute a remote code which could uh be a a big risk to your search and consumer service it could even trick your parser into revealing content of local files on your server so it's definitely important to limit your xml parser as much as possible some would even say to basically implement your own xml parser only the basics only the things that you need but keep it as minimal as possible next it's very important to use canonicalized xml canonicalized xml is a way of normalizing your xml using a specified algorithm or method this is going to protect you against the manipulation of things that maybe don't affect the signature within your saml response in 2018 there was an exploit that was found where a disgruntled administrator was able to gain access to a system that he did not have access to simply by creating a standard account that was very similar to a known administrative account and so the way this worked is this disgruntled i.t administrator already knew that the system he wanted to access used a specific username format and for our example we're just going to call it validuservaliddomain.com so he created a standard user in his directory service and he just added dot bad actor.dev for our examples purposes creating an account called validuser validdomain.com.badactor.dev very similar to the administrative account with just that badactor.dev added at the end of it and so he was able to then generate a saml response and intercepted before that standard account and what he did was he put a comment right in the middle of that account's username so validuser validdomain.com comment xml comment and then uh bad actor.dev um and what this did was this tricked the parser into stopping at that comment when it read the saml assertion or the sample response at the assertion consumer service so the search and consumer service thought that this account was just validuser at validdomain.com because it failed to notice.badactor.dev this allowed the administrator to sign in as the administrative account for this system that he was trying to access if using canonicalized xml this would not be possible because the comments would have been stripped as a part of that normalization process so that comment that he added would have been removed at the assertion consumer service automatically and therefore not allowing it to trick the parser into seeing the username incorrectly next it's important to validate the schema of the xml within the saml response you could accept any formatting or any xml that comes along from a trusted identity provider but this opens you up to things like xml signature wrapping attacks where um arbitrary pieces of xml are added outside of the signature elements to your saml response this could allow a bad actor to for example bloat your xml documents and ddos your search and consumer service via buffer overflow um you know you also could use xsw potentially to escalate permissions depending on how things are implemented so it's better to just validate the schema of the xml to ensure that only what you're expecting to be receiving is being included in this xml document and even better it's really good to use specified xpath expressions to get to the specific things within the xml that you're looking for this is going to reduce the the window of opportunity for a bad actor to manipulate the xml outside of the signatures outside of the other points of verification that you're looking at by really ensuring that the xml is is formatted in the way that you expect next it's really important to validate every signature every single assertion within the saml response is going to be signed every single signature should be validated and even further we should be rejecting any saml responses that are partially signed it's also important to limit the signature algorithms that are going to be accepted by your search and consumer service if you don't specify specific algorithms that you're going to accept it opens you up to attackers being able to forge a saml assertion by creating the assertion with an algorithm of none or no signature it's always best to specify rsa 256 for example as your preferred or your only acceptable algorithm up next let's make sure we're using ssl encryption https is kind of a no-brainer these days and it limits our exposure to attacks that require the intercepting of the saml response now we are still vulnerable to things like replay and cross-site scripting attacks but https is still an important step all the same next it's important to validate the parties that are referenced within the saml response when the identity provider sends the sample response to the assertion consumer service it's going to contain different information such as the destination the audience recipient the issuer these are all points of validation that we can check with to ensure that it's what we expect at the assertion consumer service for example the destination should be our search and consumer service are we the expected destination for the saml response the issuer should match the issue or entity id from the identity provider it's also important to enforce the validation window this is the not before not on or after time stamps that are included in the saml response we should not be accepting any sample responses that are outside of this window another thing that we can do to protect our search and consumer service is to create a historical cache if the validity window for a saml response is 20 minutes we can create a cache double that of 40 minutes and track all of the unique ids that we see during that 40 minute window and if we see a duplicate we can reject it knowing that it's a replay attack another thing we can do is to keep the buffer as small as realistically possible this is going to protect us against ddos attacks where an attacker is sending an oversized sample response or xml to our assertion consumer service with the goal of shutting it down and that's it those are all the things a developer needs to know about saml how it works from a high level and things to take into consideration when implementing now a common question that tends to come up is what are the alternatives who should use saml saml does have flaws it can be complex what else could i be considering the answer to that is oauth and openid connect oauth is a popular standard used primarily for authorization today and openid connect is an extension to that standard that adds identity concepts making it a really good fit for single sign-on if you're a developer this analogy from a colleague of mine joelle is very helpful saml is to open id connect as soap is to rest just like rest was created to address some inherent flaws with soap openid connect has been created to address some of the flaws in specs like saml it's flexible it's easy to use very widely adopted and it's reliably secure if you have a reason to use saml within your project you have a requirement and it has to be supported by all means you should use saml but if you're starting a new project and you're trying to decide between saml and openid connect i highly encourage you to research and to consider openid connect because it is where the industry is going it is the more popular and and more modern um solution to single sign-on so thank you everyone for joining a developer's guide to saml i hope this information has been helpful and i hope that you enjoy the rest of octane thank you

Channel: OktaDev

Views: 26,561

Keywords: IAM, Okta, Oktane, Oktane21, SaaS, Zero Trust, access management, cloud access, cloud identity, customer identity, cybersecurity, developer, digital identity, identity, identity and access management, identity management, lifecycle management, remote event, security, virtual conference, virtual event, workforce identity

Id: l-6QSEqDJPo

Length: 27min 46sec (1666 seconds)

Published: Fri Apr 09 2021