Sam Comments in line.
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sam Hartman > Sent: Monday, January 10, 2011 11:18 AM > To: [email protected]; [email protected] > Subject: [abfab] Multiple attribute providers in an authentication > > > 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. Would you consider it to be permissible for an intermediate to re-write the assertions to change the framework they are being made in from the IdP's home network to the federation network's framework? This would say that they may not have quite the same degree of integrity protection as might be initially assumed. > 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. Are you saying that the principal has multiple names or that they are multiple assertions being made about a single name? > 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? What happens if the naming space of the claims is different between the IDP and the RP? What happens if the additional attributes need to come from a completely different fourth realm? I.e. my name comes from the country of issue, the RP is a bank and the attributes need to come from a university? > > 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. I completely agree this is a hard problem that we need to start writing down, if not answers then at least boundaries of the problem. Jim > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
