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 Mon, 03 Nov 2008 17:15:25 GMT
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

(forgot reply-all on my first attempt to respond :-)

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
>


Mime
View raw message