undefined | Better HN

0 pointsNovemberWhiskey6y ago0 comments

If your SP supports it, you use SAML attribute assertions to model group/role memberships and only grant access to users in the appropriate groups.

Or you have your IDP (say ADFS) only permit issuance for authorization requests which are appropriate, again by reference to (say) AD group memberships.

If your SP doesn't even validate the audience for the assertions, then you're definitely going to be in a bad place - but the question there is "how do I limit the damage this braindead SAML implementation can do to my enterprise and how do I make sure I never buy software broken like this again?" rather than a screed suggesting authentication and authorization are the same thing.

0 comments

4 comments · 1 top-level

lvh6y ago· 3 in thread

Are you suggesting that there are "levels of broken" here, where an application that doesn't do audience validation will almost certainly screw up group membership assertion?

NovemberWhiskeyOP6y ago

My experience is that many vendors will happily say "SAML 2.0 integration for SSO" when they mean only that they can pick a username out of an identity assertion. I personally haven't seen one which mismanages audience validation.

Above and beyond that, support is tremendously variable. Ability to do JIT provisioning/re-provisioning with user roles etc mapped to attribute assertions is something like nirvana and about as commonly realized.

"SSO once you have pre-provisioned the user out-of-band via our application-specific API" is more common (bonus marks for SCIM). Also "SSO assuming you can provide access to an LDAP server where we can look the user up".

lvh6y ago

OK, but my question was specific. You appeared to hint that anything that doesn't do audience validation is so horribly broken that it's unusable. That's not only very different from my experience (audience confusion, and particularly domain confusion bugs are super common), and I think there's a good reason for that. If your integration claims to be able to consume group assertions but it doesn't, that will be immediately visible to anyone trying the integration. If you screw up audience validation, no-one will notice until they perform a very specific test that the vast majority of vendorsec programs will never test for, and a good chunk of the ones that do will have signed a contract that prevents them from testing or at least publishing findings.

(Completely agreed that the vast majority of SSO integrations only let the IdP assert identities, not group memberships.)

radlad6y ago

More to the point - while signing certs are part of the SAML spec (and your IdP can choose to use a different one for each SP), looking at attributes in the Assertion and making decisions based off of them is one-off for every SP - a few do this, but they each do it differently than the last.

j / k navigate · click thread line to collapse