geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@webtide.com>
Subject Re: [jetty-dev] Jetty Security refactoring for JASPI
Date Tue, 25 Nov 2008 19:57:36 GMT
Hi David,


David Jencks wrote:
> I've taken a very quick look at the AuthenticationManager you've added. 
> It looks to me (based on this very non-thorough glance) that the main
> effect is to move some of the auth setup code out of WebXmlConfiguration
> and make it more accessible to programatic setup.  For instance instead
> of having to know to use a BasicServerAuthentication you just need to
> know the string "BASIC".  Is this more or less correct?
Yes, this means that WebXmlConfiguration no longer needs knowledge of what
authentication mechanism (jaspi or non-jaspi) is being used, and we can
defer the decision to the user which flavour they prefer.

 
> I like the idea of making it easier to configure authentication like
> this, but I think there might be a more flexible and less intrusive
> way.  IIUC the runtime authentication behavior still works through the
> ServerAuthentication interface, and the added methods on
> AuthenticationManager are only used for setup.  If someone wanted to
> implement their own ServerAuthentication these extra methods wouldn't
> really provide any extra value.
> 
> What if we had something like a DefaultAuthenticationFactory that you
> set up with the security handler and called configure(String authMethod,
> String loginPage, String errorPage, String realm) on and it constructed
> the appropriate [Basic|Digest|Form|ClientCert]ServerAuthentication and
> set it in the security handler?  We'd need something similar for the
> jaspi approach.
In general, Jetty doesn't really do factory pattern. Greg has even got
a bit of a factory-phobia :) He likes to refer to jetty's use of dependency
injection rather than factories. So the pluggable AuthenticationManager
does follow a Handler->Manager pattern that is already established in 
the SessionHandler->SessionManager. We make the various implementations of
session clustering pluggable via the SessionManager.

I do agree that the AuthenticationManager and ServerAuthentication could
be simplified. But my suggestion would instead be to merge the 
ServerAuthentication behaviour into the AuthenticationManager.


cheers
Jan

