
Beer Drinkers Guide to SAML - dedalus
https://duo.com/blog/the-beer-drinkers-guide-to-saml
======
lvh
The biggest problem with SAML is probably XML-DSig. The spec is ridiculously
complex, but unfortunately the implementations are no better. You're de facto
either using libxmlsec1 or the Java stdlib. libxmlsec1 is (anecdotally) a
terrifying mess of C that most SAML integration libraries desperately want you
to run in-process with your server.

There's a totally palatable mini-SAML within SAML waiting to come out. It
already exists informally: it's whatever GSuite and Okta's default
metadata.xml will give you, and it summarizes to "one signature, on the
outside, no encryption".

You kind of need to do SAML, though, unless you don't care about selling to
companies at all. Smaller companies may or may not be able to do OIDC, but
pretty much everyone can do SAML. You just want to have someone else be
responsible for the SAML laundromat part (that is: ingesting gross SAML from
the Internet and translating it to a friendly consistent format, which doesn't
necessarily have to be SAML too). For all its flaws, Cognito fits that bill,
as does Okta.

~~~
zeveb
> The biggest problem with SAML is probably XML-DSig.

I hope that I live long enough to read the book-length historical treatment of
the late 90s/early-2000s obsession with XML. My personal opinion is that it
set the industry back by a decade. It just blows my mind the amount of effort
(time & money) which was poured into such a flawed architecture.

Ditto Java, really. The early-2000s vision was one great mass of Java & XML.
Why we didn't stick with Lisp & S-expressions I'll never know.

~~~
lvh
I'm a lisper and dislike XML as much as the next guy, but XML-DSig seems like
a fundamental mistake and sexp-dsig would not have been a better spec. All of
the problems you get from in-band signing and encryption are still there--case
in point, our blog post on how not to sign a JSON object[0] would be a fine
spike on a blog post about why XML-DSig is bananas.

(One counterexample I can think of: you probably wouldn't do CDATA and
comments the same way as XML did, which led to Kelby Ludwig's fantastic SAML
auth bypass--which also gets a review in that blog post.)

[0]: [https://latacora.micro.blog/2019/07/24/how-not-
to.html](https://latacora.micro.blog/2019/07/24/how-not-to.html)

------
mirekrusin
Great article but if I wanted to explain it to somebody in one sentence I'd
say "It's like sign-in with google, but for enterprises", by "enterprises" i
mean "more shit" \- xml/soap/overcomplicated kind of shit.

~~~
sascha_sl
as the resident keeper of the keycloak (aka RedHat SSO) which can and does do
both SAML and OIDC (what google uses) in our organization I only sort of
agree. SAML is overcomplicated, but OIDC also has a lot of bloat, although
it's more optional there. It's just trying to solve too many problems for too
many parties at once. Back and front channel logout, your choice of symmetric
or asymmetric crypto, at least 3 types of different tokens, and 3 ways to get
subsets of them with various subtypes, depending on if you're a client
application, a web application that can redirect, a web application that can't
redirect, an app on a TV... Oh, and did I tell you about the authorization
framework? With assessment servers? There's that too!

Thankfully in the real world both seem to be implemented in the absolute
minimal way to get things working.

~~~
Edmond
Cheers for keycloak, title pun intended :)

We use it for Solvent ([https://codesolvent.com](https://codesolvent.com))
login to product instances and it works excellently.

~~~
i_haz_rabies
How have you guys solved "from scratch" configuration for keycloak? I've
worked with it a bit over the years and I've never found a way to get it into
a state I want programmatically without hacky bash scripts and modifying the
json templates.

~~~
Edmond
Maybe we got lucky with the configuration but we use the approach documented
for the keycloak-saml-adapter with Jetty as the app server.

There is still a lot work done to ensure keys are generated in the proper
locations and that necessary product id values (corresponds to SAML SP
entityID) are generated.

In short, it is not a simple plug-n-play, lots of hacking to get the result we
needed but the adapter itself does what it needs to do.

------
bouke
What use does SAML still hold with the advent of OIDC? When building
enterprise software, should I bother implementing SAML or is OIDC support
commonplace?

~~~
levi-turner
Anecdotal from my experience in Presales selling Enterprise software. Out of
10 enterprise segment customers: \- 8/9 would prefer SAML \- 2/3 have a
compliant IdP which supports OIDC (ADFS needs to be v4.0 therefore run on
Windows Server 2016+)

You'd be a fool to only focus on OIDC, at least for the next few years. As
Azure gobbles up the Enterprise segment, Azure AD can be used to provide OIDC
which will be nice. Though most admins who we work with are far more
comfortable with SAML.

To be completely honest, the major of customers who are primarily interested
in OIDC are coming from Google and/or GCP shops (which are few and far
between).

~~~
wil421
In my experience with enterprise SASS products they mostly use SAML and most
companies I work for use it. At the time I was trying to switch to OAuth or
OpenID but the support was severely lacking for off the shelf enterprise
software, especially older stuff. ForgeRock was also giving the identity
management team issues so SAML was the only option.

------
megadrive
Thanks, this article made understanding the basics a lot clearer than other
things I found recently when looking. I haven't had to configure an IdP or SP
[yet] but application we work with does use SAML to authenticate, and I only
have to make small configuration to that application side. Good to have a
better, albeit very basic, understanding at least of what the Shibboleth IdP
and SP are doing.

------
m1keil
I wish that SAML would stop being referenced as Enterprise oriented and that
some SPs would stop providing support for it only in their highest payment
tiers. As every company nowadays have G Suite or something similar, they
almost certainly have an Idp ready.

~~~
wraithm112
It's the only thing that most SaaS things charge for now-a-days. Slack,
Dropbox, Github Enterprise, etc. They know that regulated businesses have
requirements to have SSO and things like this, so they can charge out the nose
for it. You can go for a very long time with paying little to nothing for most
of these services until you need SSO.

------
trey-jones
Did something happen to Alice? Who is Stu? I have so many questions.

~~~
floatrock
Bob enjoys Beer, Stu is a Software User who enjoys Salesforce.

Alice is just absent today.

------
SubiculumCode
SAML is not that common an acronym. Would it have killed to start out with a
definition?

~~~
forgot-my-pw
It's in the 3rd paragraph:

Simply put, Security Assertion Markup Language (better known as its acronym,
SAML) is a protocol for authenticating to web applications. Federating
identities is a common practice that amounts to having user identities stored
across discrete applications and organizations. SAML allows these federated
apps and organizations to communicate and trust one another’s users.

~~~
commandlinefan
It's also an incredibly common acronym.

~~~
SubiculumCode
I have been a computer nerd (now a neuroscience scientist nerd) for decades. I
didn't know SAML.

