On Mon, May 19, 2008 at 4:34 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > 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 > Hi Steve I've started making some notes on this up on the wiki ( http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy). Firstly I'd like to discuss with you whether the single sign on scenario I've started to outline matches the scenario you started this thread with. >From the discussion in this thread it feels like we are going to need closer integration between the bindings and the policy providers than we have at present. In particular we need to be able to pull named parameters from the binding context or the message itself and provide that to some extensible policy code. The result, which I'm assuming here is the Subject information, then needs to be plugged back into the message context so that it flows through to Tuscany components. Regards Simon
