Sam, Thanks for taking the time to describe the problem.
On 1/10/11 8:17 PM, Sam Hartman wrote: > Background: there was a discussion between authors of the abfab > architecture proposal about multiple attribute providers. > The idea is that you have an identity provider that is producing a set > of attributes about a subject. In the case of ABFAB we're mostly > thinking of a SAML IDP for this particular example. > > The IDP has some attributes it may be in a position to assert. > But the IDP may also want to gather attributes from other sources and > pass those along. > > One option it has is to simply pass the attributes along as if it issued > them itself. That option isn't really interesting from a protocol > standpoint because it is indistinguishable from the IDP actually issuing > the attribute itself. That is probably a fine thing to do in certain > deployments but we don't need to spend a lot of time on it. > > Another option is that the IDP can go actually get a SAML assertion (or > attribute certificate or the like) and include that in what is sent to > the RP. > > At first glance, the protocol implications of doing this look > simple. You just stick the assertion in the existing bag of bits and > move on. > > however, it's not that simple because of semantics. > > Today in ABFAB, we haven't done a great job of describing what the trust > semantics of the attribute in draft-ietf-abfab-aaa-saml are. However > what has been going through at least Josh and my mind is that the RP > SHOULD assume that the AAA framework provides an integrity protected > channel for that SAML message. The message is actually issued by the IDP > corresponding to the NAI used to make the access request. In addition, > for the SAML assertions sent from the IDP to the RP, the RP SHOULD > assume that the IDP is asserting those attributes about the subject. > That is, the RP need not perform any validation of the SAML > assertion. The RP still needs to validate whether the IDP is permitted > to make the claims it does. > There's no requirement that these SAML assertions be signed. > The IDP MAY sign the assertion; the RP MAY consider any signatures that > are present. However in the interoperable case, any signatures that are > present are ignored. You mean is that the security model you have in mind does not require that SAML assertions be signed? We may have an additional software layering problem- specifically, if they are present, and you're using a SAML library to parse the messages, from a practical standpoint, an error may be returned. However, I think what you're alluding to is that the lack of a signature itself is *part* of the problem of returning attributes from 3rd parties, since the associated connectivity of the AAA transport is providing authenticity and *not *the signature. > [snip] > Another source of complexity surrounds how an IDP links an assertion to > a subject. What confidence is the RP asserting that the additional > assertion describes the same principal as the access-accept message. On this point - the IdP either is or is not authoritative for knowing at the very least where the information is going to come from. The only question here is whether or not it is willing to vouch for the information itself. > Another potential source of complexity is how does the IDP know what > information to gather? Does the IDP just know somehow? Does the RP pass > information back? And this is a generic problem with attribute providers. The general answer is either that the principal provides a pointer, or it finds the information through external means. Again, the only issues in this case are whether the IdP is providing some sort of surety, and whether it can be assumed that there is a trust relationship between the RP and the attribute provider. That latter one is a much bigger deal, IMHO! Regards, Eliot
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
