3 ms·

The article provides examples of the IDP providing using different _IDP identities_ but I couldn't find an example of it suggesting different _user identities_.

by lvh 7y ago

The article provides examples of the IDP providing using different _IDP identities_ but I couldn't find an example of it suggesting different _user identities_. The problem is the SAML assertion is effectively a bearer token, which is fine if it's specific to a service, and not fine if it can be replayed. If you want to unmix "authentication and authorization" as you put it, you're going to need a way to bind that credential further. You can either do that with some unspecified scheme that nobody implements, or you can do that by just using per-SP keys as the article suggests. What do you propose we do instead?

matthewaveryusa 7y ago
Use a custom scheme because odds are if you're doing things right you'll need a good revocation story which SAML doesn't provide.
- lvh 7y ago
  The use case in the article is enterprise login to a bunch of services. It's hard enough to get them to do SSO, you can't seriously suggest you're going to get them to implement bespoke schemes?
  - matthewaveryusa 7y ago
    I don't disagree with you that it's a crappy situation. A lot of SaaS providers ldap/AD sync so you can authz off of groups and do automatic revocation. Enterprise integrations suck exactly because of these kinds of things. while adding a key per SP may get you further down the authz path, it doesn't solve the revocation part and also doesn't provide a way to do more advanced authz -- The natural evolution of an app that will authorize access to a subset of users will be to add roles for users, giving them different privileges, and then you're back to a custom authz protocol.
NovemberWhiskey 7y ago
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.
- lvh 7y ago
  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?
  - NovemberWhiskey 7y 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".
    - johnmaguire2013 7y 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.
    - lvh 7y 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.)

by lvh 7y ago

matthewaveryusa 7y ago

Use a custom scheme because odds are if you're doing things right you'll need a good revocation story which SAML doesn't provide.

lvh 7y ago
The use case in the article is enterprise login to a bunch of services. It's hard enough to get them to do SSO, you can't seriously suggest you're going to get them to implement bespoke schemes?
- matthewaveryusa 7y ago
  I don't disagree with you that it's a crappy situation. A lot of SaaS providers ldap/AD sync so you can authz off of groups and do automatic revocation. Enterprise integrations suck exactly because of these kinds of things. while adding a key per SP may get you further down the authz path, it doesn't solve the revocation part and also doesn't provide a way to do more advanced authz -- The natural evolution of an app that will authorize access to a subset of users will be to add roles for users, giving them different privileges, and then you're back to a custom authz protocol.

NovemberWhiskey 7y ago

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.

lvh 7y ago
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?
- NovemberWhiskey 7y 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".
  - johnmaguire2013 7y 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.
  - lvh 7y 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.)