Hacker News Reader

Comment by api_or_ipa | Hacker News Reader

Great article. I had to integrate SAML 2.0 in a product not-too-recently and it's absolutely horrible compared to Oauth workflows. Maybe it's the different ecosystem: most IDPs are big, bureaucratic institutions with tons of middlemanagement where OAuth providers tend to be tech orientated players looking to scale their product with minimal friction. Anyways, tons of documentation is outdated, or too light on details or orientated towards management rather than developers.

passport-saml [0] really deserves more love for how (mostly) wonderful it is at making integrating SAML into node applications.

0: https://github.com/bergie/passport-saml

View on HN

As a SAML IdP operator, you're not wrong -- the typical SAML IdP operator is an insitution or a BigCo's internal SSO, while the typical OIDC/OAuth provider is a tech company that runs a data silo -- but consider that SAML IdPs and SPs frequently have to engage in a dialogue to peform an integration, while OAuth 2.0 providers just kind of exist by fiat, and wait for SPs to show up. OIDC evolved from OAuth 2.0 so the UX expectations remain: the SP's operator expects to have to go through some web-based SP registration process provided by the OIDC IdP.

In SAML, the IdP and SP can exchange metadata, but plenty of fly-by-night SPs can't consume it, and need to be configured by hand. Tons of vendors of claim their SP supports SAML, but their implementation was hacked together in someone's basement and doesn't support SAML medadata, is hardcoded to use NameIDs, can't do key rotation, and the like. Some vendors intentionally "simplify" the terminology and translate well-specified SAML terms like "Assertion Consumer Service" to nicer sounding common words, like "login URL", largely obscuring meaning and making any integration an exercise of repeated trial and error.

Garbage IdP software exists too. The SAML specs are very accommodating and offer lots of options, so even among parties that don't flout the text of the standard, the interoperability matrix can be challenging. It's best if your product supports all the options, because the other guy's handmade product probably won't. Then, with attribute release and usage, some vendors ask for email address and use it as a persistent non-reassinable identifier, and some vendors ask for a persistent non-reassingable identifier and if it looks like an email, they'll probably send mail to it. It's frustrating.

Really, because each standard's deployment base, the incentives are different: the typical SAML SP offers a product it wants to sell to an institution or BigCo and the IdP is trying to be careful with its attribute release, while the typical OAuth provider is the data silo itself, full of user data, and SPs want to integrate with it to surface that data in their own application. OIDC then shipped a bunch of standard claims to carry identity info too, but the nature of the typical deployer has hardly changed.

I'm the technical point of contact at a SP. Integrating with enterprise IdPs is awful. Out of over a dozen integrations I've done only a single IdP supports metadata exchange. Most of them don't know what it is. Okta and Onelogin, and other IdPs might support metadata exchange, but they keep it fairly quiet.

Metadata exchange seems sketchy at best. I don't trust any enterprise IT organization to keep their metadata endpoint working.

I've finally got a 'self service' system dialed in where enterprise users can setup their SSO without talking to us at all, and typically they only need to enter a single value into the configuration form - the ACS url. Key rotation is supported, etc, etc.

It is a bloated yucky protocol, but when you just use "SAML The Good Parts" it isn't bad.

As someone who has built and maintains the SAML implementation for an SP it's funny how many of your complaints about bad SPs match my issues with bad IdPs.

Most IdP-as-a-service vendors produce their own metadata, but can't consume SP metadata. They invent their own terminology, make it hard to pass attributes, and rarely offer options around which binding to use.

It's unfortunately all too common to get into a situation where The spec says X and Y are valid. The interoperability profile requires X. But this popular vendor only implements Y, and does it incorrectly.

I'm a SAML consultant. I help IdPs become "good" IdPs, and I help SPs become "good" SPs. Both sides are usually bad in some way or another, and both sides usually want to shift the blame to the other side as soon as they can.

The number of times I've been CC'd on a terse email from one admin to another saying it's the other guys fault after I've clearly told them the list of things on their side that could be causing the issue is pretty much uncountable at this point.

Well most of the software is crap because almost all of them use Shibboleth, where every configuration is stored in ugly XML files and then a reconfiguration means restarting the service with new XML files.

SAML is very used at Government level and because Government likes JavaEE so much, but the libraries/frameworks implementing/offering SAML are pretty garbage

For Shibboleth, the XML configs are unwieldy, but both the IdP and SP are solid and eminently configurable, which is helpful when interfacing with someone else's broken software or odd requirements. In running our Shib IdP, I've had far more trouble with hand-rolled SPs (presumably using found libraries) than I've had with poorly managed Shib SPs. SimpleSAMLphp is comparable, if you're not a Java shop.

Commercial IdP-aaS products have their place, but with their spread, some SPs just code and document how to integrate with the two or three most popular IdP-aas products, and if you're using something else, you're left trying every possible binding, signing, and encryption, until you figure out which one works. Competent SP authors and operators can likely say similar things about various IdPs.

Despite the standards, it's nice if knowledgeable, accommodating people are running capable software on both ends of the exchange, and frustrations will probably increase the further you depart from that ideal.

This is a very helpful writeup,

I'm a SAML implementer and technical point of contact for a SP. I also have the unenviable duty of writing the "how to provision" documentation and doing our tech-rep training.

There are two kinds of IdP, in my experience: Microsoft's Active Directory / Federation Services (AD/FS) and everybody else.

"Everybody else" includes Ping Identity, which seems to be favored by very large companies. We also have a few users of the Computer Associates product and Okta. Other products we haven't seen yet in the wild include the Salesforce.com IdP and Onelogin. (Salesforce is interesting; they allow their instances to be provisioned as IdPs, SPs, or both.)

Almost everybody has been able to furnish Federation Metadata Endpoints to us; nobody has yet asked us for our Federation Metadata Endpoint data, which is good: we don't generate that.

AD/FS is a hassle. Typically of Ballmer-era Microsoft products, they changed the conceptual names of most of the protocol elements in their provisioning screens: they p*ssed on SAML until it smelt like them. So, I rewrote the docs for that IdP in Redmond Creole. Effective.

We have quite a few different AD/FS users; some from their Azure multitenant setup and others from on-premises AD / FS servers. Some multitenant AD/FS implementations provide multiple signing certificates in their federation metadata endpoints. Various Assertion xml-docs from them pick one of the multiple certs.

AD/FS has a convenient feature: its federation metadata is located at a standardized URL: https://federation.example.com/FederationMetadata/2007-06/Fe...

We implemented autoprovisioning, in which we create a profile on our service for any authenticated principal in a SAML Assertion we've never seen before. Some customers really like this as it gets rid of the need for upfront provisioning. But, I sure wish there were a standard deprovisioning protocol.

Chromium and Firefox both have nice SAML Web Extensions that render AuthnRequests and Assertions.

SAML is complicated and insanely hard to troubleshoot. But it's effective and seems (so far) to be secure.

This is my pet peeve with most single sign on providers. Either commercial products/services or bloated "over-engineered" solutions that are hard to customize.

Well. I didn't realize until now that oauth and saml are distinct things.

May I blow your mind? Have a look at https://cilogon.org — that is a service which takes a SAML Assertion, and returns to you either a client certificate or an OAuth authentication.

The link I posted above shows the client-certificate flow. If you want to see the OAuth flow, go here: https://demo.cilogon.org

CILogon is used alot in the Research & Education space. But if you don't have an institutional logon, that's OK, just select 'Google' from the list of providers.

Reply on news.ycombinator.com