5 ms·

If your IDP is providing identity, does it matter who the audience is? presumably the contract is "if this blob is signed with this certificate, then the identi

If your IDP is providing identity, does it matter who the audience is? presumably the contract is "if this blob is signed with this certificate, then the identity encoded in the blob is the user's identity" because the SP was configured to only trust a certain certificate for identity. What the article is saying is a bit nuanced in that the IDP can theoretically provide a different user identity for each service, but in reality, does that really happen? Seems like if you're doing that you're starting to mix authentication with authorization. The picture in the article that says that the idp provides the answer to "login to cat", "log in to to payroll" is wrong imho. the IDP is providing the answer "username is X", and that's it.

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.
      - 7y ago
johnmaguire2013 7y ago
It is common for an IdP to apply specific policies and controls dependent on which service provider the user is authenticating to. The IdP is specifically saying "user X has access to application Y." That is why the Audience is a (required) component of a SAML Response.
rb12345 7y ago
> What the article is saying is a bit nuanced in that the IDP can theoretically provide a different user identity for each service, but in reality, does that really happen? Seems like if you're doing that you're starting to mix authentication with authorization. It's not a scenario you're likely to see in the case of corporate SAML use, where people generally don't care about anonymity to SPs, but it happens fairly routinely in Shibboleth environments with multilateral federation. In that scenario, you often want proof of the user's membership of the organization (or their role within it) and the ability to track a specific user of the service, without being able to expose who the user is. In that case, your user identifier attribute ends up being an opaque ID, which is either random or a hash of username+SP-entity-ID+salt. Using that approach, there's no way to tell if user X at journal site A is the same as user Y at journal site B without the assistance of the IdP owner.

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.
    - 7y ago

johnmaguire2013 7y ago

It is common for an IdP to apply specific policies and controls dependent on which service provider the user is authenticating to. The IdP is specifically saying "user X has access to application Y." That is why the Audience is a (required) component of a SAML Response.

rb12345 7y ago

> What the article is saying is a bit nuanced in that the IDP can theoretically provide a different user identity for each service, but in reality, does that really happen? Seems like if you're doing that you're starting to mix authentication with authorization. It's not a scenario you're likely to see in the case of corporate SAML use, where people generally don't care about anonymity to SPs, but it happens fairly routinely in Shibboleth environments with multilateral federation. In that scenario, you often want proof of the user's membership of the organization (or their role within it) and the ability to track a specific user of the service, without being able to expose who the user is. In that case, your user identifier attribute ends up being an opaque ID, which is either random or a hash of username+SP-entity-ID+salt. Using that approach, there's no way to tell if user X at journal site A is the same as user Y at journal site B without the assistance of the IdP owner.