Classification: UNCLASSIFIED Caveats: NONE Response follows.
Gang > -----Original Message----- > From: Simon Laws [mailto:simonsl...@googlemail.com] > Sent: Friday, February 04, 2011 12:00 PM > To: dev@tuscany.apache.org > Subject: Re: Can application code and interceptor/handler code in > Tuscany communicate with each other via some context? (UNCLASSIFIED) > > 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. I definitely agree with not copying headers arbitrarily. I'm not suggesting that because message headers are unique properties of each individual message and should not be "shared" or used to transfer states. The reason that we are even talking about message headers is due to the current implementation of the context being Message class. In my opinion, the context is a more general concept that would include all messages (inbound, and possible multiple outbounds for multiple references) plus other states. I'm not sure there's time or is even worth the effort to enhance that since 2.x is on its way. If all Message objects are available to handlers, I don't mind to do the "copying" in the handlers. I do have concerns if I add arbitrary headers to one of the message for state carrying purpose, what the Tuscany runtime/framework would do with them and side effects it would cause. > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
