saml proxying scoped attributes...best practice

[Bobby Lawrence]

> Passing through values is a degenerate form of the stateless model, but with no insulation between internal and external.

I'm not entirely sure why I would need insulation between internal and external...can you explain?  I guess that’s my issue, I don’t think I want or even need insulation.  I want a proxy that passes through the values unmolested.  My SP trusts the IdP and that IdP trusts the upstream IdP.  If my SP doesn't trust the upstream IdP (the authenticating authority), then it can choose to reject the assertion right?  Maybe I'm just not thinking about all the ramifications...

At the end of the day, I simply want the SP to see the id that the user authenticated upstream with, not some opaque value that makes no sense to anything but the proxying IdP.  If the problem is about scoping, then I understand why you would want to encode the value somehow...so you can then apply the IdPs scope to it.  But then I would want to be able to decode that value downstream and I can't do this when its hashed.

> > but most of my SPs need to lookup a database record of a valid user to
> > determine authorization roles/rules. How am I to correlate the
> > identifier to a database record if its hashed?
> 
> The same way they would with any other identifier. 

I cannot lookup user information in my authorization system if the user identifier is effectively unknown.  Its been changed to something opaque that’s only known to the IdP.  If I can't get the actual user id downstream at the SP, its not much better than having no authentication at all because I cannot determine who the user is without some strategy to turn that opaque value back into a real user id.

> The downside is when you have to provision access ahead of time, i.e. knowing
> what the identifier is going to be. Then hashing is a bad approach. But that's the same reason pairwise approaches tend to work badly,
> so it's not a novel problem with proxies either.
> 
> To some extent, all federated systems have that problem of not knowing how to determine someone's identifier ahead of time

In my experience, most SPs don’t do just-in-time provisioning, so the access has to be provisioned ahead of time.  Because of this, the SP needs to know how the IdP is going to send back the user identifier (and how its formatted).  I always thought that this is something that SPs and IdPs have to agree on - either between themselves or via a federation which 'recommends' that user ids should be released via some attribute.  

If I have an SP that needs to authenticate a user from some IdP other than my own, in addition to us sharing metadata, I have to tell the IdP operator how I need the user id sent back to me.  Or I have to make a decision on how to get the user id from the assertion that the IdP returns to me using either the NameID or attributes.  Either way, I need that user id and if its something opaque, its meaningless to the SP.