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

Reply via email to