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. If there are multiple assertions from the same IDP it seems reasonable to treat them all the same. Things get a lot more messy when assertions from multiple IDPs are included. What does it mean to include them in the AAA transport? I can think of several trust models that are appropriate depending on deployment: * The IDP corresponding to the subject's NAI has validated these additional assertions and wishes to assert that the attributes can be trusted. "If you trust me then you should trust these." Here, the assertions are being included either for convenience of packaging the attributes into some form the RP can process or because it is possible that the RP may be able to validate some signature and trust the attribute source more than the IDP. * The subject IDP has performed SAML validation on the assertions. However the IDP is making no claims about how trusted the attributes included in the additional assertions are. Even if the IDP would be permitted to make a claim made in an additional assertion, the RP needs to make an independent policy decision about whether the actual issuer should be permitted to make that claim. * Here are some assertions for the RP's convenience. The IDP makes no claims about them; not even the implied claim that they have not been modified in transit. They better be signed, the RP better have metadata for their issuer, and the RP is more or less on its own. 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. 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? How does the RP make the policy decisions it needs to make? How does it get metadata that is needed? I think this sort of issue will also have impacts for kitten, because we'll need to describe it in the naming extensions interface. It seems like ABFAB is not going to be the only group facing these sorts of discussions; Kerberos is in the middle of a similar discussion right now. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
