On Fri, Feb 4, 2011 at 4:49 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Response follows. > > Gang > >> -----Original Message----- >> From: Simon Nash [mailto:n...@apache.org] >> Sent: Friday, February 04, 2011 10:32 AM >> To: dev@tuscany.apache.org >> Subject: Re: Can application code and interceptor/handler code in >> Tuscany communicate with each other via some context? (UNCLASSIFIED) >> >> Simon Laws wrote: >> > On Fri, Feb 4, 2011 at 11:17 AM, Simon Nash <n...@apache.org> wrote: >> >> See responses below. I've removed older discussion to make this >> >> easier to follow. >> >> >> >> Simon >> >> >> >> Yang, Gang CTR US USA wrote: >> >>> Classification: UNCLASSIFIED >> >>> Caveats: NONE >> >>> >> >>> (cut) >> >>> >> >>> GY: The use case applies to SCA well. When a new service is >> developed >> >>> referencing other existing services. The authorization is best > done >> in a >> >>> distributed fashion - the information owning service makes the >> >>> authorization decision based on its existing policies. This means >> that >> >>> when a client access this new service with its credential, this >> >>> credential (in the form of some security token, say SAML) would >> need to >> >>> be passed to the other existing services for authorization. >> Translated >> >>> to SCA view, the handler for the service WS binding needs to pass >> the >> >>> user credential to the handler for the reference WS binding. Since >> the >> >>> two handlers does not have any direct relation, this is done (in >> other >> >>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new >> service >> >>> implementation code which connects the service (inbound from the >> client) >> >>> to the reference (outbound to other services). >> >>> >> >> In SCA there's a getSecuritySubject() method on the RequestContext >> API. >> >> This is implemented by putting a Subject header in the >> ThreadMessageContext. >> >> This header is added by the service binding handler and would be >> available >> >> to the reference binding handler. Does this do what you need? >> >> >> >> Simon >> >> >> > >> > Reading the comments here I think the scenario being described is >> > >> > (1) service binding.ws -> (2) handlers -> (3) component >> implementation >> > -> (4) handlers -> (6) reference binding.ws >> > >> > Where credentials received at (1) or computed at (2) are required to >> > be propagated to (4) and (5). Simon N is right that, in 1.x, we >> > already look to provide access to the security subject from within >> the >> > Java component implementation (3). See the following code from [1] >> > for an example. >> > >> > for (Object header : >> > ThreadMessageContext.getMessageContext().getHeaders()){ >> > if (header instanceof Subject){ >> > subject = (Subject)header; >> > break; >> > } >> > } >> > >> > >> > While providing a "subject" in the component implementation doesn't, >> > in its' own right, help propagate the context to (4) and (5) this >> > does show that the incoming message is available in the thread >> context >> > so (4) and (5) have access to it also assuming you don't do any >> thread >> > switching in your component implementation. >> > >> > [1] http://svn.apache.org/repos/asf/tuscany/sca-java- >> > 1.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/contex >> t/RequestContextImpl.java >> > >> > Regards >> > >> > Simon >> > >> I think there's a slight problem here. When the implementation (3) >> makes >> a request invocation, JDKInvocationHandler creates a new Message > object >> and put it in the ThreadMessageContext. This Message object is >> accessible to (4) and (5) but the original Message object (containing >> the incoming JAAS Subject header) isn't. To allow (4) and (5) to >> access >> the incoming security subject, we would need to change the MessageImpl >> constructor so that the current security subject in the >> ThreadMessageContext >> is added to the newly created MessageImpl. > > I had the feeling that they might be different Message objects when I > asked the detailed questions in my other response to Simon L.'s post. It > makes sense because Message is actually presenting the message and there > are two messages involved here. Can the context be enhanced to a general > one? > > Gang > >> >> Is it safe to make this change? Is it correct from an SCA > perspective? >> I'm concerned that it might cause security credentials to leak out >> when the application isn't expecting this. > > It's true that opening up this context to the component implementation > code may cause some undesired leakage of information in this scenario. > But in the second scenario I described in my other response, the > component implementation does need to pass some information to the > handlers dynamically at runtime. One possible solution is to make the > information flow one way, from component implementation to handlers, but > not the reverse. We can do this only if (1)/(2) can directly communicate > with (4)/(5) w/o (3)'s involvement. > > Gang > >> >> Simon > > > Classification: UNCLASSIFIED > Caveats: NONE > > >
To reply to both Simon and Gangs posts... I had missed that. I don't know why we put the request message in the TMC rather than leaving it as is. It's not clear to me what's pulling the request message from there at the moment. All of the interceptors down the chain already have access to the request message part of the invoke. There must be a reason so I'll have to look more closely. I agree with Simon that we would have to be careful before just copying headers arbitrarily from one to another. I had thought this was the job of policy handlers on the reference side. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
