 OK. I think we'll start then. I've said to you of a microphone, but I think this thing here picks us up pretty well. I introduce myself. I'm David Scales, head of tech at Bright Lemon. I'm going to be taking you through some of the concepts of SAML today, and Vinny's going to be doing a demo. Most of my stuff is fairly dry, and then you'll get to see some code and things when Vinny starts. I sometimes, but when I'm nervous, so front row, just to be aware of that. It's perfect. No, no, it's fine. It's just there, but I don't think it's nice. I'll move a few rows back. Yes, you'll be fine there. OK, so simple SAML. This is an SSO that we're going to show with Drupal. As I say, we're going to cover some of the SSO background and the basics of SAML. Then Vinny's going to use the simple SAML PHP repository and connect this with Drupal and do a single sign-on between two Drupals. The first thing is a single sign-on. Let's figure out what we mean by that. It can mean different things, but in this case we're using the same credentials for multiple sites. We're having an automatic login to federated sites if we're logged into the identity provider already. An automatic log out across federated sites as well, which is an SLO. I think obviously they don't use the initialism SSO for something else. A few of the single sign-on benefits. What's good about using single sign-on? From an admin and security perspective, you get to maintain central and decoupled sets of data about a user. You can have a central ID with a really high-value user name, password, that sort of thing. Can we keep central? Let's say he's got other data in an LMS about what they're learning about, how far they've got. Then we reduce the need to sync that data into the same platform each time. It becomes decoupled. That avoids duplicating it, which is obviously good for security, and avoids synchronising it so we've got this to do there. We can also restrict and provide access to a group of sites really quickly. We've got 10 federated sites. We set up one user account, and then someone can log into that. At the point that they move to one of the other sites within the network, their account or the information they need is provisioned just in time for them to use it. When they go to, say, an LMS, that's when their details get taken in, not before. I don't know. I'm talking, but it seems okay. It's a bit different in this room. This microphone just goes to the lecture capture, so it just records on the camera, so it's not actually linked up to the PA in here. It is working. You can see here there's some levels. Thank you very much. We're just in time for provisioning for these accounts. From a user's perspective, it means, of course, they've no need to maintain multiple passwords, which is great for all their old grains. There's less risk with their data because it's technically in just in one place at one time. It also protects them from phishing because they're logging into just one trusted IDP, and they know what that looks like. Of course, once they're logged in, they've got frictionless access between the sites in your network. We're talking about SAML, so just a note about where it fits in with other major players of SSO, which would be OOF2, which is now OIDC, OpenID Connect, and CASS Central Authentication Services, which are mainly used in universities and things like that. SAML is pretty old, but SAML is widely supported by off-the-shelf software and major software-as-a-service vendors like Google, Salesforce, Amazon, as well. It's estimated that as we kicked off with SAML in 2000, version 2 came about 2005, and now we think somewhere around two-thirds of all SAR services use SAML will have provision for SAML. It's interesting that only a third of ID providers have no plans for it, so it is sticking around. Even though I've heard it called the Windows XP of Federation, which isn't a nice thing to call anyone really, but it's been rated by Gartner and Forrester Research, they say it's going to likely exist alongside OIDC for the next 10 to 15 years, so you are likely to come across it at some point. So what is it? SAML 2? It stands for Security Assertion Markup Language. It's pronounced SAML, similar to yourL, or callL, I suppose, or LL. It's an XML-based standard, and what does it do? It exchanges information securely, so usually by using an assertion about a user, it can then enable security context on another website. It establishes trust between two parties, which are an IDP and an SP. An IDP is an identity provider. Let's say that holds simply your username and password, so it can actually authorise you and say this person is who they say they are. A service provider is a service that connects to that identity provider from another site. Of course, in this as well as a user agent, which is you on the browser doing something. The examples that Vinny's going to show, these are pre-configured, so we have certificates swapped between the IDP and the SP, and they're all in the SAML config already, so that's really good for trust that we can control who's allowed to use this service. So what we're going to do with it when we start the demo, we're going to try and return an XML assertion that we can trust. An assertion is probably best described as data returned about something that's true at a point in time. It'll send you something with a timestamp and say, right now, this is a fact, and I'm a trusted source, so we're backing it up. We get this by using SAML protocols. The one we're going to use is an authentication request protocol. There are others like a single logout protocol or artifact resolution. I'll touch on that later. We'll have a binding, so we're binding this request to HTTP post today. It could be so, it could be something else. Also, there's a SAML profile, which is usually a web SSO profile. There are a few others, but you can see how, with multiple profiles, multiple bindings, multiple protocols, there then turns to be quite a few ways of doing things that you could string together. This is the basic flow of an authentication of a request. I'll run through how this plays out, and we'll take a look at the XML as we go. It's an authentication request protocol. It's bound to post, and it's a web SSO profile. Simply put, what's happening here is we've got a user agent that's saying, I want to see something. Can I see this target resource? At that point, your service provider, so your SP site that Vinny will show you, is asking the first question, it's bound to ask, do we have a valid security context to see this? Is this user logged in, or is this information freely available? If the answer is yes, then this is a very short presentation, and we skip everything else, but we're going to assume the answer is no. The service provider then makes a SAML request, follows you to the identity provider, with a SAML request in tow. That's put on the post request and base 64 encoders. What does it look like as it goes over? You can see SAML P is SAML protocol. You have an authentication request there. Important that we've got an ID, because that's going to be used to validate when we get a response. An issue instant, so we can tell at what time this was issued by the SP, not by the browser. A destination. This is essentially the endpoint, the rest point if you like, that is going to process this information. The assertion consumer service URL, which is the reciprocal of that on the SP. This is where you're going to send a response. The response is going to use a configuration for a default SP to process the assertion that you get sent. You could have several methods within the same installation to send it to different ACS URLs. We've got a binding that is post. I've taken out the digital signature. That's important. I'll show you that on the next slide. There's a name ID policy which allows us to create an opaque reference to this request. You can create something that doesn't really mean anything, so it doesn't reveal any personal andifiable information within this part of the request. The same request and responses should have a digital signature. We've got one here. I'm not going to go through it, but this is basically certificates for either server, which they're exchanging in the config, so we know who we are, who we say we are as it goes through. Once that request reaches the IDP, it's going to say thank you for that. Can you please log in? We'll be presented with a logging form. If the user agent logs in, the identity provider is happy and it's going to respond with an XML form. Forward you to request a search and consumer service with the SAML response in tow. The SP, the service can then read that response, log you in and direct you to your target resource. At that point, you are logged in on your service provider and you're allowed to see it. You have a valid security context because it's been forwarded over to the IP and it has basically vouched for you. It's created a certificate which says yes, this person is who the sale are and I am this and so they'll be allowed to log in and see that resource. A bit more about how that response is made up. Very similar to the request that went over. The digital signature goes in there and all importantly we've got a status that says success in this case. Great. The assertion part which is in the response. This is something that's true at a point in time and it's also got information to validate that as well. We've got the name ID which is the opaque name. Down here. The SP name qualifier. This is default. The name of the service provider that we're posting to and then the subject confirmation. This is like a bearer token. In fact there's exactly what it is. We're basically saying here the bearer, whoever holds this assertion can give it to this URL in response to the original request as long as it's not on or after this time. That's basically this message will self-destruct in whatever seconds it is till then. Conditions. Conditions for that, not before, not on or after. These all help validate. We've got an audience so we know we can only use it on this federated site. Then we've got some information about how the user actually authenticated at the IDP and we can see that they're authenticated by a password mechanism. The attributes that come across that are able to then log you in. This is a Drupal example. Here we've got a UID. We've got a common name, the Drupal name, test user. We've got that email address and we've got a UU ID for them as well which I think you're using that to give the users at the minute. Then really usefully we've got some of their roles, their Drupal roles. Then you can imagine having a suite of sites say five service provider sites and then managing their roles from within the IDP. You're taking on a centralized security role so then the rest of the sites don't need that. I think that's something that's worth really making use of. That is the end of the session and the end of the response. You should be logged in and obviously then you can carry on or log out of all sites at once with the SAML protocol which is something that's a little bit more difficult in OIDC, I think. But how can we make it a little bit more secure? It's something you can use a protocol which is an artifact binding protocol and this is where some people don't want the assertion passed through the browser. They might want to send that between the IDP and the SP itself with a token for the browser so then they can reference it and access those details. Another thing we should be doing is using a common or shared time source so all of the time validation is working and definitely using a TPS. I mean that's pretty much mandatory for this sort of thing anyway. You can further encrypt the assertions so if they are going through the browser then they can go through encrypted and be decrypted at the service provider at the other end and of course input validation as well because this is essentially a post form. So let's not make it vulnerable to injection attacks and do that in the same way that used to cure Drupal forms as well. If you want to play around with some of the stuff that gets back there's a URL here there's some really great tools on this site to just kind of examine the XML and the request and that sort of thing is worth having a look at and write it down or I can put it up on the screen at the end and then I'm going to pass over to Vincenzo who's actually going to make all of this work right? Yes. Thanks a lot for that. So what are we going to demonstrate now? I'm going to show you two Drupal websites one will work as an identity provider and the second one will work as a service provider. The first one will help all the user and the second one will use the users from the identity provider. Both of them have been built on Drupal 7.43 which is the latest Drupal 7 release at the time of this presentation and I'll be using my local Drupal environment using Drupal VM which is the second box built with Ansible and is optimized for Drupal. So I'm going to show you now some basic configuration for a simple sample and I'm going to switch between these slides and PHP Storm and Firefox to show all the steps. So this is my folder structure so I got the IDP web route then I got the doc route where I got my Drupal installation then I got on the same level the simple sample PHP directory where a simple sample PHP is installed then I got the WF folder under simple sample PHP basically where you can access to the admin panel of simple sample PHP then I got the same configuration for the service provider and got the doc route with Drupal simple sample PHP with installation for the simple sample PHP and then the web directory for the admin side of simple sample PHP for the service provider. So to install the IDP first of all of course we need to run to have the Drupal installation so under my Drupal directory and then I will create on the repo from GitHub and I will check out the latest tag available at the moment. After that I will start to create my configuration file simple sample comes with a bunch of templates for configuration and can be found in the directory config templates so what I will do I will create another directory where I'm going to copy config.php for the config templates and then I will pass it into my config directory. From this config.php I can set up my base URL path I can set up my admin account for simple sample PHP I can choose the debug option I can choose the simple sample PHP functionality I can then decide what type of session I'm going to use the cookies and the store type which is one of the most important part and then for more security I can add an array of trust URL so I got the doc root with Rupal and then simple sample PHP folder inside I got the wl folder for the admin interface and then I created the config file from the config sorry config directory from the config templates directory I copy the config.php and pass it into config folder and here is my configuration file so the array contains a third path I can choose which certificate directory I'm going to use the logs directory, the data directory then I can choose the debug option the loading level 2 if I want to show errors and error reporting of course it will be false on a production environment then I will choose here the admin account and carry on the contact name the time zone and here there is plenty of configuration that we can do here I will enable my IEP functionality so sum of 20 IEP I will set it through I got the session options here the cookie option so it's quite a long file so another important is the store type set it to memcache but we have other type of store type and SQL I'm using memcache because Drupal modules require memcache but you can set up PHP session and SQL if you add SQL then you can add your SQL credential after it and at the end of the file I will have the trusted URL domain option array so after that I will download the Drupal module it's not an official module it's on Google code and I will download it into the modules folder of Symposamble PHP and to enable it I will create a file called enable inside the Drupal folder so basically on my PHP on my Symposamble I have a folder module I download the Drupal and enable by creating a file enable inside it I have the lib folder with authentication source and here I can choose between extend and user password extend will use the Drupal login while user password will use the Symposamble login interface so for this demo I'm going to use the extend one so on this file I have the method Drupal user and password user pass and it's calling extend then I have to choose the Drupal root to the bug option the Drupal logout URL, the login URL and then the attribute that I'm going to pass to the service provider so I got here the fields from Drupal and here I will rename the fields in order to pass it to the service provider so this is the Drupal field and this will be the name that will arrive to the service provider so after that I will create my out source PHP file that will contain my authentication source so I will copy that array from external.php file and I will pass it into out source as per config.php you can find it on the config.templates directory you just copy and pass it into the config directory of your Symposamble PHP so you have here you have the out source you copy you pass it into the config and then you start the configuration so you can jump the part with the service provider because this is going to be the service provider and here you can place your method so we have Drupal root the logout URL the login URL and then the fields that I'm going to pass I'm going to pass just a basic field all the other fields like road, first name last name I'm going to manage it from a custom module because I want all of them to be in one place this will be just the basic fields that I'm going to pass after that we need to enable mt-adp functionality I've already done it into my config.php and then I will create the folder metadata and ask for the configuration I have a methodata templates where I can copy files from there so at this moment I'm going to copy symbol20-adp-host.php and I will pass it into my methodata folder and inside I will set the name of the certificate and the authentication method that I'm going to use so I have my methodata folder here created here there are all the templates for the other functionality so I copy the hosted and here I set the name of my certificate and the folder has been configured on my config.php so I have my folder here and this is the name of the certificate and then I have the authentication source that I'm going to use so it's true values and pass and then we'll call external and I need to install I need to run component install in order to download some package that symbol symbol which we are going to use after that I created a sim link on the docroot folder so under the Drupal installation it's a sim link to the WLB folder so I can have access to this simple symbol admin interface from my Drupal site so let's go look so this is my Drupal site this is my identity provider and this is the admin interface for simple symbols.php so I have the welcome I got linked to the documentation I got the configuration so it says that I have this symbol to your IDP enabled I can run some diagnostic if I want I have here the authentication method then I got the federation here which is the metadata that David was talking before after that I need to one more module is Drupalode SSP and you can find it inside the same module you installed on the simple symbol.php so I got to my modules Drupalode and copy the modules inside that folder and enable it as usual in Drupal and then configure it with the path to the simple symbol.php and the authentication source so I go to my Drupal site the configuration I found my module and here is my path to the simple symbol.php installation and the authentication source that I'm going to use after that we will install the service provider and we do the same thing so we install Drupal then we will install simple symbol.php with the same way we installed on the IDP same way we will set up the config.php we create the config folder and then we place it in there and we start to configure it the outsource will be different in this case the outsource will contain the entity ID the URL of the SP and the URL to the metadata of the identity provider and then the SSS certificate name so the difference is that instead of creating an authentication source I will fill the default service provider array so I added my private key the entity ID the service provider URL the IDP option with the URL to the metadata of the simple symbol php IDP then again I run composing install I create the simulink from the doc root to the www folder of the service provider in the same way as the identity provider so this is my service provider and I have the same thing but in federation I have just the metadata for the the metadata for the service provider while in the IDP I can even be a service provider or identity provider for both of them after that I will solve the Drupal module to enable the service provider functionality on a Drupal site and this is a project caused on Drupal.org so it can be found under project FAP so we have this simple symbol php O we enable and we configure it from here we can map some file and then we can set up some other option that I'm going to show you now so I will login as admin under configuration I have my option here so again I give the directory I get the authentication source which is the default SP I will force HTTPS on login and then I will map my basic fields so I have this end for the username UID as an identifier for both simple symbol php IDP and service provider and then the mail and then here is for the role but for the role I would prefer to use the custom modules in order to have everything extra in the simple model and add some php and some checking that we can do then we can register the user it means that if the user doesn't exist on the site it will automatically create it and then for the indication we can choose to set their own password on the service provider like this and manage the account from just one source from the IDP and then we can choose which role can login or which user ID and then we can specify the role here now both of them are ready so we need just to let them know each other so we need to exchange the metadata from the IDP to the SP so first of all we are going to put the IDP metadata into the service provider so what we will do we create the metadata directory in the service provider from the metadata templates directory we will copy symbol 20 IDP remote let the IDP is located remotely and then we will go to the simple symbol IDP admin interface we will copy the metadata that will pass it into this file so we will go here we go to simple symbol php so this will be the metadata of my entity provider so we have the example format we also have the flat format for this presentation and here I have the certificate it's going to be passed so I will copy this part here and then I will paste it into the metadata of the service provider and inside the file of IDP remote and I will paste it into here same file so basically what I did I went into the service provider IDP provider copy the metadata went back to the service provider and paste it into the symbol IDP remote files same thing I will do for the identity provider so I will go to the service provider I will copy the service provider metadata and I will paste it into the same file with different name so it will be the SP remote file into the identity provider so I will go to my service provider simple symbol federate show metadata again I will copy the metadata from here and paste it into the metadata SP remote file in the identity provider so now I have the metadata of the identity provider in the service provider and the service provider metadata into the identity provider time to try to paste it so I will go to the service provider I will click on login and at this point I will redirect to the IDP login page I will fill the login form press login I will be logged in both sites so I will click on login so this is my identity provider this is my service provider I will click on login I will be redirect to the identity provider password click on login and here I am logged in one I am not sorry I would log in just I couldn't see it the screen is just like I couldn't see it here sorry the screen is just better and I couldn't see my account and log out so I was like what it did work I can redo it I haven't finished yet so basically now I'm logged in why do you have a login sign there you have a login sign I just created a menu I just created a menu here I didn't put it like I said it is logged just for show but I have my account in here so on my service provider on my account I have a menu here and if I go to my service provider I'm logged as well the same and now for any of them if I click on log out I will be logged out from the IP from the IDP I'm just to make sure from both of them I'm logged out so if you want to add more fees on creation you can use a hook presave user presave and then you have the global PHP all-sample attribute that you can use and then from there you can grab all the fields and of course as I said before you can name it from the outsource of the IDP and the attribute you can add all the fields you want here to be brought from the IDP to the service provider if you want to update the fields from onLogin you can use the onLogin and use the same the same variable to the same function to get the attribute of the user here there is some link that you can use so I got the simple sum of the IDP link the github link, documentation IDP configuration, SP configuration the localModel for SP the localModel for the IDP and then the localBHemory Okay it's a lot useful for integration to be able to apply active directory and that you kind of had an experience of using active directory Now we have an integration with Moodle so we had the same configuration so we have the IDP and then the service provider was Moodle so we were getting the user from the fromDrupal site and we are importing it into Moodle so we have this single sign on between the sites Active Directory and LDAL are pretty common they do say that SAML is essentially authentication agnostic that you can import IDP in there if you need to so LDAL is an active directory if you need to do it if you've got access to those components What are the differences in a service provider? They are similar, they are the same Exactly the same It's up to you then but really I keep the same so for example I always have you need to give the certificate directory then the bug option and then again the technical name and the admin name the only difference is that indeed the service provider will not enable any of these because it's for the the service provider apart from the BSVed service provider so this would be false but then everything would be the same unless we have different for the structure and the store type would be would be memcache as well so that's why I'm using memcache or you can even use SQL and then map the database now here Just trying to follow all the steps and just main steps main language steps can we also make this make files or script writing or do we hold that load in line with that? We cannot use make files like rushdabs because it's not a proper site for the simple stem of PHP bit You can have set the configuration the same for both of them but usually you have to configure it you have to add it to the configuration then you can use the service provider configuration across all the other sites I'm talking about all this Gifflom here Gifflom from probe.com Just to make things you have to remind me it's all very practical and you have to work You can have your own repo for simple semol with your basic configuration for the service provider for example and then when you need to speed up a new one you just clone your own repo and from there you will start You can have those repos to compose a JSON Can you use Composer to build all this? I'm using Composer I'm using Composer to download some files I'm using Composer to download some files I'm using Composer to download some files before you use Composer you have to do some manual downloads Yes You cannot use Composer to use a dependency to get the same download You could add the VCS for public service Is that how you work? You could do that No, we just downloaded it from Gifflom for both of them We just like this On the link in the last page you can see that you don't have this at home No, no, no You can find those the IDP configuration and the basic SAP configuration and then you can find the instructions on those links as well and it will be exactly the same configuration that I have done here but not the Composer The other thing I want to say about the network about that is that the documentation is simple there's a lot of documentation but it's not always right You may have my security first and only versions sometimes and it's not the same If we update the user profile for instance you just have to add it to the object of the user and save it automatically When you first login and the user is not on the SP it will create the user and it will map it to the IDP If the user is already there it was updated on the service provider but not on the identity provider From the SP to the IDP it will be automatically from the IDP you can create the user login and get data from there but what you can do is just force all the users to go to the identity provider edit page of their account so it will be central in the triple module to force re-evaluation of the roles in which that's what you want to the roles change Has anybody got experience of other open source IDPs using triple IP it's not cut into IDP and IDPs do out a simpler setup This part is not automatic From what I can see you just manipulate that attribute variable and it will be automatically sent and updated on the identity provider From here is when you login on the service provider you will call the attribute from the identity provider and it will update on the service provider in that meeting That's not how open I become or how I actually have to do this mainly but I guess it depends on what you are choosing I made an integration between node db and node base forum and on top of that I had to write on the server on top of based on the OAuth server too but if you are confused you have to write them yourself you don't get to all of everything I've made like this if they are in the same server you are forced to use the HTTPS it has more strict requirements for this stuff but it was very simple to set up Oh, for anymore I think from then there was someone Did you have a question? I had a question about managing separate IDPs so I've had a test I created a file local settings PHP I took it out from the git and in there then I do a check to see which IDP I am and then from there I can then set the variables and everything so I don't use static values in the complete PHP for the one that is changing between PHP and PHP We haven't tried on multi-set installation and we use just on Drupal 7 because the model of the IDP is on google code and the other one for dsp is on Drupal.org and I don't think there is not sure if there is a version for yeah, there is another version for Drupal 8 but then it needs to be written either one for the IDP The choice in this question in more detail could you possibly do could the proper site possibly be for an identity provider and a service provider you would be able to use it from a multi-site installation and I don't know if it's a different thing So you're saying that the site would be the service for that site would send it to itself as an IDP Yeah, it's certainly a little bit more stable than shared we might be actually a good solution for multi-site Can you share those slides later on please? Yeah, basically I will share the slides and also I will create people on my GitHub account and I will upload the same environment as well just to do some security thing to capture my emails from the repository away So on my GitHub