Web Single Sign-On, the SAML 2.0 perspective

Do you have any suggestions for the best practices for implementing SAML? or any other blogs that you recommend which would cover this area in depth?

Sadly, a large percentage of printed books are just as devoid of meaningful content. At least we only paid for this one with our time.

To expand on this from a non-US perspective, the advice to join a federation also applies to working with universities elsewhere. Having joined one federation (e.g. InCommon or the UK Access Management Federation (https://www.ukfederation.org.uk/)), you can then get your metadata published in eduGAIN (https://edugain.org/) for institutions elsewhere in the world to use.

Other things to note from a HE perspective:

- Most potential users will likely be using Shibboleth as an IdP, as opposed to ADFS, Ping Federate, Okta and the like. This means that using federation-supplied metadata is far easer to work with than setting up per-SP metadata manually. (In ADFS at least, all the relying party setup is fairly manual, although Powershell can make this slightly less painful.)

- The admins running the IdP will most likely not not be the people buying or using the services provided by an SP. This can complicate setting up SAML integrations.

- SPs should try to support standard LDAP attribute schemas like the eduPerson (https://wiki.refeds.org/display/STAN/eduPerson) schema. These are likely to appear as "urn:oid:..." attributes in the SAML assertion. My personal suggestion for mixed HE/enterprise SPs would be to map both the eduPerson URNs and the equivalent ADFS claim identifiers to one internal identifier.

- As noted elsewhere, email addresses as identifiers are problematic in the general case: people change names, people change departments, and people may have multiple email addresses. The eduPersonPrincipalName attribute is generally more stable and is still non-opaque.

I literally have nightmares about shibboleth and InCommon. My university system has at least 11 IdPs (I think some of the medical centers have their own, but my apps aren't used by medical centers generally). Even with InCommon, I had to negotiate attribute release with every IdP to get email and eppn. Even after filling out the forms that went through a systemwide identity committee, I had to cold call half the campus identity management groups to get the attributes. To even get my metadata into InCommon, I had practically camp out in front of some dudes office because I could not get email or phone calls returned. But, I was getting it set up before the Research and Scholarship category came out. If you can get your app/SP approved, and your target IdPs support it, the attributes are pre-negotiated.

Plus the software was a PITA too.

I'm trying to get a "bridge" set up so I can have one SP in R&S that supports OIDC, that way when I do a new app I can just have the app use open id connect and not have to deal with shibboleth.

Research and Scholarship Category https://spaces.at.internet2.edu/display/InCFederation/Resear...

> How easy/hard is it for a developer?

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.

> How well does it actually work in practice?

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.

"How well does it actually work in practice?"

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.

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.

Disagree. Enterprise customers have SAML SSO deployed and want to use it. If you want to serve those customers at any sort of scale you need to implement SAML.

I implemented XML Signatures at our org for Payments Interface (MPI) with Card Networks and there is a part of my brain that will forever curse me for reading the XMLDSig spec.

How anyone ever thought XML Canonicalization was the right answer is beyond me.