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.