Demystifying SAML Using Spring Security

welcome everybody we're gonna get started demystifying saml we have a few housekeeping items the spring security team is hiring so if you love Java if you love spring and you want to work for pivotal please apply don't forget to rate the session that is the mobile app you've downloaded we're gonna do QA we're gonna try to fit it in if we don't fit it in we're happy to answer any questions outside the room afterwards we get a short time for us to move out of here when we're done most importantly contributions to open-source is not just code or PRS you open up a bug request or bug report that's a contribution you write an article that's a contribution you ask a question and gets answered that's a contribution so I love open source make sure you contribute in some way so let me introduce my coworker hello everyone [Music] I'm sorry - MIDI and I'm a huge Kimura fan so by the way so alter-ego I'm a senior manager of product management at pivotal and I started off my career 14 years ago as a software engineer at CA Technologies working on various enterprise security products and then eventually moved to product management at pivotal I was product managing UAE which is an identity proxy and then in my current role I'm responsible for security of the overall platform which is a pivotal Cloud Foundry Thank You Sri Sri is our identity superhero if you turn a blind eye then I aspire to be that - at the end of this talk we want all of you to be sam'l superheroes my name is philipp annek I'm a software engineer I currently work on the spring security sam'l framework we just started a rewrite to align it better with spring security and we hope to make it part of the spring security offerings today we're gonna go on a journey sam'l is not an easy thing I remember when I started reading trying to figure out what is it what do I need to know how do I use it other than reverse engineering where do I go and I felt I'm not going anywhere so today's journey we're gonna take you to nowhere you're gonna know everything about sam'l that you do need to know Sheree and I did a presentation a couple of years ago an open ID connect and we try it out what we call the demystify concept basically how can we take something that's very complex and in less than an hour make sure you're empowered when you leave here to take it further or to use it straight out of the box we want to teach you what you need to know and at the same time how do we not overwhelm you with what you don't need to know and we'd like to do this but breaking it down all the way to the lowest level so that you can use it and walk away from here and understand what you're reading what you're seeing what it means most importantly Sheree and I are infinity Wars super nerds and we love that movie so we're gonna incorporate that into our story time we want you to have fun here we're gonna be laughing at ourselves so feel free to laugh with us sam'l had a little bit of an escalation path started out in 2002 in less than one year we had a new specification about nine months later in less than two years after that we had a further specification so from 2005 the last specification was worked on until 2012 when it was completely ratified with all that Arad us so what's going on why are we talking about sam'l essentially we're talking about something that's 13 years old why aren't we talking about OAuth open I'd an open ID Connect well we did that two years ago and there's a great video but sam'l continues to perforate the enter price it is still the most popular single sign-on and single sign-off integration point there is so while we see that open ID connect an OAuth is widely popular and much easier to work with for greenfield applications sam'l is still very important and for an engineer to be in the field for 13 years you might have never even heard of it so it's a long time so we like to bring back things that are important to us shree night at pivotal have also worked on cloud crown dua a which is an authorization server as well as a sam'l server so today we're going to take all of the sam'l terminology which can be pretty overwhelming and we're going to break it down one by one until we figure out what it is so what is sam'l oh wait a second who here has not watched infinity Wars all right I'm gonna spoil the movie rotten for you so sorry about that but if you go watch the movie after this and they can't blame you for using their continent right sam'l is kind of like Danis so in infinity war Stannis is the villain his this mega beast that we don't really know what to do and he's found a problem and he's got an awful solution to it but the problem is real and he wants to solve it and Samuel is a little bit like Danis alright I'm gonna solve all these problems yeah it's not going to look pretty and you're not gonna like it but I'm gonna solve it so we're gonna tell you a story we're gonna bring in a user to this because after all Samuel which stands for security assertion markup language just the name makes me crazy but since we're dealing with security we're gonna be dealing with the users so we're gonna bring in a user into our story we're gonna call him Peter and Peter wants to use an application he's never been inside of this application never used any of the services he knows how to get there but the application doesn't know who Peter is so that's not a strange use case dr. strange right I know I was gonna make I've been practicing that one all morning well in infinity Wars Doctor Strange gets trapped on the cue ship and Peter wants to rescue it but dr. strange has no idea of Peter as so he needs some time yeah loyalty what stuff I know what you're gonna say you should not be who you should not be who you should not be who you should not be here you should not be here right Doctor Strange has no idea who Peter is you can't come in here help I don't know who you are so Peter needs someone to vouch for him so he asks Tony Tony tell him who I am so in our use case Peter is the user Tony's going to vouch for him in the Sam world we refer to that as an identity provider and the application that he wants to access we're gonna call a service provider to update the terminology a little bit we typically refer to the user as a user agent and that way goes across open ID Connect ooofff sam'l any other protocol you use the application that needs to know who Peter is is referred to as a relying party so that's from the word rely this application has to rely on somebody else to get there that makes Tony the asserting party we're gonna assert so to capture eyes we have user agent asserting party relying party so we're gonna bring up the speed a little bit [Music] we need a lot of things to get sam'l done it is not an easy specification to pick up as a matter of fact it is five specifications the first one is the metadata specification this simply defines the rules or who an identity provider is or service provider the core protocol so this is where most of us turn right I should probably read the core protocol first there is nothing but like 80 or 90 pages of XML schemas these schemas describe the messages that are being sent back and forth so for that obviously we're gonna need another specification the binding specification how do we send these messages back and forth by now we're so confused we've read three documents probably over 200 pages and we have no idea what we're doing so we need another specification the profiler a use case is a profile so Peter logging in front of a browser to a web application that's a profile so this is probably the best document to start with if you want to immerse yourself as it wasn't enough implementing and this becomes very difficult so we need a specification that tells us how to do that and how to conform to the other four specifications luckily it's been 13 years so we know what the reality is this by the way that's this is the reality stone that Danis is trying to get on his glove and for us samih has really boiled down to 90/10 use case meaning 10% of what's in the sam'l specification is used in 90% of the use cases so let's take a look I've created a demo these slides will all be there scrubbed of non approved content are available in this repository as well and we built up a couple of applications here is a spring security identity provider we're gonna log into this provider so I am Peter Parker my password is password because that's Peter not Peter Parker password I'm now authenticated I'm still on the identity provider and I want to login and we reached nowhere we're authenticated we're on the service provider application so our URL did change we ended up on the service provider here demo SP and the application is kind enough to show us something called an assertion assertion great choice for a word what is an assertion a positive statement or declaration often without support a reason so when I when I first started working with sam'l I was like well there's there was not much support for it when I first encountered it but I could never find the reason so assertion does it seem to be fitting what did we just do Peter wants to rescue dr. strange he needs Tony to help them make the introduction the profile we're going to use is our web profile remember the 90/10 almost all sam'l integrations use the web profile meaning they're leveraging the browser to send messages I'm authenticated against the identity provider so for those whom use big integration points like octa and it gives you a menu of applications you say I want to log in to my expense report application that's a service provider so you pick an application you want to log in to a service provider all it does it sends back an HTML form with an assertion the browser submits that assertion the application validates it and you're authenticated so what really happened let's dig in I'm gonna log out and we're gonna do this flow again let's go back to our identity provider browsers now have pretty nifty little tools for inspection including sam'l we're gonna turn off JavaScript and let's login and once again so I sent my request when I click the link I want to go to this application the browser responded with an HTML form that auto submits but we disabled we disable JavaScript so it's asking me to do it manually and here is our Sandler response a single hidden variable called sam'l response that's it and now you can see why sam'l is a little bit hard it's not an easy little thing we're looking at here we hit continue and the browser did send a response back the little chrome extension was able to decode that data for us and present us with that XML and inside of here you're gonna see that our assertion is in here very deep but there it is we're not quite there with the framework itself we have milestone releases out there we want feedback go for it when do we plan to put it in spring security well I was hoping that it would be independent library by now and we're reworking it a little bit to be in spring security so I'm definitely hoping within I would say the next six months there is a spring security sam'l as an independent library we want it to be this to be a sub module of the mainspring security that's this guy spring guy at least for the last four months go for it sir after we roll it up into spring security proper will it continue to be usable as an independent module absolutely the easiest thing to do those is the module today depends on spring security by having it be part of spring security proper it's still a separate jar it's still separate artifact that you add as a dependency but it's tied to spring security version we know it works with the question is what are the limitations from the existing spring security sam'l project it's built on open sam'l to an open sam'l to stop development a while back and has a few known CVS that are not being going to be addressed it's not an easy way to upgrade from that because open sam'l 3 was a complete rewrite with no backwards compatibility so what we're trying to do is abstract all of that [Music] abstract all of that so that even if that changes or happens in the future or if we wanted to bring in another library underneath it we can totally do that it's a spring security sam'l will be built so that we can easily test it meaning I don't have to deal with XML I should be dealing with Java objects I should easily be able to write tests that creates these objects so that I can write scenarios that test my integration points it should also you shouldn't have to deal with any open sam'l library at all so for those those of us that use the previous and the clarity you a use spring security sam'l one you notice that often when you extend it you're extending org open sam'l classes we don't want that to be case we want you to implement our interfaces extending our classes so that we can ensure you maintain backwards-compatible and that's the main goal here no love we'll be here all night we're gonna close the door so you're not gonna get out of here until I'm done with the presentation go for it sir the question is how does this compare to how does this compare to or open ID connect and JSON web tokens you know what I'm gonna let sri come up here and talk about that because it is part of our presentation and we might as well cover it now yeah so we actually have a slide on that from a differentiation perspective I would say that Open ID Connect is definitely solving the same problem as sam'l in terms of identity and single sign-on but Open ID Connect is based on newer frameworks like o and newer protocol specifications which is JSON JWT so it's a much lighter weight option for achieving the same thing but from a perspective of implementation with sam'l you are using XML as a way of asserting the identity whereas with Open ID Connect you are using a JWT which is a JSON web token from a security standpoint it's pretty much a similar structure things are signed encrypted that support is there both on the sam'l and the Open ID connect side but from a micro services security perspective the recommendation is to go with something like Open ID connect and Roth because it gives you more flexibility and it helps with different kinds of applications so you could have a web application a mobile application an API talking to another API and using Open ID Connect is a better way to achieve micro-services security as well as identity propagation and if you look at it it's a super small world out there the the people that wrote the sandwich specification a lot of them transitioned over to open ID Connect I think open I connect worked out a little bit better because they started with the 10% of functionality to achieve the 90% of use cases so it started really small and they're only adding features as extensions as opposed to making it part of the core protocol but for example open Ida Connect has a user info endpoint sam'l has an attribute query endpoint it achieves the exact same thing the content of an ID token is gonna mimic what you have in an assertion the question is do I think open ID Connect will replace sam'l in the future I believe so we did have the same question ten years ago will Sam will replace LDAP and I'm pretty sure we're still seeing a lot of LDAP out there all right I'm gonna continue so I hope for at least for all new applications you're using Open ID Connect and Olaf because it is easier to work with we're not going to go super deep into spring security sam'l today because we are only on the milestone release this but feel free to check out this repo and give us feedback but what I want to show you is that HelloWorld and simple things should not be difficult so one write a test case is Peter Parker and the assertion we just had right this thing we saw on the webform that giant thing what is that and spring security of sam'l itself uses a little utility class called spring security sam'l in this case we're using open ID open sam'l and from that we can decode our response and then we can create a sam'l object out of it we're not doing any decryption or signature verifications right now but if we have that we have a super easy way to represent those keys a sam'l response that was the XML object we saw now let's just do a simple assertion let's assert that that response and in its assertions we're gonna look for the first assertion as a subject has a principle that principle has a value guess what that is it's the user name so we want that to be equal to Peter Parker and that's our test case but what we want to show is that this framework is going to complete it's going to be pretty much you're just gonna plug in your user store and then the influence are gonna run themselves very rarely are you gonna be intercepting this but running this test and dealing with these XML objects should be pretty simple so if we change this just to show you I'm not totally I'm not playing a trick on you we should probably get a failure by now and that's right there it is very simple very straightforward okay I didn't Airy provider initiated login all we did was submit a form with a giant slab of XML that slab of XML does have some valuable data it's called a response where is that headed who is the intended recipient of that who sent that message and remember it's not the user that's actually sending the message the users just the middle point and who do we describe and just like a jot token or JWT token that assertion can be encrypted or we can encrypt just the username itself okay that brings us to Shree who's gonna talk about the metadata Thanks awesome I hope you are all having fun so we are going to switch gears and talk about the soul infinity stone and which is referred to as metadata in our talk the soul infinity stone is a special one which reveals all truths and same is the case with metadata so Philip showed a demo of the IDP initiated login where and you had an identity provider and a service provider and they were sharing an exchanging sensitive information the identity provider was share was sharing the users information and the service provider was trusting that information so in an enterprise setup the identity provider and the service provider are not necessarily sitting behind a firewall you know a service provider could be in a completely different domain so Trust is paramount in these situations most importantly Trust is a two-way street it's not enough that the identity provider trust the service provider the service provider has to trust the identity provider as well so over here we have the octa identity provider UI and what we are doing is we are registering the service provider here so this is one way in which information can be exchanged is you go to the identity providers administrative screen and you register your service provider so this is one way of doing it but it is fairly manual another way is metadata can be made available as an XML in a URL so what that means is again in an enterprise context you know when you are setting these things up it's dynamic things can change properties about the identity provider properties about the service provider they can change there should be a way to pick these up dynamically as opposed to configuring them statically so this is another way in which you can share metadata between the two parties so this is the big metadata that I'm going to explain so this actually follows a schema which is governed by the sam'l specification what I'll do is I'll walk you through the common parts which apply to both the IDP and the SV for short and then I will walk through things which are specific to an identity provider and things which are specific to a service provider so both of the metadata's they start off with the tag of entity descriptor but the important piece here is entity ID so both the IDP and the SP are associated with a unique identifier which is called an entity ID in this example it is a URL but it can be any unique identifier however you know like as as I've wrestled with setting up sam'l trust relationships with different IDPs one thing that you should keep track offers but the public providers so we have Azure which supports sam'l and in those scenarios it's mostly a URL the IDP entity ID is a URL and so AR and it's expected that the service provider entity IDs are also URLs because you are operating over the Internet and there should be a standard way to identify the next piece of common information is the key descriptor so we covered that assertions can be signed they can be encrypted but it applies again both to the service provider and the identity provider you could have the service providers and signed authentication requests to the identity provider and you can have the identity provider send signed responses or signed assertions in the process another piece of information is the logout URL so logout URL is something that will we'll explain further on but for now basically what this means is it's a way to log out the user from the various service providers that they have logged into through the IDP so again this can apply to both because logout can be initiated from both parties there is another important piece of information here which is binding which specifies how this request response is initiated in this case it is HTTP redirect binding so it has initiated as a redirect and messages are flowing as query parameters the next piece of information is the name ID format so at the heart of it what we are trying to do is assert on an identity or a subject and the user identity follows a pattern most of this in most of the scenarios I have seen email address being used but there is an interesting one that I would like to call out which is transient what transient means is the identifier is applied only for that transaction so the you in there are situations you know like where you don't you consider the user ID to be a PII like personally identifiable information and you do not want to share that with third party so just further search just for the transaction you will generate the IDP will generate a identifier and share it with the ESPE but not the actual ID with a net system okay now let's come to things which are specific to identity provider the first thing is it starts off with the IDP SSO descriptor as the tag and it can also specify whether it it only accepts signed authentication requests so what that means is if the service provider does not send a signed authentication request the IDP will reject it and the federated login will not occur and it will finally for identity provider the most important piece is where is the login happening what is the location of the login so that's what is under the single sign-on service URL and the binding here is forced so so you saw in the example how we are using a post by ending for federated login for service provider it has the SPSS or descriptor and there are two attributes service provider can also have an attribute which basically says hey I'm going to sign the authentication request and let the identity provider know and another piece of information is whether service provider accepts only signed assertions so if this is again you know set to true that means if IDP is not sending the signed assertion service provider will reject it finally for a service provider we have the assertion consumer URL so Phillip and I were joking about it by this new term why cannot we just use single sign-on URL so that was a bit confusing but assertion consumer service URL means where the service provider receives the assertion from the identity provider and it has an Associated binding as well thank you Shree the two things that were super important what Shree said the soulstone that was part of Gamora so that's why she's a good Moore and she talked about the soulstone zone sorry for spoiling the movie in the back there the other part was when we showed the octa registration page what octa is asking you to do at that point is dig into this XML and extract it and place it into those fields that that is really what's taking place because every provider service or ident provider will have their own description we'll do a super simple demo here where we gonna reverse it a little bit we'll go to that service provider section here and we'll leave our sam'l portion open but we're on our little demo service provider here and we select an identity provider we want to go to in this case we can actually go to a provider that runs on Cloud Foundry and we're sending an authentication request to that provider now that provider doesn't know who I am so it does need to identify Who I am in spring security often user we're gonna do user password is standard and we're logged in at nowhere again this case we're at this time we actually have a few attributes these attributes came back with the assertion and something called an attribute statement so when we're talking about open ID Connect than a JSON web token while these are a token claims attributes same thing same same but different and what took place here is that again we're using a web scenario the browser in this case accesses the service provider directly who now issues a 302 and in that 302 there's a sam'l request parameter so we've talked about bindings two of the bindings we've used now the HTTP POST and the redirect the redirect has a size limit most web servers will not parse headers that are larger than 8k meaning that whole request packet and assertion is bigger than that so when we go to the identity provider that assertion is too big so it's using HTTP POST to send that response back to the service provider we validate that and this is where she was she was talking about transient transient that means I can use that user once after that my session expires I don't again don't know who you are or we use persistent meaning you have some identifier that we know is not going to change all right in the end Peter and Tony they do rescue dr. strange so the story is over in sama world we refer to that as we're signing off but it's a feature in sam'l so let's go over how that works in the web world we're essentially establishing sessions everywhere we're not going to be sending this assertion back and forth because the more we do the more we compromise it if the user wants to log off or sign off we can use a single logout feature if we initiate it through the service provider this service bird has to contact the identity provider who keeps track of all the assertions that's issued on behalf of your user and logout of the other applications as well and we're finally logged out this here is an actual flow in sam'l where you can use back channels but again it's not very often used and becomes very complicated in the web profile what really happens is I'm sending my logout request to their application who sends a 302 redirect go here the identity provider says ok but you need to go somewhere else first and logout so it sends you to the other application you're logged in it who logs you out and you bounce back and forth until all your sessions are closed and you're back up the application but you're not authenticated and the exact same scenario happens if we go to aqua directly and say I need you to log me out octa is gonna bounce to your browser and push through so that's a distributed sign-off we close the sessions everywhere it can happen through back-channel or through the most to common bindings HTTP POST or HTTP redirect I'm going to let Street talk a little bit about the features that sam'l does have that we don't see used very often we go out to enterprises and integrate very often and very rarely do we touch on any of these features as a necessity to integrate our application into their identity we need the other mic turned on please okay so we'll try to tackle it as a group of features so the first group is assertion queries attribute queries and artifact resolution they all have to do with user claims so assertion query is something again which is not widely used but it is typically used to look up an existing assertion so if an identity provider has generated an assertion but for a given reason you want to go back load the assertion again it maintains a cache and assertion query is a way to go and load back the older assertion attribute queries as an important profile because it lets you lazy load user claims so what that means is you saw how the sam'l assertion was carrying user attributes but you can only send so much information in in one go so if a user is part of thousands and thousands of groups that your application would like to receive how do you make that possible so that is made possible with the attribute query profile where in through a back-channel you are able to query for more attributes about the user finally artifact resolution is something which is used to get a assertion without a browser agent so an artifact is generated for a transaction and then you go take that out of and exchange it for the actual assertion from the identity provider when I was reading about this you know I was thinking about the authorization code grant flow in Roth where and you get a code but that code gets exchanged for an actual token the next set has to do with name identifiers so again this is a you know this is not that prevalent if there are multiple service providers and they all have to agree on name identifiers so there is sort of like this configuration nightmare and that's what these these profiles solve there is another aspect to this which is if a name identifier as in a user identifier changes and you have to propagate that change across all service providers how do you do that and that spec goes into that the final group is the relay State ECP profile and soap URI so ECP profile is something that is used it was a much later addition to sam'l to deal with browser less scenarios wherein you have highly trusted applications which can collect the user name and password as opposed to the identity provider so you don't need a browser in the middle and then send that information to identity provider for authentication the release date is something that applies to both identity provider and service provider and it is it is something that is used to maintain a state for the concerned parties so if you are doing a sp-initiated flow a service provider could throw a release date on it for the sake of remembering where the user initiated the certain like federated login or transaction so that they can come back to the same point so from a user experience perspective I have seen relisted getting used but it's heavily overloaded like everyone has a very different understanding and implementation of this particular parameter finally soap so sam'l has been used extensively for web services security and that's where soap comes in so sam'l assertions can be encapsulated in soap envelopes and they can be passed along in web web services security related transactions and that's where the soap binding comes in I sort of discussed this during the time when we were having the snafu with the connection with sam'l versus open I reconnected just like a quick yeah distinguishing of both of these protocols so timeline-wise you know sam'l obviously is a much older protocol open ID open ID Connect started in 2010 and there were still additions done all the way through last year format wise protocol and format wise sam'l is HTML sorry HTTP and XML Open ID Connect is rest with JSON sam'l obviously is much deep rooted in the enterprise scenarios than Open ID Connect Open ID Connect is built on top of OAuth framework which has its beginnings and the social sort of like in the social trend or the social age so Open ID connectors you know like being adopted more and more by the social identity providers but it's finding roots in the enterprise so if you see a lot of the enterprise identity provider products like paying your ACTA they now have open ID connect support to user gleams in sam'l it's a sam'l assertion that carries the user claims in Open ID connect it's an ID token back channel communication to load more information sam'l does this with attribute query in open ID connected as the user info endpoint browser less or native sam'l has the e CP profile in case of Open ID connect if you want to do browser less you can use the OAuth resource owner password grant where the high highly trusted application can collect the users credentials and then finally a note on Interop so there are specifications out there to deal with exchanging sam'l assertions for you know author open ID tokens or vice versa so this is obviously very important when you have a hybrid environment you have certain applications that can understand only sam'l you have microservices obviously that can understand orthokinetic connect but they need to interoperate and that's where token exchange comes in so a quick announcement so you al Cloud Foundry UAE and the pivotal single sign-on service which support open ID Connect we recently certified so they are now certified open ID connect identity providers and they are now listed alongside other providers on the certification page so what that means is we we support all the profiles required to be supported and we can interoperate with the standard libraries out there thank you Shree the UAA we often see a scenario where you authenticate into the UA using a sam'l assertion from your company sam'l provider and then the UA translate that information into ID tokens for the applications running on Cloud Foundry or outside of Cloud Foundry and that information then becomes available through the user info endpoint as well so it is it is pretty nice way of being able to tie the two together what did we talk about and what do we want you to walk away with identity provider it simply tells somebody else who you are it's an asserting party a service provider that will be your application if you need to integrate you need to write a spring boot application that integrates with sam'l you will become that application becomes a service provider or a relying party single sign-on and single sign off are the two most common profiles are used cases the two most common bindings are the HTTP redirect HTTP POST if you fully understand those and how simple they are but it looks so complicated when you're trying to read about it then you are 90% their back channels are supported but not very common and we do have the similarities between open IT connect and sam'l so last time we did a Lord of the Rings themes and now we kind of tie them together anyway donna's achieved his goal and it wasn't pretty but he got it there and we didn't agree with it and sam'l does the same thing and it's everywhere and now that we can integrator with it pretty simply it takes us a long way and we can work on it from there all right that is it for the presentation I actually we actually do have time for questions right all right I can feel some four more questions so for global sign-off do we need to have an agent installed on the browser you do not so this will happen where the redirects so when you your browser goes to the application says log me out that application will send a redirect a 302 response the browser will follow that and then it will balance with redirects back and forth all the way until it's done so if one of these applications fail to do a logout for you it interrupts the whole flow correct so the question is by produc providing a library how's this gonna help me basically how it's gonna do is that by you setting up the configuration which is mainly the keys right you need to generate a set of a private key and a certificate to be able to exchange with only a few lines of code you're going to include a filter and now your application has sam'l endpoints and you wire that up to an authentication manager so that you have your authentication object just to add to that I mean since we are all dealing with open source the way we plan on using you know what we what we are doing in spring security on the UAS ID is you a is an identity proxy so we plan on using these profiles and the support for these profiles and spring security on the UAE side because UAA needs to connect to existing identity providers so we want to use the relying party or the service provider profile on on the in the UAE project project cool well enjoy an extended break oh there's one more everybody hang tight so the question is if you're the application of the relying party can you go there first and and the answer is yes so if I'm we're gonna close down a little bit here and I'm gonna show you so I'm gonna go to that service provider this is the relying party right this is my application and I've managed to connect my application to three different identity providers two of them are spring security sam'l applications and I'm not logged in here because remember when we logged in we're at nowhere so I go to another application which happens to be an IDP and an SP built into one so this application is going to assert my identity to where I started but this application also needs someone else to assert that your identity to it [Music] so this jumps up and let's take a look we have our sam'l inter specter we'll login and we see two posts the first one goes to port ninety ninety three it's a demo ID PSP all-in-one that asserts tied entity to that application then we're asserting our identity to the point where we started our demo SP so we changed the authentication but we started at the application itself and in this case where I started was here and if I wanted to log in I could pick I can become Peter Parker and I end up here as well does that answer your question all right well I'm gonna linger in the back one more over there the question is is there an import for the metadata generation so first of all thank you all for asking questions you making me feel more important than I am the answer is yes if we zoom in on the library here I can go sambal SP metadata like that what that actually did was that it did download a file oh that was a bad thing to do bad mojo mojo let's see downloads shall in finder open with a usable editor and here's our metadata so this was automatically generated based off of the configuration we have which is really just the keys these public keys so the question is is the same metadata for every IDP that we configure what's going to change is the IDS for the metadata get auto-generated so these unique IDs here but the entity ID will be based on your URL or you can configure it to be hard-coded and it looks like there's a lot but these URLs here's a single log out those will be automatically generated based on where you're at all right in the SP so the question was how do I configure the IDP in this be perfect good question it's a two-way relationship so let's open up our and I'm gonna make this a little bit bigger but I have two IDPs configured here and I'm gonna give them one is alias our spring sam'l what's the text I want to show it and where does this application download its metadata now if I want it to you can put XML directly in here alright so it was MD entity descriptor that is a fully valid configuration as well so we support XML either through a URL where we cache it or you paste them to XML yourself and we intend to support it just like octa where you should just give me the four things your single sign-on URL your keys your entity ID and I'll take care of the rest that makes sense actually we have three of them in here one two three there couple more features that we're building in key rotation a lot of libraries don't do that in the and the first go so we're building that in the other part is we're building in multi-tenancy as well if you want your system to be multiple IDPs depending on whatever the input is either it's a sub domain or you have other ways of creating tenants so that would be part of the library it already is go for it so the question is do you recommend using the current library in production that's a tough question if it's already there then it's already there would I pick it up today you mean this one here the 2.0 yeah would be comfortable using that the one that oh if I'm starting a new project is a little bit harder because we know there are defects in it [Music] alright we'll cut it there thank you very much you

Channel: SpringDeveloper

Views: 29,212

Rating: 4.7724552 out of 5

Keywords: Web Development (Interest), spring, pivotal, Web Application (Industry) Web Application Framework (Software Genre), Java (Programming Language), Spring Framework, Software Developer (Project Role), Java (Software), Weblogic, IBM WebSphere Application Server (Software), IBM WebSphere (Software), WildFly (Software), JBoss (Venture Funded Company), cloud foundry, spring boot, spring cloud, saml, spring security, spring security saml

Id: PruyokKaJWw

Length: 63min 25sec (3805 seconds)

Published: Thu Oct 04 2018