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 Wed, 26 Nov 2008 09:40:38 GMT
Hi David,

> I chatted with Greg a bit on IRC and think I understand a little better
> why you might like the AuthenticationManager.  IIUC it takes the code
> that sets up the standard authentication methods out of
> WebXmlConfiguration and puts it in a component that can be set from
> jetty.xml (although the default implementation is hardcoded).  Is this
> more or less correct?

Yes it does take the code out of WebXmlConfiguration that instantiates
the particular auth module. This is because we want there to be no
dependencies in the main jetty code on the type of authentication system
we're using - either jaspi or non-jaspi. As jaspi has its own set of
basic/form/cert etc auth modules in addition to the standard jetty ones,
then WebXmlConfiguration would somehow have to know which type to construct.
This would then pollute WebXmlConfiguration with knowledge of jaspi. Moreover,
the JaspiServerAuthentication class which actually seems to mediate the
jaspi processing, and upon which the correct instance of the jaspi auth
module needs to be set, was being constructed in WebXmlConfiguration,
which again, polluted it with jaspi knowledge.

By introducing the AuthenticationManager, the WebXmlConfiguration class
does not need to care which type of authentication system we're using,
as the decision on which type of auth modules to construct is taken care
of inside the AuthenticationManager implementation - either jaspi or
non-jaspi (which I have called for want of a better name DefaultAuthenticationManager).
The user can opt to use jaspi authentication for his webapp in the
standard jetty way by plugging in the JaspiAuthenticationManager in
a context xml file to configure the WebAppContext. Here's an example from
the test webapp, with the jaspi bit added. The following is all you need
to do to enable jaspi (apart from ensuring the jaspi jars are on the
classpath of course):

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  ...
  <Get name="securityHandler">
    <Set name="loginService">
      <New class="org.mortbay.jetty.security.HashLoginService">
            <Set name="name">Test Realm</Set>
            <Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set>
      </New>
    </Set>

    <!-- START JASPI BIT

    <Set name="authenticationManager">
      <New class="org.mortbay.jetty.security.jaspi.JaspiAuthenticationManager">
      </New>
    </Set>

    END JASPI BIT -->

    <Set name="checkWelcomeFiles">true</Set>
  </Get>

</Configure>

By doing this, there is indeed now the possibility that a particular auth
module implementation could be plugged into the AuthenticationManager.
Eg, a specific implementation of Basic authentication could potentially
be plugged in to an AuthenticationManager to use, rather than constructing
its own. I don't see this necessarily being of great use for the normal
jetty auth modules, however, it is very much in the spirit of jetty that
we support pluggability. Jetty's philosophy is to be the least prescriptive
as possible, provide defaults for most things, but allow the maximum
customisability.

Where I *do* see the ability to plug in a particular auth module being useful
is in the jaspi implementation. As I understand it, we want to support
plugging in 3rd party jaspi modules. My question to you in a previous
email was at what level do you think that jaspi pluggability should 
be supported? Is it enough to plug in a different auth module impl
(in the jaspi parlance a ServerAuthModule or ServerAuthContext instance) 
or do we need to make more of the jaspi machinery pluggable? 

As for the current AuthenticationModule implementations, I do agree
that there could be some improvements. Particularly, I don't want to have
a DefaultAuthenticationModule instance constructed by the ConstraintSecurityHandler
as a default. I want it to be totally pluggable, and when the
ConstraintSecurityHandler is started, it will only construct a DefaultAuthenticationModule
IFF it has not been given a specific impl to use.  This implies that
these setters need to move off the AuthenticationManager interface, and
onto the SecurityHandler interface, as an AuthenticationManager instance
may not be in existance at the time the WebXmlConfiguration processing
is done:

+  setAuthMethod(String)
+  setLoginPage(String)
+  setErrorPage(String)
+  setAllowLazyAuth(boolean) //note this is NOT derived from web.xml

The authMethod used to be on the ConstraintSecurityHandler anyway, and
the ability to control lazy authentication is, I think new, 
so I don't see moving them onto SecurityHandler as a problem. The loginPage 
and errorPage are, as you say, only relevant to the form authentication, but as 
we cannot construct a form auth module in WebXmlConfiguration to receive
these settings without polluting WebXmlConfiguration with jaspi/on-jaspi typing, 
then I don't see any other alternative than putting them onto the SecurityHandler.
Thoughts?

BTW, I see the name field of the LoginService (aka UserRealm) was deprecated.
Not sure how that came to pass, but I've reinstated it, and now
the realm name can be obtained by whichever authentication system type 
from the LoginService instead.

I also re-added the ability for a specific LoginService to be plugged into
a WebAppContext, rather than insisting that WebXmlConfiguration look thru 
all the LoginServices set on the Server instance to find a matching one. 
This reinstates previous jetty behaviour.

