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?
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.