Classification: UNCLASSIFIED Caveats: NONE Thanks, Simon L. To further clarify what exactly is available, from your description, am I right in saying that the SAME object of type Message, which can carry ARBITRARY headers and not just predefined Subject (because I do need to pass objects, such as SMAL assertion objects), is accessible from PolicyHandler code for both service binding and reference binding? This sounds like the component implementation code does not have to get involved. Right? If so, this does sound useful for one of my scenarios and I'll try this out.
Further details: 1. Is the Message object the same as the one that is passed to PolicyHandler's before/afterInvoke() or it has to be obtained by calling ThreadMessageContext.getMessageContext()? 2. If it can only be obtained by call ThreadMessageContext.getMessageContext(), which is a static method, can component implementation code access it? 3. How should I interpret your statement, "While providing a "subject" in the component implementation doesn't, in its' own right, help propagate the context to (4) and (5)"? Because there is a second scenario, where the component implementation code also needs to add credential or security information to the context so that the associated PolicyHandler can access. Using your picture, this looks like: (1) component implementation -> (2) handlers -> (3) reference binding Where (1) needs to forward some security information to (2) to be further processed and sent to (3) to be transported to the remote service. If you answer to detailed question 2. Is "Yes", then this is solved. If not, any other mechanism? Thanks, Gang -----Original Message----- From: Simon Laws [mailto:simonsl...@googlemail.com] Sent: Friday, February 04, 2011 9:47 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) 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/context/RequestContextImpl.java Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
