[HN Gopher] A Gentle Introduction to SAML
___________________________________________________________________
A Gentle Introduction to SAML
Author : ned_at_codomain
Score : 139 points
Date : 2024-07-22 17:27 UTC (1 days ago)
(HTM) web link (ssoready.com)
(TXT) w3m dump (ssoready.com)
| ajhenrydev wrote:
| Having worked with implementing SAML for a large University-
| funded application, I learned more than I ever wanted to know but
| less than I needed to know
| cyberpunk wrote:
| This is exactly how it works every time I need to touch SAML.
| Spend two weeks with the ping identity manual, somehow get
| everything working, forget all about it until the next time a
| customer wants it :}
| distortedsignal wrote:
| Ping ID is "SAML" - they actually don't comply with the spec.
| If you remove the Bearer element from the SAMLRequest, you
| should be on your way. Ask me how I know.
| philjohn wrote:
| Ah yes, the dreaded University integration!
|
| I was in charge of a SaaS offering for Academic and Public
| libraries years ago, and we had to add SAML functionality for
| the Academic side ... it was a frustrating few weeks, and I was
| glad when it was over.
| rkeene2 wrote:
| I see this comment often, but when I implemented SAML, the spec
| wasn't too unreadable... I did write my own IdP [0] instead of
| using something that existed though, since those were more
| complicated than I needed.
|
| So maybe because I only implemented features I was using it
| wasn't bad. What did you struggle with?
|
| [0] https://github.com/rkeene/saml-
| idp/blob/master/lib/saml/saml...
| fitzgera1d wrote:
| thank you for this
| ataylor284_ wrote:
| When I had to figure out how to add SAML authentication to a
| custom application, I built a barebones, no-framework Java
| application[1] just to understand the webflow. A good way to
| understand it is to just set up your own IDP like Keycloak
| running locally and play around with it.
|
| [1]: https://github.com/ataylor284/saml-example
| mdavidn wrote:
| If given the option, go with OpenID Connect instead. Both the
| OIDC and SAML standards are overly complex and designed to
| accommodate more use cases and enterprise configurations than
| they should. That said, OIDC is based on OAuth 2 and does not
| depend on XMLDSig. That's a win, in my book. OIDC library support
| is good, and getting basic federated login working for common
| patterns is relatively easy.
| barryrandall wrote:
| Unless your customers are primarily in higher
| education/research, then just take the time to figure out SAML.
| Higher ed collaboration requires eduGAIN, which requires SAML
| (because SAML has mature multilateral federation support).
| high_5 wrote:
| Even higher-ed&research will deploy OpenID federations. The
| spec is WIP: https://openid.net/specs/openid-
| federation-1_0.html
| ratiolat wrote:
| From adminstration and user perspective Oauth (Oauthorization)
| is alot more confusing though.
|
| "Why is google asking me to grant access to my google drive for
| SAAS X, I just want to login to SAAS X via Google"
| mdavidn wrote:
| This sounds like a complaint with Google's implementation,
| not with OAuth in general. The correct scopes should limit
| information sharing to the user's profile. All of the
| security and privacy concerns that necessitate an explicit
| user interaction apply to SAML too.
| eropple wrote:
| Should, but don't. OAuth2/OIDC implementations tend to be
| way more transparent about the asks being made between an
| IdP and SP. It can be confusing. (I agree, however, it's
| the right path.)
| ratiolat wrote:
| That's the thing - authentication capability is basically
| sideeffect of Oauth/OIDC. SAAS x can request whatever they
| want via OIDC and then user can either accept it or decline
| it. This is protocol, not google specific matter. Ask
| ordinary user how they understand what is being asked from
| them when they are trying "to log in" via OIDC/Oauth. With
| SAML it's the other way around - administrator chooses what
| is being sent to SAAS x, user does not need to decide
| anything nor do they get hard to understand prompts.
| rb12345 wrote:
| I'd say the main difference is that OAuth is granting the
| SP the ability to "do stuff" as the original user
| (including reading the user's profile details, as OIDC
| does), as opposed to SAML's approach of just sending
| attributes describing them.
|
| For what it's worth, it is certainly possible for SAML
| SPs to flag that certain attributes should/must be
| released to them via their metadata, but the actual
| release is at the whim of the IdP and its operators. It's
| also possible for a SAML IdP to expose that level of
| detail to its end users and allow them to agree/disagree
| to the attribute release, although I'd be surprised if
| that behaviour was particularly common in practice.
| tptacek wrote:
| The difference between OIDC and OAuth boils down to
| exchanging attribute assertions describing a user as
| opposed to the delegation of a specific set of allowed
| actions, as OAuth was intended to do. OIDC and SAML are
| basically the same thing, with OIDC being a somewhat less
| frightening and more modern protocol.
| mdavidn wrote:
| Reading the user's profile information _is_ the delegated
| action. OAuth providers were already doing this prior to
| OIDC but in incompatible ways. OIDC standardized how that
| information is requested and returned.
| tptacek wrote:
| No, the whole point of OIDC is that permission to read
| your profile is not semantically the same thing as
| authenticated sign-on.
| ataylor284_ wrote:
| I second this. OIDC is much nicer and my experience using it
| with federated identity sources through AWS Cognito was smooth.
| The sad reality is that SAML is already entrenched in many
| enterprise environments and unavoidable.
| christkv wrote:
| We have customers using SAML and ours a pain. At least one or
| two issues a year.
| adeinega wrote:
| I second this.
| ucarion wrote:
| Is anyone going around _choosing_ SAML today, though? XML fever
| has come and gone.
|
| Usually SAML happens because customers ask for it, OIDC isn't
| as widely implemented by IDPs as SAML is, so you end up
| implementing SAML and moving on with life.
| MrDarcy wrote:
| Which IDP's are you speaking of? All major players support
| OIDC now. Google, Apple, Microsoft, Amazon, login.gov.
| adeinega wrote:
| Login.gov is pretty open about its preferences :)
|
| We strongly recommend choosing OpenID Connect (OIDC) over
| SAML due to its modern, API-centric design and support for
| native mobile applications.
|
| https://developers.login.gov/saml/getting-started/
| p_l wrote:
| Amazon also has pretty explicit preference for SAML if you
| want to fine-grain certain things, it's much easier if you
| need to connect AWS to external SSO without going through
| AWS SSO (which, last time I checked, had to be "global"
| thing for whole fleet of accounts, which makes problems
| when you need some sub-accounts to have different SSOs)
| adeinega wrote:
| Where do they say that?
| adeinega wrote:
| https://docs.aws.amazon.com/cognito/latest/developerguide
| /ex... tells me they support these IDPs 1. Facebook 2.
| Login with Amazon 3. Google 4. Sign in with Apple 5. Open
| ID Connect providers, and finally 6. SAML identity
| providers
|
| If we look a bit closer, we notice that the first four
| use OpenID Connect under the hood. These names are fancy
| names for OpenID Connect with a little bit of something
| extra on top from Apple, Google, and so forth.
| p_l wrote:
| AWS SSO, ASS Cognito, and SSO (SAML/OIDC) integration in
| AWS IAM/STS are all three different things, with separate
| behaviours, problems, typical Amazon undocumented
| pitfalls, etc.
| p_l wrote:
| They say this in how you simply are limited in what you
| can pass and control when using OIDC Vs SAML.
|
| SSO -> token that works only for specific role, where the
| specific user is supposed to be able to take many roles,
| is very hard to do with OIDC unless you can mangle OIDC
| tokens properly, whereas it's way simpler to do with SAML
| adeinega wrote:
| I'd love to read about that more if you can share links
| explaining those details.
|
| Whatever you've described sounds more like internal
| problems / challenges of their own implementations than
| anything else... especially the OpenID Connect as a
| delegated authentication protocol itself.
| distortedsignal wrote:
| I'm curious - what is the issue with XMLDSig? I think XML is
| kind of a mess with the whole "billion laughs" attack, but
| other than that, are there problems with DSig that I don't know
| about?
| koolba wrote:
| > what is the issue with XMLDSig?
|
| There's a wealth of issues, some generic and some specific to
| the (not so well thought out...) choices made by the SAML
| spec.
|
| For starters, the XML signature spec requires
| canonicalization of the message (which is XML). But the
| message itself need not be the canonicalized message. So the
| SAML implementer, if they follow the spec, must process the
| untrusted input and canonicalize it prior to verifying the
| signature.
|
| Add in that you can override just about every aspect of the
| signature algorithm, canonicalization details, and even what
| parts of the message are actually signed, and you get huge
| number of places where things can either go wrong or may be
| overlooked.
|
| Then throw in "XML Encryption" (again with canonicalization)
| which could be done on the whole message or just the
| assertions.
|
| Then throw in that you can sign the encrypted portion, or the
| unencrypted portion, or just the assertions, or encrypt the
| signatures, or ...
|
| So in short, there's too many ways to do too many thing.
|
| Which leads to a massive surface area of code if you actually
| follow the spec. Which leads to libraries that either do not
| follow the spec (e.g., ignoring encryption and just checking
| signatures in a known location), or think that they follow
| the spec but will happily ignore missing assertions or out of
| date certificates.
|
| SAML sucks. But hey, it's still better than having your own
| passwords!
| tptacek wrote:
| There's also detached signatures and flexible tag matching,
| which lead to implementations that have provide rigid
| schemas with semantic passes to make sure there's no place
| to smuggle either additional signed content to confuse
| verifiers, or content that will get signed that changes the
| message semantics. The whole thing is deeply unsound. OIDC
| is no great shakes, but even 10 years ago nobody would ever
| design a signed message scheme that looked like SAML.
| rb12345 wrote:
| Outdated certificates are actually fine with regards to
| SAML, oddly enough; the logic being that the trust is
| handled out of band at metadata level, and the certificate
| is just a public-key distribution method. (That applies to
| Shibboleth at least; other implementations may disagree.)
| This does of course assume that you have a means of safely
| keeping metadata for the other end of the trust
| relationship up to date. In an eduGAIN/local federation
| setting, that's easy enough to do with signed XML metadata
| feeds and daily fetches, but far less so for bilateral
| trust.
|
| The XMLDSig stuff is definitely a mess though. There were
| definitely issues with comments in signed content allowing
| values to be truncated to the start of the comment, along
| with some similar weirdness with XML entities. And that's
| before any of your (entirely valid!) complaints...
| mdavidn wrote:
| In addition to reasons shared by other commenters, my main
| concern is XML Signature Wrapping.
|
| XMLDSig APIs are not well designed. They check whether
| signatures in a document are valid, but signatures are not
| required to cover the entire document. XMLDSig APIs do not
| make it easy to confirm that signatures cover a specific
| element of interest, like saml:Subject.
|
| An adversary can stuff a valid assertion within a forged one,
| and many popular SAML implementations would accept the forged
| assertion. This is mostly fixed now, but it's still one of
| those things that I must validate for myself in all new SAML
| service providers that I can influence.
|
| https://www.usenix.org/system/files/conference/usenixsecurit.
| ..
|
| https://arxiv.org/pdf/2106.10460
| 7bit wrote:
| While designed to accommodate many use-cases (which ist Not a
| bad thing), I'm curious what you seem overly complex? They're
| both pretty straight forward (except for single logout in SAML,
| which was never truly resolved and just left to die)
| tptacek wrote:
| XML-DSIG is probably one of the 3 worst cryptosystems ever
| designed (don't ask me what the other two are, I'm just sure
| XML-DSIG is one of them) and the system is so complicated
| that a huge percentage of the deployed base of SAML systems,
| regardless of their language and library choices, backend
| onto the same ancient libxmlsec codebase.
|
| If I could avoid doing SAML (we have so far!), I would avoid
| doing so as long as I could.
| ucarion wrote:
| Agreed. XML Signatures is the worst part of SAML. It's a
| spec that's basically begging to be done wrong. I remain
| confused as to what W3C were thinking.
|
| https://ssoready.com/blog/engineering/xml-dsig-is-
| unfortunat...
| tptacek wrote:
| SAML literally predates most modern cryptography,
| including basic notions like the inseparability of
| encryption and authentication. It's a backwater that
| until relatively recently was confined to clanking
| enterprise deployments, and OIDC means it will never be
| modernized; the "next modernizing step" would be to
| simply turn it into OIDC.
| 7bit wrote:
| While designed to accommodate many use-cases (which ist Not a
| bad thing), I'm curious what you seem overly complex? They're
| both pretty straight forward (except for single logout in SAML,
| which was never truly resolved and just left to die)
| seandoe wrote:
| What about for an idp-initiated flow? Last time I checked on
| this SAML was the more logical choice.
| mdavidn wrote:
| The "OIDC way" would be an endpoint on the service provider
| ("relying party" in the spec) that immediately redirects into
| authentication. The spec does have a section describing this.
|
| https://openid.net/specs/openid-connect-
| core-1_0.html#ThirdP...
| zerkten wrote:
| Having dealt with the operational side of SAML implementations,
| as well as implementation of the spec, it would be nice if tools
| like this generated docs for customer setup that are app
| specific. This would go from initial setup to certificate updates
| to configuring custom attributes supported by the SP.
| unilynx wrote:
| One advantage of SAML over OIDC - they standardized IDP initiated
| login, so you can skip the "login using..." button when sending
| an already logged in user to a third party system.
|
| But the various XML canonicalization specs, XML transforms,
| embedding X509 certificates, all the mess they created to be able
| to embed signatures inside XML messages instead of just sending
| them separate from the assertions, is horrible to get right and
| will be a source of more security bugs for many, many years to
| come. https://www.google.com/search?q=canonicalization+CVE+SAML
| deathanatos wrote:
| > _One advantage of SAML over OIDC - they standardized IDP
| initiated login, so you can skip the "login using..." button
| when sending an already logged in user to a third party
| system._
|
| OIDC supports this, though it is an optional part of the
| standard. This is the initiate_login_uri metadata on a relying
| party. https://openid.net/specs/openid-connect-
| core-1_0.html#ThirdP...
| OliverJones wrote:
| FWIW, the XML signature stuff in dot net just works. Once you
| get dot net's XML stuff itself working.
| denysvitali wrote:
| I still can't find a convincing reason to use SAML over OIDC.
|
| To me the SAML vs OIDC difference looks (also for the exchange
| format) pretty similar to the situations where XML vs JSON is
| used.
|
| That is, I've always seen SAML as being very old / enterprise,
| and OIDC being the breath of fresh air that is JSON compared to
| XML.
|
| I'd love to be proven wrong and start seeing SAML under a
| different lens as I don't currently see any benefit in starting a
| new project thst supports SAML
| ned_at_codomain wrote:
| Just speaking practically, the biggest reason to support SAML
| is that customers use it.
|
| _Tons_ of companies still use old school Active Directory for
| SAML -- and aren 't even quite ready to migrate to Entra
| (formerly Azure Active Directory).
| denysvitali wrote:
| This only supports my point of considering SAML as being
| "ancient" - but I just don't know if it's true.
|
| It's just a feeling seeing it mostly in banks and other old-
| school enterprises (AD plays a huge role here as you
| mentioned)
| scott_w wrote:
| Not even close. Pretty much every enterprise uses it
| because, from an admin point of view, it does everything
| the customer wants. Centralised user management is pretty
| much mandatory for different compliance and AD and Okta
| meet those needs just fine.
|
| Hell, from a user perspective, I don't even hate the Okta
| SAML implementation now we have support for Yubikey
| enabled. Click a button, I'm in.
| muhehe wrote:
| I certainly won't defend saml (it does suck), but saying oidc
| is a breath of a fresh air seems like an overstatement :).
| barryrandall wrote:
| Multilateral federation is SAML's killer app, and why higher
| education still uses it instead of OIDC.
| adeinega wrote:
| I hope there will be some changes on that soon, have a look
| at https://openid.net/specs/openid-federation-1_0.html.
| high_5 wrote:
| Ha, just found out you already posted the spec. Still, even
| if it gets published, IMO multilateral federations will
| migrate veeeery sloooooowly.
| EvanAnderson wrote:
| A minor mistake: You say "An identity provider (ISP): the
| centralized service your user will use to authenticate". You mean
| "IDP", not "ISP".
|
| (That happens to me w/ using uncommon initialisms that are one
| letter off from the ones I use more commonly. My muscle memory
| inevitably makes me type some fraction of the more common one
| even when I mean otherwise.)
| ned_at_codomain wrote:
| Thanks, Evan! Fixed
| coronapl wrote:
| I'm glad this company is building an open-source and
| straightforward solution for SAML integration. I struggled to
| find the right solution for my product and tried multiple
| libraries and services, including AWS Cognito.
|
| Diving deep into OAuth and OIDC was crucial. Lesson learned:
| stick to the basics.
| ned_at_codomain wrote:
| Glad the project seems useful to you :)
|
| Any chance you'd share what went wrong with the other
| libraries/services? Curious to hear what mistakes we should
| avoid.
| coronapl wrote:
| Sure! I think Cognito is a decent solution. However, client-
| app integration can be tricky, and the documentation is quite
| ambiguous in my opinion. The recommended implementation
| option is Amplify, but I had concerns because it doesn't
| support HTTP-only cookies.
|
| I also experimented with NextAuth.js, but its documentation
| wasn't great, possibly because they're working on a new major
| version. I struggled particularly with supporting multi-
| tenancy with Microsoft AD.
|
| I noticed that you offer SAML over OAuth. I'm curious to try
| that out.
| ned_at_codomain wrote:
| Yeah, we made SAML over OAuth available mainly for ease of
| use in NextJS. Drop me a note (email in HN bio)if you end
| up trying us out. Would love to see whether we're on the
| right track.
| DemocracyFTW2 wrote:
| I have no idea what I'm talking about but the comments in this
| thread have fully convinced me that this is a preferable state of
| affairs
| adeinega wrote:
| "SAML isn't a recipient for innovations" or something along this
| line was once said by Vittorio Bertocci... it's hard to add much
| to it.
|
| OpenID Connect is a core for many new specs in the space, "OpenID
| for Verifiable Presentations" and "OpenID for Verifiable
| Credentials" just to name a few.
|
| Any new company choosing one vs another, I suggest to take into
| account this aspect.
| Biganon wrote:
| In an app that's accessed through HTTPS only, is it enough to
| ensure the Assertions are signed?
|
| I'm using the "WantAssertionsSigned" policy only and I'm
| wondering if it's secure or not
| ucarion wrote:
| It's hard to answer questions like this in the abstract. The
| details matter.
___________________________________________________________________
(page generated 2024-07-23 23:05 UTC)