 All right, I'm going to get started. My name's Gavin Jackson. I run a software engineering team at Les Mills Asia Pacific. It's not an IT company. It's a group fitness training solutions company. So I'm saying a little bit left field. But we do use Drupal. And we use Shibboleth for a single sign-on. So I'll kick off. So this is an overview of what I'm going to talk about today. I'm going to give you a little bit of a background. What are we actually trying to achieve with this product using this product? An overview of Shibboleth and SAML2. Talk about the ShibOrth module that's available for Drupal 7. I'll do a demonstration of it in action. So we've actually gone live with this. And I'll try and share with you some of the gotchas that I encountered during this project and possibly things that you might want to consider if you do end up going down the path of integrating a single sign-on solution with Drupal. So a few years ago, I'll rewind a little bit further. We've got a large code base of Java code. And a decision was made a few years ago to actually migrate off Java as a programming language and move to Python. So we had to migrate a bunch of struts to web applications and Java Stripes and a content management system as well called OpenCMS to this new technology. So during this process, we decided to go with Drupal as the CMS. It's a world-leading open source content management system. And we want it to be like a transitional sort of process. So we wanted to be able to run our legacy struts to web applications alongside our new Pyramid web applications and also this new Drupal instance. And we wanted to share authentication and attribute information across all of these platforms. So we had to write a little bit of custom code. So we selected Shibboleth as an identity provider. And so we had to write a few different things, a jazz authentication plug-in that basically takes a username and password and says this user is authenticated, a Shibboleth attribute resolver, which returned back role-related information or attributes about the user. So things like this particular user is an instructor, a group fitness instructor that's trained in body pump. And then we needed a few auxiliary services that surrounded this identity, a web application to actually create a new user and a password reset web application. So a lot of frameworks, you kind of get that for free. But because we're sort of ripping it out and putting it in a separate component, you need to roll your own. We decided to roll our own. And finally, I'll talk about the SOAP API. I'll talk about some Salesforce integration, which we did much later on in the project that we're still doing at the moment. So single sign on the problem, what exactly is it? It's a shared authentication scheme across multiple websites spanning multiple domains. So basically, when you sign into a website, you don't want to have to enter another username password. That's essentially what single sign on is. It's traditionally a web browser-based tool, but lately it's become an issue for API use as well as mobile applications. And it spans across both self-hosted and cloud-based services. So I'll just briefly discuss some of the open single sign on standards that I've come across. There was a very early one called CAS, which was used a lot by universities to achieve single sign on. Then SAML1 came out and SAML2. And then there's some new ones, OpenID Connect and OAuth2. And here are some of the popular open source SAML implementations. OpenSSO, which is actually owned by Oracle now. OpenAM, which is a fork of OpenSSO owned by Fordrock. And it claims that it's open source in that the source code's available for you to download, but you still have to compile the Java code into classes. So it's a bit like Red Hat Enterprise Linux, where it's open source, but you kind of have to run CentOS to get an open source version of Red Hat Enterprise Linux. Another one called Simple SAML PHP, which I really wasn't aware of when we decided to go down the Shibboleth path. And of course, Shibboleth. So why Shibboleth? Like why did this one sort of pop out as being the one for us to pick? Well, it's actually quite widely used. It's probably the most widely used open source single sign-on implementation in the world. It's used by a lot of universities to achieve federated access between university campuses or universities in general. And so when you actually download an install Shibboleth, you'll see a lot of references to attributes inside the education space. It's very meaningful if you run a university campus to inter-operate with other university campuses. So there is certain attribute information that you need about the students trying to access your resources. SAML is a specification, and Shibboleth is an implementation of that specification. The specification itself is made up of three different components. There's assertions, so things like rules around authentication, attribute resolution, and authorization. It's a protocol. It defines how SAML asks for and receives assertions. And there's also a binding, so it's how SAML messages map to SOPE exchanges. So the complete specification as a whole is designed for interoperability between different software vendors. So a lot of commercial providers provide SAML support in their products, and that allows them to share authentication and attribute-related information between those different products. And there are third parties that go in and evaluate and document how well different vendors support the specification. And not all vendors actually support the full spec. Even Shibboleth itself is missing core components of SAML, which can be fun. So here's a quote. I won't read too many quotes, but this is from the Shibboleth website, and I think it encapsulates exactly what it is. Shibboleth is a standards-based open-source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner. So what that's really saying is that I can... I can protect certain areas in my website and say a user must have these attributes associated with them before I'll grant access to that resource. And the architecture of Shibboleth facilitates that process of this person has a valid username and password, and they also have the required permissions to access a resource. So primarily... Now, I must caveat this presentation that I'm talking about Shibboleth 2. They've recently released a new version of Shibboleth. Shibboleth has version 3, and I believe that does have OpenID and OpenID Connect support as well. So I'm really just concerned with SAML at this point. So it primarily uses the OASIS Security Session Market Language Standard, provides a federated single sign-on-attribute exchange framework for authorization and attribute resolution. Shibboleth 1 was released back in 2003, so it's quite a mature product, and it's used extensively by research and education communities worldwide. And Shibboleth 2 was released shortly after the SAML version 2 standard in 2005. So that's 10 years ago, so it's actually been around for quite some time. It's developed as open-source software and is released under the Apache Software License. The actual funding model is quite interesting, so you become a member of the Shibboleth... Oh, you can choose to enter into the Shibboleth Consortium and provide funding for the developers, because it costs them quite a lot of money to actually develop this software, but no one actually owns it, which is quite unusual for something like this. It's an established and well-used product, it's free as in beer, and the identity provider, so the piece of code that's responsible for authenticating and returning the attributes is written in Java and extended in Java as well. And the actual service provider component is an Apache plug-in called ModShib that was written in C++. So how does it work? So there's two main components for single sign-on. There's an identity provider, and you'll see it referred to as an IDP and a service provider, which is called the SP. So the IDP is responsible for authentication and attribute resolution, and the SP is really responsible for protecting the resources. So it has a definition associated with it that says this particular path, the user requires these permissions and requires authentication, and that's just in your HT Access file in Apache. So here's a little diagram of the architecture that we have in our system. So on the left are the two service providers, www.lesmills.com.au and webapps.lesmills.com.au. The www one is running Drupal, it's actually hosted on a linode virtual private server in Tokyo, webapps.lesmills.com.au runs in our server room in Canberra, and that's running a bunch of pyramid web applications. So it's all written in Python. The identity provider is ssa.lesmills.com.au and that's also self-hosted. And to the right, there's a, you can see sales force there. So we're currently going through a process of integrating with a partner overseas, Lesmills International. They have a system hosted within sales force that would like them to use our identity provider to grant access to. So they should be able, well, the intention, well, the proof of concept that we've done is that they sign into our system and they can access Lesmills International systems transparently without having to enter in that username and password. So what happens when a user actually attempts to log in? So I'll just quickly go through this diagram and then I'll do a quick demonstration in progress. So the user is at their web browser and they try to access a protected resource. The service provider generates a SAML request and then it redirects the user back through to the identity provider. So it's like they get bounced into the identity provider to a login screen. They enter in their login credentials and the IDP parses the SAML request and authenticates the user and generates a SAML response. The IDP returns the encoded SAML response to the browser which then redirects the browser, then sends that back to the service provider. And then the service provider looks at that, it decodes it and it grants access to the protected resource so the user is essentially logged into the system. Cool, so. What I'll do is I'll do two little demos. The first one will be our production system. So the live one, if I have internet access. If I don't have internet access, I've got a local dev version running. So I've got three virtual machines on my box that simulate the production environment. And what I'll do also, it's not quite what I want it. So this is just a standard Drupal CMS instance. The actual login link that you see at the top right there isn't your standard Drupal login. So when you install Modsheer, it actually, it doesn't replace the Drupal authentication mechanism, it just gives you access to a new one. So it's an additional block that you can drop into your site or you can write your theme around this login handler. So it's like login. And so we can see there that it's already gone from www.lesmills.com.au to htpsso.lesmills.com.au slash idp slash la. So this is the actual identity provider requesting the username and password. And now it's actually gone through that process of authenticating and returning the attributes and actually letting me into the protected site. So now I see a contextual menu now. So these are the internal web applications that I can access. And if I click on this one here, this update details, we can see that it's gone to webapps.lesmills.com.au and you might have seen it actually bounce into the IDP as well. So it went to the IDP to actually authenticate and it realized, hey, this user's already authenticated and it let me straight in. So yeah, so that's really all there is to it. It's not a very glamorous thing. Like it's not really eye candy, but what's actually happened is it's pretty cool. There's three different components. They can be in three different parts of the world. An identity provider and two service providers. They could be in any domain as well. So yeah, that's pretty much what we demonstrated by that. Now, I have a note here to make sure that time's synchronized. So it's really important that your time is up to date when you play around with this kind of stuff. Otherwise you get some pretty nasty errors. So that's just a little bit of a trap that I've fallen into a few times. So I'll talk a little bit about the configuration. If you have any questions or you want me to drill down into anything, if you want to evaluate Shibboleth as an identity provider, like it's, the thing that got me about it when I first looked at it three years ago was it doesn't actually work out of the box. There isn't something that, there is no real hello world associated with it. You actually have to plug in your own authentication provider and your own attribute resolver or you can have static resolvers. All of the config files are in XML. So, and if you get one small error in your XML file, things go pretty funny. So yeah, so as I mentioned, the IDP runs as a Java web application. I've got it currently running in Tomcat 6, but it can also run in JD9. The service provider runs as an Apache module called ModShib, and it's also a daemon process as well that starts up. And I believe there's also an IIS module as well, so it's cross platform, it runs on Windows as well. If you do want to go with it, I suggest like a phased implementation process because it can get quite involved and you can really trip yourself up if you try and take on too many blocks of work at a time. So this is sort of how I got started with it. So on your laptop, you install both the identity provider software and the service provider. You self-sign as cell certificates, authenticate against Active Directory or a database using the JDBC plugin. And by default, when you install the SP, there is a single protected resource slash secure that allows you to test that everything's actually working. After that, you might want to set up another service provider on your internal network on a different box and point it at the IDP. The IDP and the SP need to have metadata about each other. So during the installation and configuration process, there's metadata that's generated. And so when you're registering another service provider with your identity provider, you have to have some information about that server. And the metadata contains their digital certificate, some information about their end points. And similarly, the SP needs to be aware of the IDP that it's bound to as well. So try testing multiple attributes before granting access to a resource. So you can say this user must be in the context of Les Mills Asia Pacific. You might want to nail down resources to someone with the trainer profile. So you can say they must be a trainer to access this resource. Accessing user principle and attribute information from within the language of your choice, we've used it successfully with Java, Python and PHP and create a custom login page. So the custom login pages look quite ugly that the identity provider has. So you have to customize login.jsp. So it's something that you'd want to do. And also the error pages as well. So when error messages get strained back, they kind of look quite ugly by default. So you want to give them a bit of a facelift. And then finally, this is what we wanted to extend it to. We would write our own jazz authenticator to talk to our database system. And we write our own attribute resolution plugins as well that sent sort of application specific information back by SAML. You can also control which attributes are released to the individual SP. So you have what's called an attribute filter in your identity provider. So you can actually say, I'm only going to release these particular attributes to these clients or to this URL. So you have a little bit of control over who gets to see what, you're not giving up your crown jewels. If you're integrating with a third party, an untrusted third party, you might only want to have a few key credentials you might say. Yeah, it's quite neat. And then the next step was to set up Shibboleth with Drup PHP and Drupal. So using mod PHP, which I'll talk about in just a sec. Mod WSGI, that's used for Pyramid. And I think mod AJP was what we used for Java. And then finally you map the Shibboleth attributes that are coming back from the identity provider to Drupal roles. And that's what gives you control over who sees what within your Drupal instance itself. So like I said, there's a lot of XML config files. I don't want to sort of go through them all one by one with you. But I'd like you to just come away with an awareness of the core config that you need to have for this thing to actually work. And yeah, if you do want to actually see working config files, I'm happy to share. So this is on the service provider. There's the IDP metadata. So that's generated at install time by the identity provider. So an SP must have access to that. And that's just a file located locally. Metadata SSI Dev is the SP metadata. So when you install an SP, there is metadata created for that SP. And there's the attribute map.xml and that defines the attributes that are released to the SP. So it's like a list of all the attributes that are coming in from the identity provider. The shibboleth2.xml file, which is the main config file for it. And that has things like the URL for the identity, or it actually has the reference to the IDP metadata.xml file, which tells it pretty much where to send them to when they attempt to log in. And then there's an important file called locallogout.html. There's heaps of others, but these are the ones that I found the most, that were sort of the most important ones. So yeah, the IDP config files. Logging.xml, like logging wasn't actually enabled by default. So you're kind of running a bit blind at the start. So make sure you enable logging. Relyingparty.xml. This actually allows you to list out all of the SPs that your IDP is going to support and a reference to where the metadata is located on the identity provider itself. Attribute, I'll mention attribute resolver first, because that allows you to define the attribute resolver plugins that are used. So this could be like an LDAP directory service. Like we had it working with Active Directory, or you can build your own. So we built our own eventually. And the attribute filter allows you to define which attributes are actually released to these service providers. And the login.config file, which tells the identity provider which jazz authentication module to use. And you can actually have multiple authentication modules registered with it, which is kind of neat. So she both. It's a Drupal 7 contributed module. They haven't got any plans yet to port that to Drupal 8, which is a bit unfortunate, but it's a supported Drupal package. Provides an admin interface, so it allows you to actually define the identity provider you want to use. The core attribute, which will be the user principle for the user. And it also allows you to map the attributes that are coming in to the Drupal roles. It redirects the user to the configured IDP when they click on the login link. And yeah, and it actually under the hood, it requires the SP software to be installed, Apache Modship, I'll just jump in here. So I'll just give you a bit of a lay of the land. So this is the identity provider. When you install it, everything lives in slash opt, shibla fi dp. All the config files live in conf. And inside here, we can see those files that I was just talking about. They're relying party.xml, login config attribute, filter attribute resolver. So if we have a look at the attribute resolver, you'll get a bit of an idea of some of the attributes that we're sending back. So we can see here, there's a customer ID, email, title, name, given name, surname, role valid login. So there's quite a few different ones. A lot of it's sort of business specific to us, but you can insert your own business here and you'd have your own attribute related information that you'd want to send back. And finally, down the bottom here, there's a whole heap of these static attributes that I'm sending back. So these are just required by Salesforce. So during the integration project, there was some magic values that needed to be sent back that weren't gonna change user to user. So this is a way that I could define static attributes without having to write my own resolver for it. So look at the filter. My filter is actually quite lazy. It's just basically saying that I'm gonna release all of these attributes to anyone. Although at the very top here, there's an example here of this transient ID. So do not release this transient ID to the attribute request to string equaling this hcpslesmillsdevelop.my.salesforce.com. So that's saying, I don't wanna release this attribute to this particular host. So that was just when we were getting the Salesforce stuff working. So you get used to looking at XML files. It does your head in at the start, but start getting used to it. And you can find your way around it pretty quickly. So we can see here that these are the metadata definitions because this is my dev box. There's a few more than there probably should be. But you can see dub dub dev, SSO dev, Drupal dev. So these are my local ones. Like I said, didn't wanna sort of bore you too much with config files because your eyes will start bleeding. Just some important side notes that I sort of came across during this integration project. Semmel2 or shibboleth I should say doesn't support single logout, which is actually quite important. So when you click on the logout button, it'll sign you out of your current instance, but it won't actually sign you out of all of the other SPs that are there. So there needs to be a bit of a workaround and it's called a chain logout where one logout handler will tell another logout, like it'll redirect to the next login handler. So you end up with a chain of different logout handlers. So it goes sp logout, idp logout, sp logout. And it's a bit weird, but it was just something that I noticed that logout just wasn't really working for me. And I spoke to Scott Cantor, the guy that wrote shibboleth, and he came back to me with a workaround for that. But it can be a bit of a gotcha. The AJP underscore prefix I found had to be added to the actual attributes for them to be passed through to Java. So I found I wasn't getting my attributes through modajp into my Java web applications. So, and that required some small modifications to the Drupal-Shibboleth module as well. So if you intend to integrate Java with it, there's an outstanding bug against the module for this, but that might be something that you run into. The Drupal module only supports Shibboleth 1.3 and 2, not 3.0, which was recently released. It only supports Drupal 6 and 7, not 8. And I went to a Drupal users group meeting back in December in Canberra, and Adam Malone actually ported simple SAML PHP to Drupal 8. So that might be worth considering if you want to evaluate another open source single sign-on technology. So hopefully I've been able to sort of give you a bit of an overview of how we've used single sign-on, and given you a few hints if you want to tackle a similar integration project of your own. Does anyone have any questions? Yeah. Yeah, I know a lot of people that actually use iFrames and stuff to achieve that kind of functionality. Yeah, sure, you could go down that path, I guess. One of the nice things about this is I didn't actually talk about our recent project, which was actually a Salesforce integration where our partners over in Auckland, Les Mills International, actually have a digital music distribution portal in Salesforce. So they have these portal users, and people sign in with their Salesforce credentials, and there's a Magento e-commerce system that sits in front of that. And anyway, as an agency, we have our own e-commerce system, and we want to actually play in this digital download space as well. So we actually, I went over to Auckland, and we actually got Salesforce talking to Shibboleth, so it respects our identity provider. And so that means a user can actually purchase their music through our e-commerce platform and then bounce into Salesforce without entering in their username and password. So that's pure federation. So that's one of the benefits that you get from actually using a standard space single sign-on solution as opposed to an iFrame hope. Cool, any other questions? Great, well, thanks for your time.