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, 04 Nov 2008 08:03:12 GMT
Hi David,

To help orient your responses, my efficiency concerns involve
the sequence of handling that occurs inside the FormAuthModule in tryLogin() and
in BaseAuthModule in login(). There's a few more objects being
created and methods invoked as compared with the older FormAuthenticator
handling, which had a much more direct way of interacting with the
UserRealm.  

cheers
Jan

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
> 
> 
> 


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

Mime
View raw message