[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] follow-up on i010
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]