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/context/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.
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.
Simon
