On Fri, May 9, 2008 at 1:57 PM, Steve Chamberlain < [EMAIL PROTECTED]> wrote:
> Hi Simon, > > Thanks for your reply. Further comments inline below. > > Best regards > Steve > > > On Thu, May 8, 2008 at 12:16 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > Hi Steve > > > > Some comments inline. > > > > Simon > > > > On Wed, May 7, 2008 at 4:13 PM, Steve Chamberlain < > > [EMAIL PROTECTED]> wrote: > > > >> Hi all > >> > >> I have a few related issues to raise concerning authentication. > >> > >> Firstly, when can we hope to see the policy framework being > >> implemented in bindings other than WS? My concern is particularly > >> token-based authentication with the JMS binding. I know, given the > >> new policy framework SPIs, it will be possible in principle to apply > >> policies to bindings externally, but I'm not sure that will be > >> sufficient in the JMS case. > > > > > > As far as I know there is no activity going on at the moment to extend > the > > reach of the authentication policy. But now you've raised it ;-) Can you > > say a little more about the token-based authentication you are looking > for. > > I don't know off the top of my head how a token would flow over JMS or > how > > the target service binding would intercept and apply it. It's certainly > > different, as I think you are suggesting, from providing a policy set for > > applying username/password authentication that JMS itself supports > through > > its connection creation mechanism > > > As you suggest, there are several levels at which security can be > applied with JMS. Container-level security could be applied to the > JNDI lookup and/or the connection creation. In principle both of > these should probably be supported, although clearly they presuppose > appropriate configuration of the container. > However, the specific type of authentication token I am looking for is > a session ticket that can be created, validated, and translated back > to the real user, by using some external SecurityManager service. > This can of course be accommodated within an application-level > username/password scheme such as is supported by Rampart. In JMS I > think such a token could be transported simply as one or more message > properties. > As you say, this is distinct from container-level security, unless > integrated somehow by means of a custom security provider. It is of > course simpler to manage. > > > > >> > >> Secondly, having authenticated, I need to access the credentials from > >> within the target component. This is partly for application-specific > >> authorization within the component, and partly for passing on via > >> non-SCA references. I know the RequestContext has a method for > >> returning the authenticated Subject, but it is not implemented. Is > >> there any intention either to implement this, or provide a equivalent > >> extension point? > > > > > > We are trying to represent the SCA specs a faithfully as we can so we > should > > implement this. Can you raise JIRA for this so we can track it. > > > > Will do > > > > >> > >> Finally, to support any such feature, it seems to me we need some > >> extra plumbing to associate the authenticated credentials with the > >> current invocation on the thread, like the Subject.doAs() pattern - > >> although I know the standard version is broken. This needs to be at a > >> higher level in the flow than standard interceptors. For the WS > >> binding it seems necessary to do it above the Axis handler level, e.g. > >> with a servlet filter or by extending the servlet. But I think for > >> JMS and other bindings it would need implementing within the binding, > >> probably in the Listener and possibly the Invoker (for replies). Have > >> I missed something here? > > > > > > No I don't think you've missed anything. I need to get down into the guts > of > > how the security policies are applied but we need a suitable context to > be > > created following authentication/authorization within which the service > > method operated. We need this context to implement the > getSecuritySubject() > > method. I'm not sure that we need to do this at the servlet level > although > > that might prove convenient. > > Indeed, and this context needs to be created by a common caller of > both the authenticatication and invocation mechanisms, and updated > with the results of authentication which the invocation can later pick > up. In Axis, this ought to be achievable by setting properties on the > MessageContext, except that the thread-local access to the current > context is not set up soon enough. I guess this is an Axis bug. > > > > At the moment WS-Security for the web service binding is handled by the > > Rampart module which is naturally part of Axis. The JAAS authentication > > policy provides interceptors that sit in the message path and perform the > > appropriate login actions (although it doesn't try to doAs() here which > is > > interesting). > > To make this work with the current implementation policy pattern, the > context would need to be held by PolicyHandlingInterceptor.invoke() as > the common caller, rather than by beforeInvoke() in the specific > policy handler. But even that wouldn't work for Axis, as the Rampart > security processing is not done under the control of the Tuscany > runtime. > > > > > I think this is sufficiently complex that a first step here is to draw > out > > the different mechanisms that are provided in Tuscany and that way we can > > understand if anything is missing (and as an aside we get some > documentation > > for when these questions are asked again). Then we can overlay with any > > specific requirement you have and see what needs to be added. > > > > I'd like to do this on the wiki where we can all edit it so I've started > a > > page here (http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy > ). > > You'll note that there is nothing there yet. I'm hoping that someone will > > should if there is already a page like this somewhere else that provides > > this information. > > > > > >> > >> > >> Thanks in advance > >> Steve > >> > > > Hi Steve. I haven't forgotten about this but got sidetracked last week with other things. Hope to get a chance to look in more detail this week. Simon