> To me this would seem to separate the configuration and runtime aspects
> nicely while still providing the advantages of simpler configuration of
> the default auth methods.
> 
> I haven't looked at your jaspi code yet.... jaspi configuration is a bit
> convoluted IMNSHO and I actually suspect anyone using a jaspi module may
> want to set it up directly in code rather than dealing with a whole
> jaspi provider (which I wrote for geronimo but not jetty specifically) 
> I'll look at this in a bit.
> 
> Moving the login services seems like a very good idea :-)
> 
> thanks
> david jencks
> 
> 
> On Nov 25, 2008, at 8:53 AM, Jan Bartel wrote:
> 
>> Hi David,
>>
>> I've made some changes to attempt to make jaspi vs non-jaspi
>> authentication pluggable. I've checked the changes in, as I
>> thought it is easier to see the code than talk about it.
>>
>> In a nutshell, I've introduced an AuthenticationManager that
>> is used by a SecurityHandler to carry out all authentication,
>> and which delegates to either a non-jaspi or jaspi implementation.
>>
>> The ConstraintSecurityHandler uses a DefaultAuthenticationManager
>> (non-jaspi) by default, but one can plug in the
>> JaspiAuthenticationManager
>> as an alternative.
>>
>> The WebXmlConfiguration sets up information from the web.xml such
>> as the auth method and login/error pages on the AuthenticationManager,
>> but no longer sets up the various auth modules such as Basic, Form, Cert
>> etc. That is now done by the AuthenticationManager instance instead when
>> it is started, based on the auth information passed into it by the
>> WebXmlConfiguration
>> (or programmatically of course).
>>
>> I've allowed for the JaspiAuthenticationManager to plugin a jaspi auth
>> module,
>> so that potentially we can plug in 3rd party jaspi auth modules. The
>> question is,
>> is the pluggability at the right level? That is, I've allowed a
>> ServerAuth instance
>> to be set on the JaspiAuthenticationManager, but the
>> JaspiServerAuthentication
>> class expects a ServerAuthContext instead (which all of the FormAuth,
>> BasicAuth
>> etc classes implement) - would a 3rd party jaspi module be likely to
>> implement
>> that interface? Should we be allowing for plugging in some other class
>> entirely?
>>
>> BTW I changed around a couple of packages, most notably the
>> HashLoginService and
>> JDBCLoginService I moved out of
>> org.mortbay.jetty.security.jaspi.modules and into
>> org.mortbay.jetty.security, as AFAICT they are not jaspi specific.
>>
>> I noticed along the way that the SSO stuff isn't really hooked up.
>> Difficult to
>> see how to shoe-horn that into the new structure. Perhaps its time to
>> ditch it
>> and allow for integration with "real" SSO implementations instead?
>>
>> The jaspi branch builds and tests without error, but I'm just chasing
>> down an
>> error when running the test webapp:
>>
>> Failed startup of context
>> org.mortbay.jetty.webapp.WebAppContext@1e59128{/,/home/janb/src/jetty-jaspi/webapps/test}
>>
>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>> content-administrator, known roles: []
>>
>> And the same for the test-jaas webapp:
>>
>> Failed startup of context
>> org.mortbay.jetty.webapp.WebAppContext@10ffb38{/test-jaas,file:/home/janb/src/jetty-jaspi/webapps/test-jaas/}
>>
>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>> roleA, known roles: []
>>
>> Looks like something amiss with the role merging, perhaps.
>>
>> Have a look at what I've committed, and please let me know what you
>> think. I'm all ears if
>> you've got any suggestions or a better way.
>>
>> cheers
>> Jan
>>
>>
>>
>> Jan Bartel wrote:
>>> David,
>>> [snip]
>>>>>>> BTW,  the code needs to be reformatted to jetty standard conventions
>>>>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>>>>>>> gregw will have conniptions ;)
>>>>>> hmm.... I thought I'd done pretty well imitating the code style.
>>>>>> Do you
>>>>>> have some way to fix it automatically?
>>>>> Lemme see ... as far as the brackets go, I have an eclipse codestyle
>>>>> that I can apply to each file, but the rigorous naming of data members
>>>>> with leading _
>>>>> or __ would have to be done manually.
>>>> aha.... I can fix that, probably tomorrow.  The brackets might be
>>>> tougher for me.
>>>
>>> I've reformatted and checked in classes in jetty and jetty-security
>>> packages.
>>>
>>>>> Correct me if I'm wrong, but the constraint preprocessing behaviour is
>>>>> separable
>>>>> from the jaspi authentication, so we could make that common between a
>>>>> ConstraintSecurityHandler
>>>>> that invoked non-jaspi authentication and another
>>>>> ConstraintSecurityHandler that invoked
>>>>> jaspi authentication?
>>>> The authentication (jaspi or ServerAuthentication) and authorization
>>>> (constraints or jacc or....??)  are completely separable, but I would
>>>> not try to guarantee that the behavior of the legacy constraint
>>>> security
>>>> handler would be unchanged if we combined the constraints up front.  If
>>>> you guys are willing to risk that the legacy behavior will change or
>>>> analyze it carefully enough so you're sure it won't, combining the
>>>> constraints up front would really simplify the code.  I don't
>>>> understand
>>>> how the legacy code works well enough to be comfortable claiming
>>>> anything about it.
>>>
>>> Well, I think the existing "legacy" code is a bit difficult to
>>> understand,
>>> which is why I think it is clearer to go with your new structure that
>>> does the preprocessing.
>>>
>>>
>>>>> In terms of pluggability, I think so far I'm still leaning towards a
>>>>> default of current
>>>>> jetty authentication impl, with pluggability of the jaspi impl
>>>>> (probably via plugging in a
>>>>> JaspiConstraintSecurityHandler).
>>>> not sure what you mean here.... if you don't want to use the
>>>> ServerAuthentication, RunAsToken, and UserIdentity abstractions it may
>>>> be difficult to switch back and forth.  If you mean you want to use the
>>>> [Basic|Digest|Form|ClientCert]ServerAuthentication implementations for
>>>> the known auth methods rather than the jaspi modules, I wholeheartedly
>>>> agree.
>>>
>>> What gregw has been discussing with me is the possibility to retain the
>>> existing jetty-7 authorization code, making judicious changes as
>>> necessary
>>> in order to permit a jaspi-flavoured implementation to be plugged in by
>>> choice. The new jaspi stuff could be debugged, profiled and generally
>>> kicked around a bit more until we could be comfortable that its at
>>> least as correct and performant (in the sense of least object creation
>>> per request, lazy auth all in the right places etc) so that it could
>>> then move to being the default authorization impl.
>>>
>>> Hence, a couple of emails ago I was starting to sketch out some
>>> ideas of how we could achieve that, but the code base has moved on
>>> somewhat since then, so I'm not sure how applicable those nascent ideas
>>> still are until I get a better grip on the changes.
>>>
>>> cheers
>>> Jan
>>>
>>>
>>>>> BTW, thanks for putting so much work into the security refactoring!
>>>> np!
>>>>
>>>> david jencks
>>>>
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>>> thanks!
>>>>>> david jencks
>>>>>>
>>>>>>>
>>>>>>> cheers
>>>>>>> Jan
>>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> I rewrote the standard auth methods as ServerAuthentication
>>>>>>>> classes on
>>>>>>>> the plane ride home.  I implemented Lazy and Caching (in session
>>>>>>>> and
>>>>>>>> SSO) as wrappers.  Seems to compile but I haven't tried the tck
>>>>>>>> yet.
>>>>>>>>
>>>>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>>>>> timeouts??  but
>>>>>>>> I think this is a lot more plausible than the pure jaspi
>>>>>>>> implementations.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>>
>>>>>>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>>>>>>
>>>>>>>>> I share your concerns about efficiency of the jaspi model,
>>>>>>>>> which is
>>>>>>>>> why I tried to put another hopefully efficient layer of
>>>>>>>>> interfaces in
>>>>>>>>> between the AbstractSecurityHandler and the jaspi auth modules.  I
>>>>>>>>> was
>>>>>>>>> hoping that we could simply implement the known auth methods
>>>>>>>>> (FORM,
>>>>>>>>> BASIC,...)  in terms of the ServerAuthentication interface
>>>>>>>>> directly
>>>>>>>>> and retain all possible efficiencies.  Not having done it yet I
>>>>>>>>> might
>>>>>>>>> have missed some important points :-)
>>>>>>>>>
>>>>>>>>> I'll think some more about your comments and get back to you.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>>>>> give some more detailed comments.
>>>>>>>>>>
>>>>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>>>>> like very much the refactoring of
>>>>>>>>>> Abstract/ConstraintSecurityHandler
>>>>>>>>>> methods.
>>>>>>>>>>
>>>>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>>>>> coming :)
>>>>>>>>>>
>>>>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>>>>> is a role restriction will result in the user being fully
>>>>>>>>>> reauthenticated. I understand that even this is an
>>>>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>>>>> requires validateRequest to be called on each and every
>>>>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>>>>> authentication when there are no role constraints is another
>>>>>>>>>> good optimization.
>>>>>>>>>>
>>>>>>>>>> As there is going to be more authenticating going on as
>>>>>>>>>> compared with the previous situation, my next reservation
>>>>>>>>>> takes on more significance, and that is the amount of
>>>>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>>>>> callback design.
>>>>>>>>>>
>>>>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>>>>
>>>>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>>>>> in mind?
>>>>>>>>>>
>>>>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>>>>> without code to show.
>>>>>>>>>>
>>>>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>>>>> to modify some of the interfaces of UserIdentity and LoginService
>>>>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>>>>> things a little:
>>>>>>>>>>
>>>>>>>>>> UserIdentity
>>>>>>>>>> ------------
>>>>>>>>>> Principal getUserPrincipal()
>>>>>>>>>> String getAuthMethod()
>>>>>>>>>> boolean isUserInRole(String role)
>>>>>>>>>> setRunAsRole(RunAsToken)
>>>>>>>>>> setServletHandler(ServletHandler)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> UserRealm (was LoginService)
>>>>>>>>>> ---------
>>>>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SecurityManager
>>>>>>>>>> --------------
>>>>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>>>>> ----------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>>>>> --------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> AbstractSecurityHandler
>>>>>>>>>> ----------------------
>>>>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>>>>
>>>>>>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>>>>> where it currently invokes
>>>>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>>>>> (around line 169).
>>>>>>>>>>
>>>>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>>>>> authenticator
>>>>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>>> did in the pre-jaspi version.
>>>>>>>>>>
>>>>>>>>>> The JaspiSecurityManager implementation would be equivalent to
>>>>>>>>>> the
>>>>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>>>>
>>>>>>>>>> Perhaps the biggest change would be to the LoginService, which
>>>>>>>>>> I've
>>>>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>>>>> authentication related, rather than strictly login related. No
>>>>>>>>>> problem though
>>>>>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>>>>>> method
>>>>>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>>>>>> LoginCallback
>>>>>>>>>> instance on the Subject (via the ServletCallbackHandler). I don't
>>>>>>>>>> see that as a major problem - the ServletCallbackHandler could
>>>>>>>>>> set
>>>>>>>>>> the UserIdentity object on the Subject instead. Note that in a
>>>>>>>>>> jaspi
>>>>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>>>>> called, or
>>>>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>>>>
>>>>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>>>>> I think we'd need another set for the default jetty
>>>>>>>>>> implementation
>>>>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>>>>> duplication
>>>>>>>>>> would be highly desirable.
>>>>>>>>>>
>>>>>>>>>> From the user's perspective, it would be simple to configure
>>>>>>>>>> jaspi:
>>>>>>>>>>
>>>>>>>>>> WebAppContext webApp = ...;
>>>>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>>>>> JaspiSecurityManager());
>>>>>>>>>>
>>>>>>>>>> I'm sure I haven't considered all aspects of pluggability.
>>>>>>>>>> I'll try
>>>>>>>>>> and get some time to turn the thoughts into code, which are a)
>>>>>>>>>> more
>>>>>>>>>> easily
>>>>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> Jan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>>>>
>>>>>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>>>>>> future,
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>>>>
>>>>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235 and
>>>>>>>>>>>> 259.
>>>>>>>>>>>>
>>>>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>>>>> again on
>>>>>>>>>>>> the right connector (either the confidential or integral
>>>>>>>>>>>> port as
>>>>>>>>>>>> appropriate).
>>>>>>>>>>>>
>>>>>>>>>>>> cheers
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>>>>>>> noticed
>>>>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>>>>> notices the request was received on the wrong connector
>>>>>>>>>>>>>> (ie on
>>>>>>>>>>>>>> http
>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>> https) and does a redirect, the
>>>>>>>>>>>>>> AbstractSecurityHandler.handle()
>>>>>>>>>>>>>> method goes
>>>>>>>>>>>>>> ahead and subjects the request to JASPI authentication. It
>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>>>>> altogether. It
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be the redirected request that we're interested in processing
>>>>>>>>>>>>>> further
>>>>>>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>>>>
>>>>>>>>>>>>>           if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>>>>>           {
>>>>>>>>>>>>>               if (!base_request.isHandled())
>>>>>>>>>>>>>               {
>>>>>>>>>>>>>                   response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>>>>>                   base_request.setHandled(true);
>>>>>>>>>>>>>               }
>>>>>>>>>>>>>               return;
>>>>>>>>>>>>>           }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think there's something odd here, but IIUC something
>>>>>>>>>>>>> other than
>>>>>>>>>>>>> what
>>>>>>>>>>>>> you see.
>>>>>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>>>>>> request.
>>>>>>>>>>>>> I've been worrying about this because it prevents redirecting
>>>>>>>>>>>>> http
>>>>>>>>>>>>> requests to the equivalent https requests.  Until recently I
>>>>>>>>>>>>> didn't
>>>>>>>>>>>>> think it was possible to do this redirect using jacc
>>>>>>>>>>>>> permissions
>>>>>>>>>>>>> but I
>>>>>>>>>>>>> think there is a solution....
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the actual request is denied and is http we could create
>>>>>>>>>>>>> a new
>>>>>>>>>>>>> request with the url converted to https and
>>>>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>>>>> it.... if that check succeeds we can redirect to the more
>>>>>>>>>>>>> secure
>>>>>>>>>>>>> url.
>>>>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>>>>> authentication is
>>>>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> unauthenticated user.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the jaspi
>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are
>>>>>>>>>>>>>>>> quasi
>>>>>>>>>>>>>>>> analogous
>>>>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour has
>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to retain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>>>>>> understand the
>>>>>>>>>>>>>>> new code, I rather think it would be confusing.  I'd really
>>>>>>>>>>>>>>> rather not
>>>>>>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal and
>>>>>>>>>>>>>>> depending
>>>>>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> things.  The main point of introducing it was that in jetty
>>>>>>>>>>>>>>> integrations
>>>>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the
>>>>>>>>>>>>>>> UserPrincipal was
>>>>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>>>>> non-principal
>>>>>>>>>>>>>>> information associated with the user's identity.  I think
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>>>>> whatever else the security system needs.  I don't have
>>>>>>>>>>>>>>> strong
>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>> to calling the LoginService UserRealm but I think its going
>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be quite
>>>>>>>>>>>>>>>> important for
>>>>>>>>>>>>>>>> Jetty users to be able to make a smooth transition over
>>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm
>>>>>>>>>>>>>>>> and a
>>>>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe.  I think the new interfaces are a lot clearer and
>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>> descriptive for embedding jetty that the old ones.  I could
>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>>>>> LoginService to
>>>>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work.  In
>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>> I'm not
>>>>>>>>>>>>>>> at all sure the non login-service methods on UserRealm could
>>>>>>>>>>>>>>> plausibly
>>>>>>>>>>>>>>> be called.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>>> (well,
>>>>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>>>>> WebAppContext.getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>>>>> LoginService is
>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler, around
>>>>>>>>>>>>>>> line 1042
>>>>>>>>>>>>>>> of WebXmlConfiguration.  I don't recall changing this code
>>>>>>>>>>>>>>> much...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of
>>>>>>>>>>>>>>>> callbacks it
>>>>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>>> the right info, such as credentials, passwords,
>>>>>>>>>>>>>>>> usernames and
>>>>>>>>>>>>>>>> also extra request parameters from the login. I notice
>>>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler
>>>>>>>>>>>>>>>> instead? It
>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I think
>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>>>>>>> extracting
>>>>>>>>>>>>>>> credentials from the request.  In the jaspi architecture
>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>>>>> service.  A
>>>>>>>>>>>>>>> login module that fishes directly in the request ought to be
>>>>>>>>>>>>>>> refactored
>>>>>>>>>>>>>>> into a plain login module that just validates the
>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>> and an
>>>>>>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>>>>>>> Despite all
>>>>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and worth
>>>>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I guess someone who really really wanted to preserve their
>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>> could write a subclass of LoginCallback that dealt with
>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>> parameters, and a JAASLoginService subclass.  This would be
>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>> easier
>>>>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>> protected method.   Looks like I left out some exception
>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> too :-(  I'd rather not encourage this however.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>>>>>>> marker
>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>>>>> mappings
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>>>> This is an embedding thing also.  It's pretty unclear what
>>>>>>>>>>>>>>> run-as is
>>>>>>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>>>>>>> identity for
>>>>>>>>>>>>>>> a web service client or other remote call is supposed to
>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>> (If the
>>>>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>>>>> credentials does
>>>>>>>>>>>>>>> this run-as-role identity supply????)  In Geronimo we
>>>>>>>>>>>>>>> represent the
>>>>>>>>>>>>>>> run-as role by a Subject obtained by logging into a security
>>>>>>>>>>>>>>> realm.  So,
>>>>>>>>>>>>>>> the geronimo run-as token has this Subject in it.  We might
>>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't think
>>>>>>>>>>>>>>> constraining the representation of the run-as identity is
>>>>>>>>>>>>>>> wise.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>>>>>>> more or
>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>> agree on the main interfaces, at which time I plan to
>>>>>>>>>>>>>>> rewrite
>>>>>>>>>>>>>>> them in
>>>>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and
>>>>>>>>>>>>>>>>>> light on
>>>>>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi branch,
>>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey around,
>>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/jetty-plus
>>>>>>>>>>>>>>>>> Not sure if it  is ideal, it's pretty much a simple
>>>>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to
>>>>>>>>>>>>>>>>>> you with
>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you that
>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>>>> them back into more jetty specific code.  Of course if you
>>>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity
>>>>>>>>>>>>>>>>>> @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>>>>> on at the end when someone realized it was incomplete, and
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>>>>> of CallbackHandler for two way communication between the
>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for
>>>>>>>>>>>>>>>>>>> me to
>>>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>>>>> integration with jetty and its getting to a point
>>>>>>>>>>>>>>>>>>> where I'm
>>>>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for
>>>>>>>>>>>>>>>>>>> messaging
>>>>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>>>>> authentication.  On
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> client you can add auth info to a request and
>>>>>>>>>>>>>>>>>>> validate auth
>>>>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>> response.  On the server you can validate auth info on a
>>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>>>>> auth info to a response.  The auth code can conduct
>>>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and
>>>>>>>>>>>>>>>>>>> transmit the
>>>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal for
>>>>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi
>>>>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it is
>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>>>>> integration with other app servers with their own ideas
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to
>>>>>>>>>>>>>>>>>>> verify
>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response pair on
>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle.  This
>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>>>>> method that runs through the following structure calling
>>>>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>> base_response, constraintInfo).  This checks the user
>>>>>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>>>>> basically that the request arrived over the right
>>>>>>>>>>>>>>>>>>> kind of
>>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>>> (http/https).  Two obvious implementations of this
>>>>>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>> jetty constraint based implementation or one based on
>>>>>>>>>>>>>>>>>>> JACC.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> we can often delay authentication until a method
>>>>>>>>>>>>>>>>>>> relying on
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory into a
>>>>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass
>>>>>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will
>>>>>>>>>>>>>>>>>>> extract the
>>>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided
>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash, JDBC,
>>>>>>>>>>>>>>>>>>> etc
>>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>>>>> authentication when info is actually needed.  In this
>>>>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this includes
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>>>>> UserIdentity userIdentity = newUserIdentity(authResult);
>>>>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however they
>>>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext, base_request,
>>>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now secure
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework implementation
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>>>>> (rather than the bits actually needed for http which I
>>>>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>>>>> and have a nearly-untested openid implementation.   This
>>>>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an
>>>>>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> SecurityHandler:  AbstractSecurityHandler now just
>>>>>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>> workflow described about and delegates all actual
>>>>>>>>>>>>>>>>>>> work to
>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> authentication delegate.  This makes it easy to plug in
>>>>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Authentication results and run-as roles:  Formerly these
>>>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>>>> UserRealm.  This really overloaded the idea of a
>>>>>>>>>>>>>>>>>>> Principal
>>>>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>>>> convoluted.  This is replaced with a UserIdentity
>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>>>>> separate access to the auth results (user principal) and
>>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling).  Subclasses of
>>>>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> interface.  These typically delegate to
>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy
>>>>>>>>>>>>>>>>>>> authentication if
>>>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated
>>>>>>>>>>>>>>>>>>> functions,
>>>>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the
>>>>>>>>>>>>>>>>>>> credential
>>>>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>>>>> in LoginService.  Credential validation may not even be
>>>>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> server (e.g. openid).  If needed it's called from
>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> extracts credentials from the request. 
>>>>>>>>>>>>>>>>>>> Implementations are
>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>>>>> On the other hand the role handling is called by jetty
>>>>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>>>>> e.g. geronimo).  Aside from being related somehow to
>>>>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService relate to
>>>>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>>>> subject)
>>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication
>>>>>>>>>>>>>>>>>>> packages
>>>>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal and
>>>>>>>>>>>>>>>>>>> group
>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> callback handers.  This lets ServerAuthentication
>>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>>>>> whole lotta methods on some other stuff.  or.... you can
>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>>>>> and stuff it into an adapter, JaspiServerAuthentication.
>>>>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>> ServerAuthModule implementations (a ServerAuthContext is
>>>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which have
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of
>>>>>>>>>>>>>>>>>>> asking for
>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>> validation and getting some info back.  JASPI has a
>>>>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>>> based on Callbacks.  The container (jetty) supplies the
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>>>>> services.  AFAICT these are mostly for securing response
>>>>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the
>>>>>>>>>>>>>>>>>>> server:
>>>>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller
>>>>>>>>>>>>>>>>>>> principal so
>>>>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user may be
>>>>>>>>>>>>>>>>>>> in.  The
>>>>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird to me
>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging, including
>>>>>>>>>>>>>>>>>>> ejb
>>>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>>>>> normally not a secured response.  Trying to evaluate
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the
>>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't see how this implementation could be
>>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time now.
>>>>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>> I can see that is possible with constraint
>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request to the
>>>>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>>>>> https request if a user data constraint is violated. 
>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> whether this is something people want to do or
>>>>>>>>>>>>>>>>>>> usually set
>>>>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>  http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>  http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>   http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> -- 
>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>    http://xircles.codehaus.org/manage_email
> 
> 
> 


-- 
Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com

Mime
View raw message