>>>>> "Eliot" == Eliot Lear <[email protected]> writes:
Eliot> Sam, Thanks for taking the time to describe the problem.
You are welcome.
I realized that I did not explicitly say it, but I think all these
complexities are tractable.
We will have to do work in order to support this use case.
I think that work is not in scope for what we're signed up to do now,
although if someone stepped forward and wanted to do the work, it could
happen sooner.
I think that some of this may require some work in kitten.
> 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.
Eliot> You mean is that the security model you have in mind does not
Eliot> require that SAML assertions be signed? We may have an
Eliot> additional software layering problem- specifically, if they
Eliot> are present, and you're using a SAML library to parse the
Eliot> messages, from a practical standpoint, an error may be
Eliot> returned.
Perhaps.
With Shibboleth we certainly are no longer having issues with this.
I'd be interested in hearing from other SAML implementeors.
Note that you are equally likely to have trouble if the message is
signed and you don't have metadata. So, you're going to have a better
user experience if your SAML library does not require signatures.
Eliot> However, I think what you're alluding to is that the lack of
Eliot> a signature itself is part of the problem of returning
Eliot> attributes from 3rd parties, since the associated
Eliot> connectivity of the AAA transport is providing authenticity
Eliot> and not the signature.
No; you can always (as the issuer at least) add signatures.
Supporting a case where the third party attributes are just carried and
the RP is responsible for validation is fairly easy at the protocol
level. It probably requires a different AAA attribute that doesn't imply
the contents should be trusted. That is, the RP is free to ignore
signatures on assertions in the current attribute, but would need to
validate assertions from third parties. However that's one new AAA
attribute, which is fairly simple.
My personal opinion is that it's also fairly useless.
We're assuming that the RP and IDP don't have any requirement for a
trust relationship other than through the AAA fabric. Why is it more
reasonable to assume a trust relationship with a third party.
There are some situations where this model is exactly what you need.
Complexity comes in if you want to offload more trust to the IDP.
Eliot> [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.
Eliot> On this point - the IdP either is or is not authoritative for
Eliot> knowing at the very least where the information is going to
Eliot> come from.
I agree with this sentence. I don't understand how it fits into the
quoted paragraph above.
Eliot> The only question here is whether or not it is
Eliot> willing to vouch for the information itself.
I agree that's a question.
I'm again not sure that it fits into the question of subject linkage,
except that one hopes the subject linkage is fairly good if the IDP does
vouch for the information.
> 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?
Eliot> And this is a generic problem with attribute providers. The
Eliot> general answer is either that the principal provides a
Eliot> pointer, or it finds the information through external means.
Sure. But we need to provide protocols and APIs to actually convey that
throughout the system. It's real engineering that needs doing for
things to work, but again is certainly something we can do.
Eliot> Eliot> Again, the only issues in this case are whether the IdP is
Eliot> providing some sort of surety, and whether it can be assumed
Eliot> that there is a trust relationship between the RP and the
Eliot> attribute provider. That latter one is a much bigger deal,
Eliot> IMHO!
I'm definitely missing how these relate to what information the RP
wants.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
