
Web Single Sign-On, the SAML 2.0 perspective - guillaumeklaus
https://blog.theodo.com/2019/06/web-single-sign-on-the-saml-2-0-perspective/
======
sk5t
Having worked with SAML, ADFS, etc., in substantial depth, I will opine that
this article doesn't contribute above and beyond the same introductions to the
technology from 10-15 years ago. It's just enough info to get a naive reader
into trouble.

~~~
newusertoday
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?

~~~
jarvuschris
Just do it and see what happens ¯\\_(ツ)_/¯

Most certainly use a library at least for building and parsing messages. All
the complexity is in figuring out how to use your particular library and
figuring out any quirks in the systems your connecting re: what fields and
formats they expect. It's not really something you can read up on and then
know before you start

~~~
zrail
This is 100% my experience as well as a SAML SP. After the first few customers
onboarding largely consisted of certificate exchanges and figuring out where
the IdP put the fields we needed. Before that there was s lot of development
to add those configuration knobs.

------
CaliforniaKarl
Here's a tip for anyone planning on working with customers who are US research
or education institutions: Have one of your Higher Ed customers sponsor you as
an InCommon sponsored partner, and use that to join the InCommon Federation
([https://www.incommon.org/](https://www.incommon.org/))

InCommon is, among other things, a US federation of SAML SPs and IdPs. And
this is one of the interesting things about SAML. Let's say that you are a
Service Provider. Normally, for each customer, you have do at least one
exchange of metadata (as u/victorNicollet mentioned elsewhere in the
comments). If you have multiple SPs (say, a dev and a prod), or the customer
has multiple IdPs (again, a dev and a prod), then you have to do this exchange
multiple times.

An alternative is to join a federation. With a federation, the federation
receives all of the metadata (all of the information about SPs and IdPs), and
you trust the combined metadata the federation provides. And for Service
Providers, there is a separate metadata feed of just IdPs.

What does this get you? It means, if your customer is already part of the
federation, you don't have to exchange metadata with them. At most, they (the
customer) might have to release additional attributes to you, that are not
released by default (phone number, for example).

For InCommon, you can see all of the federation participants here:
[https://www.incommon.org/federation/incommon-federation-
part...](https://www.incommon.org/federation/incommon-federation-
participants/)

Details on the technical side of the process are available here:
[https://spaces.at.internet2.edu/display/InCFederation/How+to...](https://spaces.at.internet2.edu/display/InCFederation/How+to+Get+Started+in+the+InCommon+Federation)

~~~
tingletech
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...](https://spaces.at.internet2.edu/display/InCFederation/Research+and+Scholarship+Category)

------
perlgeek
While this article is very clear, I had hoped (based on the title, I guess)
for some more information:

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?

~~~
victorNicollet
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.

~~~
CaliforniaKarl
>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.

~~~
victorNicollet
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.

~~~
CaliforniaKarl
>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:

[https://uit.stanford.edu/service/saml/arp](https://uit.stanford.edu/service/saml/arp)

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

------
youdontknowtho
New apps should NOT implement SAML.

All platforms support OpenID Connect. It's better in every way. SAML is
effectivly dead from a development standpoint. All the energy from the
standards bodies are focused on OIDC.

~~~
zrail
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.

~~~
youdontknowtho
Literally all of those enterprise SSO systems support OIDC. ADFS, PING, OKTA,
Azure AD, ETC...

~~~
user5994461
SAML has two way authentication and some advanced security stuff. The IDP and
the SP must be registered to one another and can actively sign and verify
their transactions. It is noteworthy for some use cases like AWS or bank
authentication.

Nonetheless, we can all agree that SAML is an order of magnitude more
difficult for no significant benefit. OpenID connect should be largely
preferred.

~~~
mosdl
You can verify transactions in openid as well

~~~
user5994461
openid is a dead protocol that stopped being supported by major websites and
authentication solutions years ago. Not to be confused with openid connect.

------
motohagiography
I've also worked with SAML and OIDC as an architect, and implemented OAuth
(relatively trivially) for websites, and SAML is not a solution that can be
considered naively. The problem SAML solves is if you would like to stand up a
federated IdP, or integrate to an existing federation that uses SAML. If you
don't know what these mean, I'd argue you are blessed, and it's not a problem
you have.

I will say that many enterprise/institutional applications are simple CRUD web
pages with gargantuan iceberged identity management problems that developers
and project managers walk right into. Identity is a basic unanswered business
model question that shouldn't be left to last minute implementation decisions.

If you are building a consumer service today, I don't see why you would bother
having your own password database or authentication scheme when you can just
adopt any of the major platforms as an IdP using OAuth.

Storing passwords today is dumb. I'd argue if you do not want to adopt an IdP
and use their OAuth or OIDC service, stand up a Vault instance and use it for
TOTP secrets for users 2FA apps. They are literally better user experiences
than trying to remember a never-used password.

If you need to do enterprise 2FA, Authy and Google Authenticator and now
Apple's Sign-In and Relay services are great options. Keycloak is another cool
package for handling OAuth and OIDC services as well.

------
unethical_ban
Warning - this site is categorized as malicious by at least one known web
filter.

------
newscracker
This is very short. Almost any other site on SAML would provide the same
information, describing the flows.

For a better foundation, it could be expanded with explanations of signing,
encryption, SLO (single logout), and other aspects.

------
matthewaveryusa
The hardest part of SAML is the bonehead way in which they do signatures -- It
normalizes the data before signing it, and then embeds the signature within
the XML document.

So if you want to verify the authenticity of the identity assertion, you need
to parse the XML, find the node that's being signed, canonicallize the node,
and then finally verify the signature. It's absolutely gross to do and you
need to use (lib)xmlsec1 lest you want to lose your sanity.

~~~
captn3m0
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.

~~~
marcosdumay
XML being the way it is, I don't think there was any alternative to
canonicalization.

~~~
tomjen3
Of the top of my head: embed the XML as a pchar, sign only that; and the
insert the signature as another XML value.

Then you only parse the outside XML, extract the inner value and validate the
signature, then you validate the inner value as-is, so no XML changes will
undo the signature.

~~~
marcosdumay
Ok, you do not need to keep the signature at the same document you are
signing.

But you'll have to canonicalize your XML anyway. There are plenty of security
issues with signing non-canonical XML.

------
mcguire
" _9\. The user can access to its desired resource._ "

This one is fun. In step 1, the "service provider" auth/auth system freezes
the original request and satisfies it in 9. I wrote a Java Servlet filter that
performed this dance ([https://maniagnosis.crsr.net/p/web-
authentication.html](https://maniagnosis.crsr.net/p/web-authentication.html))
many years ago, which may be one of my few pieces of software still in use
(although the guy who took it over may have rewritten it; he doesn't like
other people's software).

------
JadeNB
I guess anyone reading such a technical article already knows this, but I
didn't have even the vaguest clue what SAML _was_ —my first thought was some
dialect of ML—and skimming the article only slightly clarified for me.
According to Wikipedia
([https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language)),
it's the "Security Assertion Markup Language", and the discussion is about
implementations of Single Sign-On.

------
jteppinette
One of the most painful parts of my career was writing a multi-tenant SAML
authentication service in Golang (~3 years ago). _experiencing painful flash
backs_

------
vgetr
It doesn’t.

