Re: Least Privilege & Special Powers of Attorney (UNCLASSIFIED)
On 4/12/07, Friedrichs, Paul D CTR DISA PEO-IAN
<Paul.Friedrichs.ctr@disa.mil> wrote:
I recently read about the use of signed SAML authorization decisions for
delegation. Great idea! I wonder whether this would obviate proxy
authentication credentials. (Your possession of a power of attorney does
not support authentication of you; it is an attribute assertion. Relying
parties would have to authenticate you as the person named in the POA.)
In our case, for the time being at least, the SAML assertion is bound
to a short-term X.509 certificate (EEC or proxy), so the authn
credential and the authz credential are one and the same.
(1) If an intermediary includes a senderVouches SAML
authenticationStatement in the header of a WS-Security-signed message to
a back-end resource, the assertion cannot be captured and played
successfully in another, fake message.
I don't think it's the sender-vouches SubjectConfirmation that
provides this security feature, but rather the WS-Security SAML Token
Profile itself.
But "sender vouches" is
misleading. The sender isn't vouching for anything. (Vouching would be
an attribute assertion.)
As far as I understand it, sender-vouches doesn't have anything to do
with the particular statements in the assertion. In general,
SubjectConfirmation tells the RP what processing steps it needs to
execute before it can be confident that the assertion (whatever its
content) can be associated with the Subject. In the case of
sender-vouches, no explicit processing steps are required.
The useful meaning of this assertion would be
"I promise that I have authenticated this entity, and that it is he who
has asked me to make this request. Additionally, I promise to give the
response only to this entity. I promise that I have/will authenticate
the entity in the manner described." The scenario works if this
intermediary is trusted by the relying party to make such claims.
This is precisely the use case we have in mind. Thanks for describing
it so eloquently!
(2) The fact that an "intermediary" is in possession of proof that an
entity has been authenticated doesn't satisfy me that there is any proof
that this "intermediary" had anything to do with that authentication.
This depends entirely on the use case, I think. The intermediary may
in fact *not* have had anything to do with the original act of
authentication. Such is the case with a Shibboleth-enabled Science
Gateway, for example.
Again, I'm worried about man-in-the-middle attacks.
To mitigate this possibility, the issuer of the SAML assertion can
bind the intermediary's key to the assertion using holder-of-key
SubjectConfirmation (or otherwise bind something that the RP can use
to obtain a key). In our case, though, this is not an issue since the
RP trusts the intermediary implicitly.
So generally, I think (1) is a correct, but potentially dangerous and
usually inappropriate, business model, but (2) is faulty technology.
All depends on the use case. In some cases, you can have your cake
and eat it, too ;-)
I am interested in the use of SAML authorization decisions for
delegation and plan to pull this string at this end.
Great! We're interested in your use case, so please keep us posted as
it develops.
Thanks,
Tom