geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [jetty-dev] Jetty Security refactoring for JASPI
Date Sat, 08 Nov 2008 09:09:45 GMT
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
>
>


Mime
View raw message