5 ms·

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 eco

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 https://github.com/bergie/passport-saml

jtl999 7y ago
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.
ses1984 7y ago
Well. I didn't realize until now that oauth and saml are distinct things.
- CaliforniaKarl 7y ago
  May I blow your mind? Have a look at https://cilogon.org 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 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.
niftich 7y ago
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.
- jacobsenscott 7y ago
  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.
- timv 7y ago
  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.
  - kellenmurphy 7y ago
    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.
- IloveHN84 7y ago
  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

jtl999 7y ago

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.

ses1984 7y ago

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

CaliforniaKarl 7y ago
May I blow your mind? Have a look at https://cilogon.org 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 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.

niftich 7y ago

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.

jacobsenscott 7y ago
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.
timv 7y ago
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.
- kellenmurphy 7y ago
  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.
IloveHN84 7y ago
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