On Tue, Jun 3, 2008 at 3:21 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > 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 >
Hi Simon, As discussed - yes, this does pretty well describe the scenario of interest. However, there seems no reason to require the client to have already authenticated and received a token: we should equally be able to pass e.g. username and password by the same mechanism. So as regards the format of the security token, I'd suggest username and password as a minimum, which can also handle a token (username only). A general property map would be nice but not really necessary in my view. You have described the server-side processing; obviously there is matching client-side work to associate the credentials with the message or transport. I would suggest a JAAS-style callback is fine, as already used with the WS binding; though it should ideally be binding-agnostic. I look forward to your concrete proposal in due course. Many thanks Steve
