Re: [ws-sx] follow-up on i010

[Prateek Mishra <prateek.mishra@oracle.com>]

This note follows up on the discussion in the call on Feb 7.

It was pointed out in the call that SOAP intermediaries and traditional 
intermediaries (gateway/proxy)
do not need the additional flexibilities I am proposing.

On reviewing my proposal, I see that I am actually referencing a 
third-class of intermediary - an program
transformation agent, typically bound to a container and acts for 
applications hosted by the container
 by adding or transforming security headers as needed. The program 
transformation agent manages
keys associated with applications and also interacts with a STS as 
needed. In summary, the
agent impersonates security properties of various applications and acts 
on their behalf. Applications
themselves do not include any security processing whatsoever.

Consider a use-case where an agent is acting for two applications, and 
each application is bound
to a key Ki. When the agent makes a request of the STS, it can provide 
its own identity in the
SOAP header of the STR and  the identity of the application in the 
<OnBehalfOf>, say K1. But it has no
way to provide proof of possession for K1 with the current message 
structure.

For next steps I would propose to close the issue as currently stated. I 
will open a new issue describing this
use-case and a proposed solution.

- prateek





> Reading the minutes from the last call, i was asked to provide an 
> example to clarify my point.
>
> Consider a case where we have a <wsse:security> header with multiple 
> tokens involved; a
> username token which names a user ("joe"), X.509 token (i guess this 
> is called a supporting
> token) and a signature over the user-name-token and body (based on the 
> X.509 token).
>
> Now, an application can present this entire security header to STS. 
> The STS can make judgements
> based on both the X.509 token and the user-name token ("aha, this is a 
> message from Joe signed
> by the finance server") placing whatever interpretation it chooses to 
> w.r.t this header.
>
> But the intermediary cannot provide equivalent information; if we 
> imagine an intermediary acting on behalf of
> the application. As currently stated in section 11.1, the intermediary 
> can only provide a security token,
> a STR or an end-point-reference. My suggestion is to expand this list 
> to include <wsse:security>
> headers as well.
>
> - prateek
>
>