Having said all that, if you can think of a different way of achieving
pluggability and configurability without introducing any dependencies 
on the type of the authentication system in the core jetty code, 
then I'm all ears.

cheers
Jan


> 
> This seems sort of like a plausible goal to me but I still have some
> concerns...
> 
> First of all, this is an entirely new level of flexibility beyond
> anything previously in jetty.  Jetty trunk just hardcodes the choice of
> [Basic|Digest|Form|ClientCert]Authenticator directly in
> WebXmlConfiguration, just like I did with the ServerAuthentication
> replacements.
> 
> I'm not actually sure there's any chance anyone would use this added
> flexibility and strongly suspect there's an easier way to get there with
> less code.  I think that we should look at the plausible choices for
> authentication:
> 
> 1. [Basic|Digest|Form|ClientCert]ServerAuthentication -- standard, 
> known methods.  I can't see why someone would reimplement all of these
> and want to base jetty on their reimplementation rather than just
> installing the ServerAuthentication they want per app directly (see (3)
> below)
> 2. A Jaspi ServerAuthModule or maybe ServerAuthContext.  For instance
> the OpenId module I wrote for geronimo or the spnego one Ron Monzillo
> wrote.  There's a sub-question of how people might like to install this
> which I'll address later -- but we want to support jaspi somehow.
> 3. A custom implementation of jetty's ServerAuthentication.  I would
> hope that anyone who went to the trouble to write an auth method for
> jetty would use this easier to use more optimized interface rather than
> the jaspi one.
> 
> Do you see any other plausible choices?
> 
> IIUC what your AuthenticationManager code does is make it possible to
> supply different implementations for the
> [Basic|Digest|Form|ClientCert]ServerAuthentication other than the ones
> jetty ships with and configure jetty (using jetty.xml) to install these
> instead of the standard ones.  I just cant see how this would be a
> plausible scenario.  I'm happy to be convinced though...
> 
> We still don't have code for (2). (I know you wrote
> JaspiAuthenticationManager but its not created in code anywhere so
> requires extra configuration -- and I haven't looked at it yet.)  I've
> been delaying writing it until we have agreement on more of the
> interfaces.... maybe not so wise on my part :-)  The official way to use
> jaspi is rather complicated and IMO silly for jetty.  You need a Jaspi
> provider that lets the all-powerful sysadmin configure all sorts of
> stuff including ServerAuthConfigs for specific apps.  This is then saved
> somehow by the jaspi impl ready for use by the world, indexed by
> basically the context root of the app.  Now when the app is deployed you
> go through a bunch of classes using that context root and eventually
> manage to extract the ServerAuthConfig for your app.   The jaspi spec
> says if there's an auth whoozits configured for your app (based on the
> context root) then you should use it instead of the standard auth method
> that might be configured.   So we ought to support this I guess but I
> doubt anyone will use this.  What you actually need is either a
> ServerAuthModule or ServerAuthContext  and you can configure those
> yourself and stuff them in the JaspiServerAuthentication (possibly with
> a wrapper around them).
> 
> So I think what I'd like to see is...
> 
> if there's either a ServerAuthentication instance or jaspi
> ServerAuthModule/Context/Config explicitly configured in context.xml
> (IIUC this is the app-specific "jetty plan" for the web app) then we'll
> use that.
> Otherwise...
> If there's a jaspi provider available and configured and there's
> something configured for your app we'll use that
> Otherwise...
> we'll use the [Basic|Digest|Form|ClientCert]ServerAuthentication built
> into jetty.
> 
> So that's why I don't think the added flexibility of
> AuthenticationManager is very useful...
> 
> My other problem with it is that the methods on it are specific to the
> built in auth methods and some -- like the login and error page
> properties -- are specific to the form auth method.  I think that basic
> and digest also need a "realm" property.  So if we continue using
> AuthenticationManager I'd prefer that SecurityHandler just have a
> ServerAuthentication instance inside and anyone who wants to use the
> AuthenticationManager interface test for it.  If the
> ServerAuthentication is not an AuthenticationManager that means that
> some other authentication configuration is in place and we shouldn't try
> to set the standard methods up.
> 
> Finally.... I may not have made it clear enough that the
> [Basic|Digest|Form|ClientCert]AuthModules left over are never going to
> be used for anything except examples (maybe).... I left them there
> mostly for reference in case I forgot something in the
> ServerAuthentication implementations.
> 
> Even more finally... I want to reemphasize that I think we agree on all
> major points and if you still want the AuthenticationManager I'll still
> be very happy with the code.
> 
> many thanks
> david jencks
> 
> 
> On Nov 25, 2008, at 11:01 AM, David Jencks wrote:
> 
>> Hi Jan,
>>
>> 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?
>>
>> 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.
>>
>> 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