It depends on whether there are libraries available and how simple they are to use. The spring security SAML plugin is an absolute nightmare to integrate. A basic configuration requires 600 mostly redundant lines of which you probably copy paste 400 from the example project.
I've had a completely different experience with Grails which is a web framework for Groovy that is based on spring boot. It's plugins are usually just a thin wrapper over the actual spring libraries but they take care of those 600 lines and the end result is that you need to write slightly less than 50 lines of configuration in a YAML file.
Basically it can be hell or heaven depending on your language's ecosystem.
> Grails which is a web framework for Groovy that is based on spring boot. It's plugins
I thought Grails uses Spring Boot only from 3 onwards, and only versions up to Grails 2.x have a plugin ecosystem. Virtually no-one has upgraded their apps and plugins since Grails 3 came out in early 2015, and no-one's started new projects in Grails since then. To mention Spring Boot and Grails Plugins in the same statement is misleading.
>Virtually no-one has upgraded their apps and plugins...
I'll let the gripe about plugins pass because I think it's a bad metric for measuring how popular a framework is. How many of the plugins from 1.x and 2.x are even relevant anymore?
>...and no-one's started new projects
This is a ridiculous claim. It's just spreading FUD.
If one is targeting any SAML compliant IdP, then this would be very hard and painful unless the developer chooses to use a mature library that preferably provides high level APIs to handle the request generation and response handling.
> How about setting up an identify provider in dev?
The easiest way is to not setup one in dev by oneself, but use free instances (potentially unstable at times) provided by the likes of Okta (okta.com) and other cloud based services.
I've written a simple SAML IdP[0] which could be used for development purposes -- it's overall not too complex to deal with.
Maybe I should release this whole thing so people could have a simple SAML server for testing... though I'd probably switch to a better XML parser ! :-)
[0] http://www.rkeene.org/viewer/tmp/tcl-saml.tcl.htm (there's a web front-end that goes in front of this package to take the HTTP request turn it into the appropriate username and call this library).
Agreed, coding "from scratch" to use a SAML IdP would be painful for a typical developer, who thus far mainly has experience using Web/app frameworks. And, as with much software development, it's easy to introduce vulnerabilities. Use off-the-shelf, if you can.
That said, I've had to implement several SSO protocols "from scratch" (using off-the-shelf libraries for HTTPS, XML, and crypto) for a large Web system, including at least a couple different SAML IdP variants. There was a lot of figuring things out, and being very careful, and it was difficult but useful experience.
(The SAML IdP uses were reasonable for authentication, and simply worked. Where I saw trouble was when cleanroom implementing client side of some of the non-standard SSO protocols used by some large companies. Every time I discovered a security problem with a customer's protocol design/implementation, I had to go to the director I was working with (fortunately, a very smart engineering PhD, who took it seriously), then he had to explain to the customer. Presumably there were historical and/or requirements reasons for doing a non-standard protocol, but security is hard, and every programmer changing the code is potentially a weak link.)
Quite well, once you get path the teething pains of finding out how the various components you're using understand the standard. In practice, it's very similar to whatever Google, Github, and Facebook use for their federated authentication. (Very similar.)
We didn't use the authorization, and I wasn't involved in picking or setting up the IdP(s). But once you have one working, it's relatively simple to slap in front of all of your apps.
This is down to quality of implementation. Is your IdP any good? Do you have good management practices around access control? Do your applications check authorization properly?
> How does the authorization part work?
Role information is passed to applications. It is the responsibility of applications to check authorization, in whichever way the developers of each application see fit.
I hope this helps! Please don't hesitate to ask if you have further questions.
I'm saying all of this as the CTO of a B2B service that accepts SAML for authentication.
> How well does it actually work in practice?
For authentication, pretty well. No downtimes observed on Google, Microsoft or customer-owned IdPs over the last 4 years of using SAML in production.
The customer's IT can easily provide you all the necessary data about their IdP as a standard format metadata.xml file. In return, you give them two URLs (your entityId and your ACS endpoint).
In case of IdP certificate change (once every few years unless something happens), they just send you ahead of time a new metadata.xml containing both old and new certificates, so you don't have to be there with you finger on the button to change the certificate on your side.
The only complex thing is whether any user that comes you way should have an associated user profile created in your application (i.e. any employee in your customer's directory is one of your users by default) or if you deny access to users that have not been manually registered in your application by the customer's admins.
> How does the authorization part work?
Not as elegantly as authentication. You need the IdP to provide you with additional information, such as roles. Not all IdPs can do this properly. Then, you need to manage your own mapping from that information to actual authorization info. Also, since you only get data from the IdP once (as part of the identity assertion), you won't have the granularity to provide per-resource access control.
In the end, we've found it far easier to use SAML only for authentication, and to implement an RBAC on our side, based on the identity of the users.
> How easy/hard is it for a developer? How about setting up an identify provider in dev?
Mature libraries exist for all major languages to deal with the crypto part, and the SAML protocol itself is trivial in terms of HTTP (redirect user to appropriate page on the IdP, receive a crypto-signed identity assertion on your ACS endpoint). It took me 3 days to go from zero to fully implemented and tested, in C#, and with extensive logging to detect sign-in issues.
Whenever possible, use the email as the user identifier. You can manage with any other kind of identifier, but debugging is significantly easier, since you don't have access to the customer's IdP to know the correspondance between an actual user and its opaque identifier.
Another important tip: even if you have a strong ownership between a customer and a customer subscription, some employees of your customer may need to access several customer subscriptions (for example Wrike project management: you can use it internally, and also participate as external contributors in projects from other companies) so you need to either allow an user account to access several customer subscriptions (likely hard) or allow a single SAML login to connect to several user accounts in several customer subscriptions. With email + password this could be worked around by using mail aliases (e.g. victor+companyA@example.com, victor+companyB@example.com) but with SAML you are limited to only one identity, so if you don't allow multi-user SAML, you end up in a situation like Wrike (again) where we actively discourage our customers from using Wrike internally because we want their employees to connect to our Wrike subscription...
Setting up an IdP... depends on how much you want to dogfood. If you have Office 365 or Google Suite, you already have an IdP that you can use easily to connect to your own system. I used Salesforce, which has a "free" level.
>Whenever possible, use the email as the user identifier. You can manage with any other kind of identifier, but debugging is significantly easier, since you don't have access to the customer's IdP to know the correspondance between an actual user and its opaque identifier.
This is an assumption that a number of service providers run in to when setting up a SAML relationship with Stanford’s IdP: Not every Stanford person has a published email address. In particular, people who have been sponsored for accounts (in order to log in to Stanford systems) don’t have their email address published (we don’t have their permission to do so).
Email addresses can also change.
As was mentioned, there are opaque identifiers that uniquely identify someone and that do not change. We also provide the person’s SUNetID (their Stanford username), even if there is no email address.
I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ?
On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace.
>I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ?
Yup. For those curious, you can find Stanford's list of released-by-default attributes here:
>On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace.
Yup, totally agree, and that's one of the annoying things about SAML. In Stanford's case, that's the eduPersonPrincipalName attribute.
> Whenever possible, use the email as the user identifier. You can manage with any other kind of identifier, but debugging is significantly easier, since you don't have access to the customer's IdP to know the correspondance between an actual user and its opaque identifier.
This isn't a great idea, things like email get recycled fairly frequently. Some systems also let people change their email, for example, it's not uncommon for an email to change when someone gets married or for an email to get recycled when an employee leaves a company.
> In the end, we've found it far easier to use SAML only for authentication, and to implement an RBAC on our side, based on the identity of the users.
This I 100% agree with, standardizing basic attributes is hard enough.
The main things to remember about certificate rollover from experience are:
- Publish the signing certificates ahead of time in the metadata before using them.
- Install any new encryption certificates on your service (supporting old and new certificates) before publishing the certificates in the service metadata.
In terms of SAML testing, https://samltest.id/ is useful for short-term testing of both IdPs and SPs.
How well does it actually work in practice?
How does the authorization part work?
How easy/hard is it for a developer? How about setting up an identify provider in dev?