You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jan Bartel <ja...@webtide.com> on 2008/10/17 08:59:16 UTC
Re: [jetty-dev] Jetty Security refactoring for JASPI
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!
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?
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!
Jan
PS I love this code-comment in ServletCallbackHandler:
* Idiot class required by jaspi stupidity @#*($)#@&^)$@#&*$@
:)
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
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
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
>
>
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
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
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
FYI, I've done a few big checkins lately, so its worthwhile updating.
Here's the highlights:
+ updated to trunk rev 4101
+ moved almost all security-related classes out of org.mortbay.jetty and into
org.mortbay.jetty.security
+ fixed Digest auth for jaspi/non-jaspi
+ fixed duplicated B64 decoding for auth modules
+ introduced CredentialValidationCallback instead of PasswordValidationCallback
as not all credentials are just char[]
+ fixed Form validation which was incorrectly calling handlers after a redirect
I also tested (non jaspi) basic, form and digest authentication, and digest
auth with JAAS and they seem to be working just fine for all test webapps.
Next step is to test the jaspi versions of them.
cheers
Jan
Jan Bartel wrote:
> Hi David,
>
>> I chatted with Greg a bit on IRC and think I understand a little better
>> why you might like the AuthenticationManager. IIUC it takes the code
>> that sets up the standard authentication methods out of
>> WebXmlConfiguration and puts it in a component that can be set from
>> jetty.xml (although the default implementation is hardcoded). Is this
>> more or less correct?
>
> Yes it does take the code out of WebXmlConfiguration that instantiates
> the particular auth module. This is because we want there to be no
> dependencies in the main jetty code on the type of authentication system
> we're using - either jaspi or non-jaspi. As jaspi has its own set of
> basic/form/cert etc auth modules in addition to the standard jetty ones,
> then WebXmlConfiguration would somehow have to know which type to construct.
> This would then pollute WebXmlConfiguration with knowledge of jaspi. Moreover,
> the JaspiServerAuthentication class which actually seems to mediate the
> jaspi processing, and upon which the correct instance of the jaspi auth
> module needs to be set, was being constructed in WebXmlConfiguration,
> which again, polluted it with jaspi knowledge.
>
> By introducing the AuthenticationManager, the WebXmlConfiguration class
> does not need to care which type of authentication system we're using,
> as the decision on which type of auth modules to construct is taken care
> of inside the AuthenticationManager implementation - either jaspi or
> non-jaspi (which I have called for want of a better name DefaultAuthenticationManager).
> The user can opt to use jaspi authentication for his webapp in the
> standard jetty way by plugging in the JaspiAuthenticationManager in
> a context xml file to configure the WebAppContext. Here's an example from
> the test webapp, with the jaspi bit added. The following is all you need
> to do to enable jaspi (apart from ensuring the jaspi jars are on the
> classpath of course):
>
> <Configure class="org.mortbay.jetty.webapp.WebAppContext">
> ...
> <Get name="securityHandler">
> <Set name="loginService">
> <New class="org.mortbay.jetty.security.HashLoginService">
> <Set name="name">Test Realm</Set>
> <Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set>
> </New>
> </Set>
>
> <!-- START JASPI BIT
>
> <Set name="authenticationManager">
> <New class="org.mortbay.jetty.security.jaspi.JaspiAuthenticationManager">
> </New>
> </Set>
>
> END JASPI BIT -->
>
> <Set name="checkWelcomeFiles">true</Set>
> </Get>
>
> </Configure>
>
> By doing this, there is indeed now the possibility that a particular auth
> module implementation could be plugged into the AuthenticationManager.
> Eg, a specific implementation of Basic authentication could potentially
> be plugged in to an AuthenticationManager to use, rather than constructing
> its own. I don't see this necessarily being of great use for the normal
> jetty auth modules, however, it is very much in the spirit of jetty that
> we support pluggability. Jetty's philosophy is to be the least prescriptive
> as possible, provide defaults for most things, but allow the maximum
> customisability.
>
> Where I *do* see the ability to plug in a particular auth module being useful
> is in the jaspi implementation. As I understand it, we want to support
> plugging in 3rd party jaspi modules. My question to you in a previous
> email was at what level do you think that jaspi pluggability should
> be supported? Is it enough to plug in a different auth module impl
> (in the jaspi parlance a ServerAuthModule or ServerAuthContext instance)
> or do we need to make more of the jaspi machinery pluggable?
>
> As for the current AuthenticationModule implementations, I do agree
> that there could be some improvements. Particularly, I don't want to have
> a DefaultAuthenticationModule instance constructed by the ConstraintSecurityHandler
> as a default. I want it to be totally pluggable, and when the
> ConstraintSecurityHandler is started, it will only construct a DefaultAuthenticationModule
> IFF it has not been given a specific impl to use. This implies that
> these setters need to move off the AuthenticationManager interface, and
> onto the SecurityHandler interface, as an AuthenticationManager instance
> may not be in existance at the time the WebXmlConfiguration processing
> is done:
>
> + setAuthMethod(String)
> + setLoginPage(String)
> + setErrorPage(String)
> + setAllowLazyAuth(boolean) //note this is NOT derived from web.xml
>
> The authMethod used to be on the ConstraintSecurityHandler anyway, and
> the ability to control lazy authentication is, I think new,
> so I don't see moving them onto SecurityHandler as a problem. The loginPage
> and errorPage are, as you say, only relevant to the form authentication, but as
> we cannot construct a form auth module in WebXmlConfiguration to receive
> these settings without polluting WebXmlConfiguration with jaspi/on-jaspi typing,
> then I don't see any other alternative than putting them onto the SecurityHandler.
> Thoughts?
>
> BTW, I see the name field of the LoginService (aka UserRealm) was deprecated.
> Not sure how that came to pass, but I've reinstated it, and now
> the realm name can be obtained by whichever authentication system type
> from the LoginService instead.
>
> I also re-added the ability for a specific LoginService to be plugged into
> a WebAppContext, rather than insisting that WebXmlConfiguration look thru
> all the LoginServices set on the Server instance to find a matching one.
> This reinstates previous jetty behaviour.
>
> Having said all that, if you can think of a different way of achieving
> pluggability and configurability without introducing any dependencies
> on the type of the authentication system in the core jetty code,
> then I'm all ears.
>
> cheers
> Jan
>
>
>> This seems sort of like a plausible goal to me but I still have some
>> concerns...
>>
>> First of all, this is an entirely new level of flexibility beyond
>> anything previously in jetty. Jetty trunk just hardcodes the choice of
>> [Basic|Digest|Form|ClientCert]Authenticator directly in
>> WebXmlConfiguration, just like I did with the ServerAuthentication
>> replacements.
>>
>> I'm not actually sure there's any chance anyone would use this added
>> flexibility and strongly suspect there's an easier way to get there with
>> less code. I think that we should look at the plausible choices for
>> authentication:
>>
>> 1. [Basic|Digest|Form|ClientCert]ServerAuthentication -- standard,
>> known methods. I can't see why someone would reimplement all of these
>> and want to base jetty on their reimplementation rather than just
>> installing the ServerAuthentication they want per app directly (see (3)
>> below)
>> 2. A Jaspi ServerAuthModule or maybe ServerAuthContext. For instance
>> the OpenId module I wrote for geronimo or the spnego one Ron Monzillo
>> wrote. There's a sub-question of how people might like to install this
>> which I'll address later -- but we want to support jaspi somehow.
>> 3. A custom implementation of jetty's ServerAuthentication. I would
>> hope that anyone who went to the trouble to write an auth method for
>> jetty would use this easier to use more optimized interface rather than
>> the jaspi one.
>>
>> Do you see any other plausible choices?
>>
>> IIUC what your AuthenticationManager code does is make it possible to
>> supply different implementations for the
>> [Basic|Digest|Form|ClientCert]ServerAuthentication other than the ones
>> jetty ships with and configure jetty (using jetty.xml) to install these
>> instead of the standard ones. I just cant see how this would be a
>> plausible scenario. I'm happy to be convinced though...
>>
>> We still don't have code for (2). (I know you wrote
>> JaspiAuthenticationManager but its not created in code anywhere so
>> requires extra configuration -- and I haven't looked at it yet.) I've
>> been delaying writing it until we have agreement on more of the
>> interfaces.... maybe not so wise on my part :-) The official way to use
>> jaspi is rather complicated and IMO silly for jetty. You need a Jaspi
>> provider that lets the all-powerful sysadmin configure all sorts of
>> stuff including ServerAuthConfigs for specific apps. This is then saved
>> somehow by the jaspi impl ready for use by the world, indexed by
>> basically the context root of the app. Now when the app is deployed you
>> go through a bunch of classes using that context root and eventually
>> manage to extract the ServerAuthConfig for your app. The jaspi spec
>> says if there's an auth whoozits configured for your app (based on the
>> context root) then you should use it instead of the standard auth method
>> that might be configured. So we ought to support this I guess but I
>> doubt anyone will use this. What you actually need is either a
>> ServerAuthModule or ServerAuthContext and you can configure those
>> yourself and stuff them in the JaspiServerAuthentication (possibly with
>> a wrapper around them).
>>
>> So I think what I'd like to see is...
>>
>> if there's either a ServerAuthentication instance or jaspi
>> ServerAuthModule/Context/Config explicitly configured in context.xml
>> (IIUC this is the app-specific "jetty plan" for the web app) then we'll
>> use that.
>> Otherwise...
>> If there's a jaspi provider available and configured and there's
>> something configured for your app we'll use that
>> Otherwise...
>> we'll use the [Basic|Digest|Form|ClientCert]ServerAuthentication built
>> into jetty.
>>
>> So that's why I don't think the added flexibility of
>> AuthenticationManager is very useful...
>>
>> My other problem with it is that the methods on it are specific to the
>> built in auth methods and some -- like the login and error page
>> properties -- are specific to the form auth method. I think that basic
>> and digest also need a "realm" property. So if we continue using
>> AuthenticationManager I'd prefer that SecurityHandler just have a
>> ServerAuthentication instance inside and anyone who wants to use the
>> AuthenticationManager interface test for it. If the
>> ServerAuthentication is not an AuthenticationManager that means that
>> some other authentication configuration is in place and we shouldn't try
>> to set the standard methods up.
>>
>> Finally.... I may not have made it clear enough that the
>> [Basic|Digest|Form|ClientCert]AuthModules left over are never going to
>> be used for anything except examples (maybe).... I left them there
>> mostly for reference in case I forgot something in the
>> ServerAuthentication implementations.
>>
>> Even more finally... I want to reemphasize that I think we agree on all
>> major points and if you still want the AuthenticationManager I'll still
>> be very happy with the code.
>>
>> many thanks
>> david jencks
>>
>>
>> On Nov 25, 2008, at 11:01 AM, David Jencks wrote:
>>
>>> Hi Jan,
>>>
>>> I've taken a very quick look at the AuthenticationManager you've
>>> added. It looks to me (based on this very non-thorough glance) that
>>> the main effect is to move some of the auth setup code out of
>>> WebXmlConfiguration and make it more accessible to programatic setup.
>>> For instance instead of having to know to use a
>>> BasicServerAuthentication you just need to know the string "BASIC".
>>> Is this more or less correct?
>>>
>>> I like the idea of making it easier to configure authentication like
>>> this, but I think there might be a more flexible and less intrusive
>>> way. IIUC the runtime authentication behavior still works through the
>>> ServerAuthentication interface, and the added methods on
>>> AuthenticationManager are only used for setup. If someone wanted to
>>> implement their own ServerAuthentication these extra methods wouldn't
>>> really provide any extra value.
>>>
>>> What if we had something like a DefaultAuthenticationFactory that you
>>> set up with the security handler and called configure(String
>>> authMethod, String loginPage, String errorPage, String realm) on and
>>> it constructed the appropriate
>>> [Basic|Digest|Form|ClientCert]ServerAuthentication and set it in the
>>> security handler? We'd need something similar for the jaspi approach.
>>>
>>> To me this would seem to separate the configuration and runtime
>>> aspects nicely while still providing the advantages of simpler
>>> configuration of the default auth methods.
>>>
>>> I haven't looked at your jaspi code yet.... jaspi configuration is a
>>> bit convoluted IMNSHO and I actually suspect anyone using a jaspi
>>> module may want to set it up directly in code rather than dealing with
>>> a whole jaspi provider (which I wrote for geronimo but not jetty
>>> specifically) I'll look at this in a bit.
>>>
>>> Moving the login services seems like a very good idea :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>> On Nov 25, 2008, at 8:53 AM, Jan Bartel wrote:
>>>
>>>> Hi David,
>>>>
>>>> I've made some changes to attempt to make jaspi vs non-jaspi
>>>> authentication pluggable. I've checked the changes in, as I
>>>> thought it is easier to see the code than talk about it.
>>>>
>>>> In a nutshell, I've introduced an AuthenticationManager that
>>>> is used by a SecurityHandler to carry out all authentication,
>>>> and which delegates to either a non-jaspi or jaspi implementation.
>>>>
>>>> The ConstraintSecurityHandler uses a DefaultAuthenticationManager
>>>> (non-jaspi) by default, but one can plug in the
>>>> JaspiAuthenticationManager
>>>> as an alternative.
>>>>
>>>> The WebXmlConfiguration sets up information from the web.xml such
>>>> as the auth method and login/error pages on the AuthenticationManager,
>>>> but no longer sets up the various auth modules such as Basic, Form, Cert
>>>> etc. That is now done by the AuthenticationManager instance instead when
>>>> it is started, based on the auth information passed into it by the
>>>> WebXmlConfiguration
>>>> (or programmatically of course).
>>>>
>>>> I've allowed for the JaspiAuthenticationManager to plugin a jaspi
>>>> auth module,
>>>> so that potentially we can plug in 3rd party jaspi auth modules. The
>>>> question is,
>>>> is the pluggability at the right level? That is, I've allowed a
>>>> ServerAuth instance
>>>> to be set on the JaspiAuthenticationManager, but the
>>>> JaspiServerAuthentication
>>>> class expects a ServerAuthContext instead (which all of the FormAuth,
>>>> BasicAuth
>>>> etc classes implement) - would a 3rd party jaspi module be likely to
>>>> implement
>>>> that interface? Should we be allowing for plugging in some other
>>>> class entirely?
>>>>
>>>> BTW I changed around a couple of packages, most notably the
>>>> HashLoginService and
>>>> JDBCLoginService I moved out of
>>>> org.mortbay.jetty.security.jaspi.modules and into
>>>> org.mortbay.jetty.security, as AFAICT they are not jaspi specific.
>>>>
>>>> I noticed along the way that the SSO stuff isn't really hooked up.
>>>> Difficult to
>>>> see how to shoe-horn that into the new structure. Perhaps its time to
>>>> ditch it
>>>> and allow for integration with "real" SSO implementations instead?
>>>>
>>>> The jaspi branch builds and tests without error, but I'm just chasing
>>>> down an
>>>> error when running the test webapp:
>>>>
>>>> Failed startup of context
>>>> org.mortbay.jetty.webapp.WebAppContext@1e59128{/,/home/janb/src/jetty-jaspi/webapps/test}
>>>>
>>>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>>>> content-administrator, known roles: []
>>>>
>>>> And the same for the test-jaas webapp:
>>>>
>>>> Failed startup of context
>>>> org.mortbay.jetty.webapp.WebAppContext@10ffb38{/test-jaas,file:/home/janb/src/jetty-jaspi/webapps/test-jaas/}
>>>>
>>>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>>>> roleA, known roles: []
>>>>
>>>> Looks like something amiss with the role merging, perhaps.
>>>>
>>>> Have a look at what I've committed, and please let me know what you
>>>> think. I'm all ears if
>>>> you've got any suggestions or a better way.
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>>
>>>>
>>>> Jan Bartel wrote:
>>>>> David,
>>>>> [snip]
>>>>>>>>> BTW, the code needs to be reformatted to jetty standard
>>>>>>>>> conventions
>>>>>>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>>>>>>>>> gregw will have conniptions ;)
>>>>>>>> hmm.... I thought I'd done pretty well imitating the code style.
>>>>>>>> Do you
>>>>>>>> have some way to fix it automatically?
>>>>>>> Lemme see ... as far as the brackets go, I have an eclipse codestyle
>>>>>>> that I can apply to each file, but the rigorous naming of data
>>>>>>> members
>>>>>>> with leading _
>>>>>>> or __ would have to be done manually.
>>>>>> aha.... I can fix that, probably tomorrow. The brackets might be
>>>>>> tougher for me.
>>>>> I've reformatted and checked in classes in jetty and jetty-security
>>>>> packages.
>>>>>
>>>>>>> Correct me if I'm wrong, but the constraint preprocessing
>>>>>>> behaviour is
>>>>>>> separable
>>>>>>> from the jaspi authentication, so we could make that common between a
>>>>>>> ConstraintSecurityHandler
>>>>>>> that invoked non-jaspi authentication and another
>>>>>>> ConstraintSecurityHandler that invoked
>>>>>>> jaspi authentication?
>>>>>> The authentication (jaspi or ServerAuthentication) and authorization
>>>>>> (constraints or jacc or....??) are completely separable, but I would
>>>>>> not try to guarantee that the behavior of the legacy constraint
>>>>>> security
>>>>>> handler would be unchanged if we combined the constraints up
>>>>>> front. If
>>>>>> you guys are willing to risk that the legacy behavior will change or
>>>>>> analyze it carefully enough so you're sure it won't, combining the
>>>>>> constraints up front would really simplify the code. I don't
>>>>>> understand
>>>>>> how the legacy code works well enough to be comfortable claiming
>>>>>> anything about it.
>>>>> Well, I think the existing "legacy" code is a bit difficult to
>>>>> understand,
>>>>> which is why I think it is clearer to go with your new structure that
>>>>> does the preprocessing.
>>>>>
>>>>>
>>>>>>> In terms of pluggability, I think so far I'm still leaning towards a
>>>>>>> default of current
>>>>>>> jetty authentication impl, with pluggability of the jaspi impl
>>>>>>> (probably via plugging in a
>>>>>>> JaspiConstraintSecurityHandler).
>>>>>> not sure what you mean here.... if you don't want to use the
>>>>>> ServerAuthentication, RunAsToken, and UserIdentity abstractions it may
>>>>>> be difficult to switch back and forth. If you mean you want to use
>>>>>> the
>>>>>> [Basic|Digest|Form|ClientCert]ServerAuthentication implementations for
>>>>>> the known auth methods rather than the jaspi modules, I wholeheartedly
>>>>>> agree.
>>>>> What gregw has been discussing with me is the possibility to retain the
>>>>> existing jetty-7 authorization code, making judicious changes as
>>>>> necessary
>>>>> in order to permit a jaspi-flavoured implementation to be plugged in by
>>>>> choice. The new jaspi stuff could be debugged, profiled and generally
>>>>> kicked around a bit more until we could be comfortable that its at
>>>>> least as correct and performant (in the sense of least object creation
>>>>> per request, lazy auth all in the right places etc) so that it could
>>>>> then move to being the default authorization impl.
>>>>>
>>>>> Hence, a couple of emails ago I was starting to sketch out some
>>>>> ideas of how we could achieve that, but the code base has moved on
>>>>> somewhat since then, so I'm not sure how applicable those nascent ideas
>>>>> still are until I get a better grip on the changes.
>>>>>
>>>>> cheers
>>>>> Jan
>>>>>
>>>>>
>>>>>>> BTW, thanks for putting so much work into the security refactoring!
>>>>>> np!
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>>
>>>>>>>> thanks!
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>>> David Jencks wrote:
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> I rewrote the standard auth methods as ServerAuthentication
>>>>>>>>>> classes on
>>>>>>>>>> the plane ride home. I implemented Lazy and Caching (in
>>>>>>>>>> session and
>>>>>>>>>> SSO) as wrappers. Seems to compile but I haven't tried the tck
>>>>>>>>>> yet.
>>>>>>>>>>
>>>>>>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>>>>>>> timeouts?? but
>>>>>>>>>> I think this is a lot more plausible than the pure jaspi
>>>>>>>>>> implementations.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>
>>>>>>>>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>>>>>>>>
>>>>>>>>>>> I share your concerns about efficiency of the jaspi model,
>>>>>>>>>>> which is
>>>>>>>>>>> why I tried to put another hopefully efficient layer of
>>>>>>>>>>> interfaces in
>>>>>>>>>>> between the AbstractSecurityHandler and the jaspi auth
>>>>>>>>>>> modules. I
>>>>>>>>>>> was
>>>>>>>>>>> hoping that we could simply implement the known auth methods
>>>>>>>>>>> (FORM,
>>>>>>>>>>> BASIC,...) in terms of the ServerAuthentication interface
>>>>>>>>>>> directly
>>>>>>>>>>> and retain all possible efficiencies. Not having done it yet
>>>>>>>>>>> I might
>>>>>>>>>>> have missed some important points :-)
>>>>>>>>>>>
>>>>>>>>>>> I'll think some more about your comments and get back to you.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>>>>>>> give some more detailed comments.
>>>>>>>>>>>>
>>>>>>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>>>>>>> like very much the refactoring of
>>>>>>>>>>>> Abstract/ConstraintSecurityHandler
>>>>>>>>>>>> methods.
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>>>>>>> coming :)
>>>>>>>>>>>>
>>>>>>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>>>>>>> is a role restriction will result in the user being fully
>>>>>>>>>>>> reauthenticated. I understand that even this is an
>>>>>>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>>>>>>> requires validateRequest to be called on each and every
>>>>>>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>>>>>>> authentication when there are no role constraints is another
>>>>>>>>>>>> good optimization.
>>>>>>>>>>>>
>>>>>>>>>>>> As there is going to be more authenticating going on as
>>>>>>>>>>>> compared with the previous situation, my next reservation
>>>>>>>>>>>> takes on more significance, and that is the amount of
>>>>>>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>>>>>>> callback design.
>>>>>>>>>>>>
>>>>>>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>>>>>>
>>>>>>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>>>>>>> in mind?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>>>>>>> without code to show.
>>>>>>>>>>>>
>>>>>>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>>>>>>> to modify some of the interfaces of UserIdentity and
>>>>>>>>>>>> LoginService
>>>>>>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>>>>>>> things a little:
>>>>>>>>>>>>
>>>>>>>>>>>> UserIdentity
>>>>>>>>>>>> ------------
>>>>>>>>>>>> Principal getUserPrincipal()
>>>>>>>>>>>> String getAuthMethod()
>>>>>>>>>>>> boolean isUserInRole(String role)
>>>>>>>>>>>> setRunAsRole(RunAsToken)
>>>>>>>>>>>> setServletHandler(ServletHandler)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> UserRealm (was LoginService)
>>>>>>>>>>>> ---------
>>>>>>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SecurityManager
>>>>>>>>>>>> --------------
>>>>>>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>>>>>>> ----------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>>>>>>> --------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> AbstractSecurityHandler
>>>>>>>>>>>> ----------------------
>>>>>>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>>>>>>
>>>>>>>>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>>>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>>>>>>> where it currently invokes
>>>>>>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>>>>>>> (around line 169).
>>>>>>>>>>>>
>>>>>>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>>>>>>> authenticator
>>>>>>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>>>>> did in the pre-jaspi version.
>>>>>>>>>>>>
>>>>>>>>>>>> The JaspiSecurityManager implementation would be equivalent
>>>>>>>>>>>> to the
>>>>>>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>>>>>>
>>>>>>>>>>>> Perhaps the biggest change would be to the LoginService,
>>>>>>>>>>>> which I've
>>>>>>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>>>>>>> authentication related, rather than strictly login related. No
>>>>>>>>>>>> problem though
>>>>>>>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>>>>>>>> method
>>>>>>>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>>>>>>>> LoginCallback
>>>>>>>>>>>> instance on the Subject (via the ServletCallbackHandler). I
>>>>>>>>>>>> don't
>>>>>>>>>>>> see that as a major problem - the ServletCallbackHandler
>>>>>>>>>>>> could set
>>>>>>>>>>>> the UserIdentity object on the Subject instead. Note that in
>>>>>>>>>>>> a jaspi
>>>>>>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>>>>>>> called, or
>>>>>>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>>>>>>
>>>>>>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>>>>>>> I think we'd need another set for the default jetty
>>>>>>>>>>>> implementation
>>>>>>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>>>>>>> duplication
>>>>>>>>>>>> would be highly desirable.
>>>>>>>>>>>>
>>>>>>>>>>>> From the user's perspective, it would be simple to configure
>>>>>>>>>>>> jaspi:
>>>>>>>>>>>>
>>>>>>>>>>>> WebAppContext webApp = ...;
>>>>>>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>>>>>>> JaspiSecurityManager());
>>>>>>>>>>>>
>>>>>>>>>>>> I'm sure I haven't considered all aspects of pluggability.
>>>>>>>>>>>> I'll try
>>>>>>>>>>>> and get some time to turn the thoughts into code, which are
>>>>>>>>>>>> a) more
>>>>>>>>>>>> easily
>>>>>>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>>>>>>
>>>>>>>>>>>> cheers
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>>>>>>
>>>>>>>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>>>>>>>> future,
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> 259.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>>>>>>> again on
>>>>>>>>>>>>>> the right connector (either the confidential or integral
>>>>>>>>>>>>>> port as
>>>>>>>>>>>>>> appropriate).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>>>>>>>>> noticed
>>>>>>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>>>>>>> notices the request was received on the wrong connector
>>>>>>>>>>>>>>>> (ie on
>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>>>> https) and does a redirect, the
>>>>>>>>>>>>>>>> AbstractSecurityHandler.handle()
>>>>>>>>>>>>>>>> method goes
>>>>>>>>>>>>>>>> ahead and subjects the request to JASPI authentication.
>>>>>>>>>>>>>>>> It seems
>>>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>>>>>>> altogether. It
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> be the redirected request that we're interested in
>>>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>>>> further
>>>>>>>>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>>>>>>> base_request.setHandled(true);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think there's something odd here, but IIUC something
>>>>>>>>>>>>>>> other than
>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>> you see.
>>>>>>>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>> I've been worrying about this because it prevents redirecting
>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>> requests to the equivalent https requests. Until recently I
>>>>>>>>>>>>>>> didn't
>>>>>>>>>>>>>>> think it was possible to do this redirect using jacc
>>>>>>>>>>>>>>> permissions
>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>> think there is a solution....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If the actual request is denied and is http we could
>>>>>>>>>>>>>>> create a new
>>>>>>>>>>>>>>> request with the url converted to https and
>>>>>>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>>>>>>> it.... if that check succeeds we can redirect to the more
>>>>>>>>>>>>>>> secure
>>>>>>>>>>>>>>> url.
>>>>>>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>>>>>>> authentication is
>>>>>>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>> unauthenticated user.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the
>>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are
>>>>>>>>>>>>>>>>>> quasi
>>>>>>>>>>>>>>>>>> analogous
>>>>>>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour has
>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to
>>>>>>>>>>>>>>>>>> retain
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>>>>>>>> understand the
>>>>>>>>>>>>>>>>> new code, I rather think it would be confusing. I'd really
>>>>>>>>>>>>>>>>> rather not
>>>>>>>>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> depending
>>>>>>>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>> things. The main point of introducing it was that in jetty
>>>>>>>>>>>>>>>>> integrations
>>>>>>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the
>>>>>>>>>>>>>>>>> UserPrincipal was
>>>>>>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>>>>>>> non-principal
>>>>>>>>>>>>>>>>> information associated with the user's identity. I
>>>>>>>>>>>>>>>>> think that
>>>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>>>>>>> whatever else the security system needs. I don't have
>>>>>>>>>>>>>>>>> strong
>>>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>>>> to calling the LoginService UserRealm but I think its going
>>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be
>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>> important for
>>>>>>>>>>>>>>>>>> Jetty users to be able to make a smooth transition over
>>>>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm
>>>>>>>>>>>>>>>>>> and a
>>>>>>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer and
>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>> descriptive for embedding jetty that the old ones. I could
>>>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>>>>>>> LoginService to
>>>>>>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>> I'm not
>>>>>>>>>>>>>>>>> at all sure the non login-service methods on UserRealm
>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>> plausibly
>>>>>>>>>>>>>>>>> be called.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>>>>> (well,
>>>>>>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>>>>>>> WebAppContext.getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>>>>>>> LoginService is
>>>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler,
>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>> line 1042
>>>>>>>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this code
>>>>>>>>>>>>>>>>> much...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of
>>>>>>>>>>>>>>>>>> callbacks it
>>>>>>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>>>>> the right info, such as credentials, passwords,
>>>>>>>>>>>>>>>>>> usernames and
>>>>>>>>>>>>>>>>>> also extra request parameters from the login. I notice
>>>>>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler
>>>>>>>>>>>>>>>>>> instead? It
>>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I
>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>>>>>>>>> extracting
>>>>>>>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>>>>>>> service. A
>>>>>>>>>>>>>>>>> login module that fishes directly in the request ought
>>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>>> refactored
>>>>>>>>>>>>>>>>> into a plain login module that just validates the
>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>> and an
>>>>>>>>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>>>>>>>>> Despite all
>>>>>>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and
>>>>>>>>>>>>>>>>> worth
>>>>>>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I guess someone who really really wanted to preserve their
>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>>>> could write a subclass of LoginCallback that dealt with
>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>> parameters, and a JAASLoginService subclass. This would be
>>>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>>> easier
>>>>>>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>>>>>>>>> marker
>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>>>>>>> mappings
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>>>>>> This is an embedding thing also. It's pretty unclear what
>>>>>>>>>>>>>>>>> run-as is
>>>>>>>>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>>>>>>>>> identity for
>>>>>>>>>>>>>>>>> a web service client or other remote call is supposed to
>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>> (If the
>>>>>>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>>>>>>> credentials does
>>>>>>>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>>>>>>>> represent the
>>>>>>>>>>>>>>>>> run-as role by a Subject obtained by logging into a
>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>> realm. So,
>>>>>>>>>>>>>>>>> the geronimo run-as token has this Subject in it. We might
>>>>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't
>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>> constraining the representation of the run-as identity
>>>>>>>>>>>>>>>>> is wise.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>>>>>>>>> more or
>>>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>>>> agree on the main interfaces, at which time I plan to
>>>>>>>>>>>>>>>>> rewrite
>>>>>>>>>>>>>>>>> them in
>>>>>>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and
>>>>>>>>>>>>>>>>>>>> light on
>>>>>>>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi branch,
>>>>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey
>>>>>>>>>>>>>>>>>>>> around, where
>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in
>>>>>>>>>>>>>>>>>>> modules/plus/jetty-plus
>>>>>>>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to
>>>>>>>>>>>>>>>>>>>> you with
>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you that
>>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>>>>>> them back into more jetty specific code. Of course if
>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity
>>>>>>>>>>>>>>>>>>>> @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>>>>>>> on at the end when someone realized it was incomplete,
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>>>>>>> of CallbackHandler for two way communication between the
>>>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for
>>>>>>>>>>>>>>>>>>>>> me to
>>>>>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>>>>>>> integration with jetty and its getting to a point
>>>>>>>>>>>>>>>>>>>>> where I'm
>>>>>>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for
>>>>>>>>>>>>>>>>>>>>> messaging
>>>>>>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> client you can add auth info to a request and
>>>>>>>>>>>>>>>>>>>>> validate auth
>>>>>>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>>>> response. On the server you can validate auth info
>>>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and
>>>>>>>>>>>>>>>>>>>>> transmit the
>>>>>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal for
>>>>>>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi
>>>>>>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it
>>>>>>>>>>>>>>>>>>>>> is more
>>>>>>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>>>>>>> integration with other app servers with their own ideas
>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to
>>>>>>>>>>>>>>>>>>>>> verify
>>>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response
>>>>>>>>>>>>>>>>>>>>> pair on
>>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle. This
>>>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>>>>>>> method that runs through the following structure
>>>>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the
>>>>>>>>>>>>>>>>>>>>> user data
>>>>>>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>>>>>>> basically that the request arrived over the right
>>>>>>>>>>>>>>>>>>>>> kind of
>>>>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this
>>>>>>>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>> jetty constraint based implementation or one based
>>>>>>>>>>>>>>>>>>>>> on JACC.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>> we can often delay authentication until a method
>>>>>>>>>>>>>>>>>>>>> relying on
>>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory
>>>>>>>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass
>>>>>>>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will
>>>>>>>>>>>>>>>>>>>>> extract the
>>>>>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided
>>>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash,
>>>>>>>>>>>>>>>>>>>>> JDBC, etc
>>>>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>>>>>>> authentication when info is actually needed. In this
>>>>>>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this
>>>>>>>>>>>>>>>>>>>>> includes
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>>>>>>> UserIdentity userIdentity =
>>>>>>>>>>>>>>>>>>>>> newUserIdentity(authResult);
>>>>>>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however they
>>>>>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext,
>>>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now
>>>>>>>>>>>>>>>>>>>>> secure
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework
>>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>>>>>>> (rather than the bits actually needed for http which I
>>>>>>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>>>>>>> and have a nearly-untested openid implementation.
>>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an
>>>>>>>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just
>>>>>>>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>>>> workflow described about and delegates all actual
>>>>>>>>>>>>>>>>>>>>> work to
>>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> authentication delegate. This makes it easy to plug in
>>>>>>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly
>>>>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a
>>>>>>>>>>>>>>>>>>>>> Principal
>>>>>>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity
>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>>>>>>> separate access to the auth results (user principal)
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> interface. These typically delegate to
>>>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy
>>>>>>>>>>>>>>>>>>>>> authentication if
>>>>>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated
>>>>>>>>>>>>>>>>>>>>> functions,
>>>>>>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the
>>>>>>>>>>>>>>>>>>>>> credential
>>>>>>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>>>>>>> in LoginService. Credential validation may not even be
>>>>>>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from
>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> extracts credentials from the request.
>>>>>>>>>>>>>>>>>>>>> Implementations are
>>>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>>>>>>> On the other hand the role handling is called by jetty
>>>>>>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService
>>>>>>>>>>>>>>>>>>>>> relate to
>>>>>>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>>>>>> subject)
>>>>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication
>>>>>>>>>>>>>>>>>>>>> packages
>>>>>>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal and
>>>>>>>>>>>>>>>>>>>>> group
>>>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication
>>>>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or.... you
>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>>>>>>> and stuff it into an adapter,
>>>>>>>>>>>>>>>>>>>>> JaspiServerAuthentication.
>>>>>>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>> ServerAuthModule implementations (a
>>>>>>>>>>>>>>>>>>>>> ServerAuthContext is
>>>>>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which
>>>>>>>>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of
>>>>>>>>>>>>>>>>>>>>> asking for
>>>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies the
>>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing
>>>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the
>>>>>>>>>>>>>>>>>>>>> server:
>>>>>>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller
>>>>>>>>>>>>>>>>>>>>> principal so
>>>>>>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user
>>>>>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird
>>>>>>>>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging,
>>>>>>>>>>>>>>>>>>>>> including ejb
>>>>>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>>>>>>> normally not a secured response. Trying to evaluate
>>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the
>>>>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I don't see how this implementation could be
>>>>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time
>>>>>>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>>>> I can see that is possible with constraint
>>>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request to
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>>>>>>> https request if a user data constraint is
>>>>>>>>>>>>>>>>>>>>> violated. I'm
>>>>>>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>> whether this is something people want to do or
>>>>>>>>>>>>>>>>>>>>> usually set
>>>>>>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
--
Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
Hi David,
> I chatted with Greg a bit on IRC and think I understand a little better
> why you might like the AuthenticationManager. IIUC it takes the code
> that sets up the standard authentication methods out of
> WebXmlConfiguration and puts it in a component that can be set from
> jetty.xml (although the default implementation is hardcoded). Is this
> more or less correct?
Yes it does take the code out of WebXmlConfiguration that instantiates
the particular auth module. This is because we want there to be no
dependencies in the main jetty code on the type of authentication system
we're using - either jaspi or non-jaspi. As jaspi has its own set of
basic/form/cert etc auth modules in addition to the standard jetty ones,
then WebXmlConfiguration would somehow have to know which type to construct.
This would then pollute WebXmlConfiguration with knowledge of jaspi. Moreover,
the JaspiServerAuthentication class which actually seems to mediate the
jaspi processing, and upon which the correct instance of the jaspi auth
module needs to be set, was being constructed in WebXmlConfiguration,
which again, polluted it with jaspi knowledge.
By introducing the AuthenticationManager, the WebXmlConfiguration class
does not need to care which type of authentication system we're using,
as the decision on which type of auth modules to construct is taken care
of inside the AuthenticationManager implementation - either jaspi or
non-jaspi (which I have called for want of a better name DefaultAuthenticationManager).
The user can opt to use jaspi authentication for his webapp in the
standard jetty way by plugging in the JaspiAuthenticationManager in
a context xml file to configure the WebAppContext. Here's an example from
the test webapp, with the jaspi bit added. The following is all you need
to do to enable jaspi (apart from ensuring the jaspi jars are on the
classpath of course):
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
...
<Get name="securityHandler">
<Set name="loginService">
<New class="org.mortbay.jetty.security.HashLoginService">
<Set name="name">Test Realm</Set>
<Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set>
</New>
</Set>
<!-- START JASPI BIT
<Set name="authenticationManager">
<New class="org.mortbay.jetty.security.jaspi.JaspiAuthenticationManager">
</New>
</Set>
END JASPI BIT -->
<Set name="checkWelcomeFiles">true</Set>
</Get>
</Configure>
By doing this, there is indeed now the possibility that a particular auth
module implementation could be plugged into the AuthenticationManager.
Eg, a specific implementation of Basic authentication could potentially
be plugged in to an AuthenticationManager to use, rather than constructing
its own. I don't see this necessarily being of great use for the normal
jetty auth modules, however, it is very much in the spirit of jetty that
we support pluggability. Jetty's philosophy is to be the least prescriptive
as possible, provide defaults for most things, but allow the maximum
customisability.
Where I *do* see the ability to plug in a particular auth module being useful
is in the jaspi implementation. As I understand it, we want to support
plugging in 3rd party jaspi modules. My question to you in a previous
email was at what level do you think that jaspi pluggability should
be supported? Is it enough to plug in a different auth module impl
(in the jaspi parlance a ServerAuthModule or ServerAuthContext instance)
or do we need to make more of the jaspi machinery pluggable?
As for the current AuthenticationModule implementations, I do agree
that there could be some improvements. Particularly, I don't want to have
a DefaultAuthenticationModule instance constructed by the ConstraintSecurityHandler
as a default. I want it to be totally pluggable, and when the
ConstraintSecurityHandler is started, it will only construct a DefaultAuthenticationModule
IFF it has not been given a specific impl to use. This implies that
these setters need to move off the AuthenticationManager interface, and
onto the SecurityHandler interface, as an AuthenticationManager instance
may not be in existance at the time the WebXmlConfiguration processing
is done:
+ setAuthMethod(String)
+ setLoginPage(String)
+ setErrorPage(String)
+ setAllowLazyAuth(boolean) //note this is NOT derived from web.xml
The authMethod used to be on the ConstraintSecurityHandler anyway, and
the ability to control lazy authentication is, I think new,
so I don't see moving them onto SecurityHandler as a problem. The loginPage
and errorPage are, as you say, only relevant to the form authentication, but as
we cannot construct a form auth module in WebXmlConfiguration to receive
these settings without polluting WebXmlConfiguration with jaspi/on-jaspi typing,
then I don't see any other alternative than putting them onto the SecurityHandler.
Thoughts?
BTW, I see the name field of the LoginService (aka UserRealm) was deprecated.
Not sure how that came to pass, but I've reinstated it, and now
the realm name can be obtained by whichever authentication system type
from the LoginService instead.
I also re-added the ability for a specific LoginService to be plugged into
a WebAppContext, rather than insisting that WebXmlConfiguration look thru
all the LoginServices set on the Server instance to find a matching one.
This reinstates previous jetty behaviour.
Having said all that, if you can think of a different way of achieving
pluggability and configurability without introducing any dependencies
on the type of the authentication system in the core jetty code,
then I'm all ears.
cheers
Jan
>
> This seems sort of like a plausible goal to me but I still have some
> concerns...
>
> First of all, this is an entirely new level of flexibility beyond
> anything previously in jetty. Jetty trunk just hardcodes the choice of
> [Basic|Digest|Form|ClientCert]Authenticator directly in
> WebXmlConfiguration, just like I did with the ServerAuthentication
> replacements.
>
> I'm not actually sure there's any chance anyone would use this added
> flexibility and strongly suspect there's an easier way to get there with
> less code. I think that we should look at the plausible choices for
> authentication:
>
> 1. [Basic|Digest|Form|ClientCert]ServerAuthentication -- standard,
> known methods. I can't see why someone would reimplement all of these
> and want to base jetty on their reimplementation rather than just
> installing the ServerAuthentication they want per app directly (see (3)
> below)
> 2. A Jaspi ServerAuthModule or maybe ServerAuthContext. For instance
> the OpenId module I wrote for geronimo or the spnego one Ron Monzillo
> wrote. There's a sub-question of how people might like to install this
> which I'll address later -- but we want to support jaspi somehow.
> 3. A custom implementation of jetty's ServerAuthentication. I would
> hope that anyone who went to the trouble to write an auth method for
> jetty would use this easier to use more optimized interface rather than
> the jaspi one.
>
> Do you see any other plausible choices?
>
> IIUC what your AuthenticationManager code does is make it possible to
> supply different implementations for the
> [Basic|Digest|Form|ClientCert]ServerAuthentication other than the ones
> jetty ships with and configure jetty (using jetty.xml) to install these
> instead of the standard ones. I just cant see how this would be a
> plausible scenario. I'm happy to be convinced though...
>
> We still don't have code for (2). (I know you wrote
> JaspiAuthenticationManager but its not created in code anywhere so
> requires extra configuration -- and I haven't looked at it yet.) I've
> been delaying writing it until we have agreement on more of the
> interfaces.... maybe not so wise on my part :-) The official way to use
> jaspi is rather complicated and IMO silly for jetty. You need a Jaspi
> provider that lets the all-powerful sysadmin configure all sorts of
> stuff including ServerAuthConfigs for specific apps. This is then saved
> somehow by the jaspi impl ready for use by the world, indexed by
> basically the context root of the app. Now when the app is deployed you
> go through a bunch of classes using that context root and eventually
> manage to extract the ServerAuthConfig for your app. The jaspi spec
> says if there's an auth whoozits configured for your app (based on the
> context root) then you should use it instead of the standard auth method
> that might be configured. So we ought to support this I guess but I
> doubt anyone will use this. What you actually need is either a
> ServerAuthModule or ServerAuthContext and you can configure those
> yourself and stuff them in the JaspiServerAuthentication (possibly with
> a wrapper around them).
>
> So I think what I'd like to see is...
>
> if there's either a ServerAuthentication instance or jaspi
> ServerAuthModule/Context/Config explicitly configured in context.xml
> (IIUC this is the app-specific "jetty plan" for the web app) then we'll
> use that.
> Otherwise...
> If there's a jaspi provider available and configured and there's
> something configured for your app we'll use that
> Otherwise...
> we'll use the [Basic|Digest|Form|ClientCert]ServerAuthentication built
> into jetty.
>
> So that's why I don't think the added flexibility of
> AuthenticationManager is very useful...
>
> My other problem with it is that the methods on it are specific to the
> built in auth methods and some -- like the login and error page
> properties -- are specific to the form auth method. I think that basic
> and digest also need a "realm" property. So if we continue using
> AuthenticationManager I'd prefer that SecurityHandler just have a
> ServerAuthentication instance inside and anyone who wants to use the
> AuthenticationManager interface test for it. If the
> ServerAuthentication is not an AuthenticationManager that means that
> some other authentication configuration is in place and we shouldn't try
> to set the standard methods up.
>
> Finally.... I may not have made it clear enough that the
> [Basic|Digest|Form|ClientCert]AuthModules left over are never going to
> be used for anything except examples (maybe).... I left them there
> mostly for reference in case I forgot something in the
> ServerAuthentication implementations.
>
> Even more finally... I want to reemphasize that I think we agree on all
> major points and if you still want the AuthenticationManager I'll still
> be very happy with the code.
>
> many thanks
> david jencks
>
>
> On Nov 25, 2008, at 11:01 AM, David Jencks wrote:
>
>> Hi Jan,
>>
>> I've taken a very quick look at the AuthenticationManager you've
>> added. It looks to me (based on this very non-thorough glance) that
>> the main effect is to move some of the auth setup code out of
>> WebXmlConfiguration and make it more accessible to programatic setup.
>> For instance instead of having to know to use a
>> BasicServerAuthentication you just need to know the string "BASIC".
>> Is this more or less correct?
>>
>> I like the idea of making it easier to configure authentication like
>> this, but I think there might be a more flexible and less intrusive
>> way. IIUC the runtime authentication behavior still works through the
>> ServerAuthentication interface, and the added methods on
>> AuthenticationManager are only used for setup. If someone wanted to
>> implement their own ServerAuthentication these extra methods wouldn't
>> really provide any extra value.
>>
>> What if we had something like a DefaultAuthenticationFactory that you
>> set up with the security handler and called configure(String
>> authMethod, String loginPage, String errorPage, String realm) on and
>> it constructed the appropriate
>> [Basic|Digest|Form|ClientCert]ServerAuthentication and set it in the
>> security handler? We'd need something similar for the jaspi approach.
>>
>> To me this would seem to separate the configuration and runtime
>> aspects nicely while still providing the advantages of simpler
>> configuration of the default auth methods.
>>
>> I haven't looked at your jaspi code yet.... jaspi configuration is a
>> bit convoluted IMNSHO and I actually suspect anyone using a jaspi
>> module may want to set it up directly in code rather than dealing with
>> a whole jaspi provider (which I wrote for geronimo but not jetty
>> specifically) I'll look at this in a bit.
>>
>> Moving the login services seems like a very good idea :-)
>>
>> thanks
>> david jencks
>>
>>
>> On Nov 25, 2008, at 8:53 AM, Jan Bartel wrote:
>>
>>> Hi David,
>>>
>>> I've made some changes to attempt to make jaspi vs non-jaspi
>>> authentication pluggable. I've checked the changes in, as I
>>> thought it is easier to see the code than talk about it.
>>>
>>> In a nutshell, I've introduced an AuthenticationManager that
>>> is used by a SecurityHandler to carry out all authentication,
>>> and which delegates to either a non-jaspi or jaspi implementation.
>>>
>>> The ConstraintSecurityHandler uses a DefaultAuthenticationManager
>>> (non-jaspi) by default, but one can plug in the
>>> JaspiAuthenticationManager
>>> as an alternative.
>>>
>>> The WebXmlConfiguration sets up information from the web.xml such
>>> as the auth method and login/error pages on the AuthenticationManager,
>>> but no longer sets up the various auth modules such as Basic, Form, Cert
>>> etc. That is now done by the AuthenticationManager instance instead when
>>> it is started, based on the auth information passed into it by the
>>> WebXmlConfiguration
>>> (or programmatically of course).
>>>
>>> I've allowed for the JaspiAuthenticationManager to plugin a jaspi
>>> auth module,
>>> so that potentially we can plug in 3rd party jaspi auth modules. The
>>> question is,
>>> is the pluggability at the right level? That is, I've allowed a
>>> ServerAuth instance
>>> to be set on the JaspiAuthenticationManager, but the
>>> JaspiServerAuthentication
>>> class expects a ServerAuthContext instead (which all of the FormAuth,
>>> BasicAuth
>>> etc classes implement) - would a 3rd party jaspi module be likely to
>>> implement
>>> that interface? Should we be allowing for plugging in some other
>>> class entirely?
>>>
>>> BTW I changed around a couple of packages, most notably the
>>> HashLoginService and
>>> JDBCLoginService I moved out of
>>> org.mortbay.jetty.security.jaspi.modules and into
>>> org.mortbay.jetty.security, as AFAICT they are not jaspi specific.
>>>
>>> I noticed along the way that the SSO stuff isn't really hooked up.
>>> Difficult to
>>> see how to shoe-horn that into the new structure. Perhaps its time to
>>> ditch it
>>> and allow for integration with "real" SSO implementations instead?
>>>
>>> The jaspi branch builds and tests without error, but I'm just chasing
>>> down an
>>> error when running the test webapp:
>>>
>>> Failed startup of context
>>> org.mortbay.jetty.webapp.WebAppContext@1e59128{/,/home/janb/src/jetty-jaspi/webapps/test}
>>>
>>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>>> content-administrator, known roles: []
>>>
>>> And the same for the test-jaas webapp:
>>>
>>> Failed startup of context
>>> org.mortbay.jetty.webapp.WebAppContext@10ffb38{/test-jaas,file:/home/janb/src/jetty-jaspi/webapps/test-jaas/}
>>>
>>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>>> roleA, known roles: []
>>>
>>> Looks like something amiss with the role merging, perhaps.
>>>
>>> Have a look at what I've committed, and please let me know what you
>>> think. I'm all ears if
>>> you've got any suggestions or a better way.
>>>
>>> cheers
>>> Jan
>>>
>>>
>>>
>>> Jan Bartel wrote:
>>>> David,
>>>> [snip]
>>>>>>>> BTW, the code needs to be reformatted to jetty standard
>>>>>>>> conventions
>>>>>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>>>>>>>> gregw will have conniptions ;)
>>>>>>> hmm.... I thought I'd done pretty well imitating the code style.
>>>>>>> Do you
>>>>>>> have some way to fix it automatically?
>>>>>> Lemme see ... as far as the brackets go, I have an eclipse codestyle
>>>>>> that I can apply to each file, but the rigorous naming of data
>>>>>> members
>>>>>> with leading _
>>>>>> or __ would have to be done manually.
>>>>> aha.... I can fix that, probably tomorrow. The brackets might be
>>>>> tougher for me.
>>>>
>>>> I've reformatted and checked in classes in jetty and jetty-security
>>>> packages.
>>>>
>>>>>> Correct me if I'm wrong, but the constraint preprocessing
>>>>>> behaviour is
>>>>>> separable
>>>>>> from the jaspi authentication, so we could make that common between a
>>>>>> ConstraintSecurityHandler
>>>>>> that invoked non-jaspi authentication and another
>>>>>> ConstraintSecurityHandler that invoked
>>>>>> jaspi authentication?
>>>>> The authentication (jaspi or ServerAuthentication) and authorization
>>>>> (constraints or jacc or....??) are completely separable, but I would
>>>>> not try to guarantee that the behavior of the legacy constraint
>>>>> security
>>>>> handler would be unchanged if we combined the constraints up
>>>>> front. If
>>>>> you guys are willing to risk that the legacy behavior will change or
>>>>> analyze it carefully enough so you're sure it won't, combining the
>>>>> constraints up front would really simplify the code. I don't
>>>>> understand
>>>>> how the legacy code works well enough to be comfortable claiming
>>>>> anything about it.
>>>>
>>>> Well, I think the existing "legacy" code is a bit difficult to
>>>> understand,
>>>> which is why I think it is clearer to go with your new structure that
>>>> does the preprocessing.
>>>>
>>>>
>>>>>> In terms of pluggability, I think so far I'm still leaning towards a
>>>>>> default of current
>>>>>> jetty authentication impl, with pluggability of the jaspi impl
>>>>>> (probably via plugging in a
>>>>>> JaspiConstraintSecurityHandler).
>>>>> not sure what you mean here.... if you don't want to use the
>>>>> ServerAuthentication, RunAsToken, and UserIdentity abstractions it may
>>>>> be difficult to switch back and forth. If you mean you want to use
>>>>> the
>>>>> [Basic|Digest|Form|ClientCert]ServerAuthentication implementations for
>>>>> the known auth methods rather than the jaspi modules, I wholeheartedly
>>>>> agree.
>>>>
>>>> What gregw has been discussing with me is the possibility to retain the
>>>> existing jetty-7 authorization code, making judicious changes as
>>>> necessary
>>>> in order to permit a jaspi-flavoured implementation to be plugged in by
>>>> choice. The new jaspi stuff could be debugged, profiled and generally
>>>> kicked around a bit more until we could be comfortable that its at
>>>> least as correct and performant (in the sense of least object creation
>>>> per request, lazy auth all in the right places etc) so that it could
>>>> then move to being the default authorization impl.
>>>>
>>>> Hence, a couple of emails ago I was starting to sketch out some
>>>> ideas of how we could achieve that, but the code base has moved on
>>>> somewhat since then, so I'm not sure how applicable those nascent ideas
>>>> still are until I get a better grip on the changes.
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>>
>>>>>> BTW, thanks for putting so much work into the security refactoring!
>>>>> np!
>>>>>
>>>>> david jencks
>>>>>
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>>
>>>>>>> thanks!
>>>>>>> david jencks
>>>>>>>
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> Jan
>>>>>>>>
>>>>>>>> David Jencks wrote:
>>>>>>>>> Hi Jan,
>>>>>>>>>
>>>>>>>>> I rewrote the standard auth methods as ServerAuthentication
>>>>>>>>> classes on
>>>>>>>>> the plane ride home. I implemented Lazy and Caching (in
>>>>>>>>> session and
>>>>>>>>> SSO) as wrappers. Seems to compile but I haven't tried the tck
>>>>>>>>> yet.
>>>>>>>>>
>>>>>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>>>>>> timeouts?? but
>>>>>>>>> I think this is a lot more plausible than the pure jaspi
>>>>>>>>> implementations.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>>>>>
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>>>>>>>
>>>>>>>>>> I share your concerns about efficiency of the jaspi model,
>>>>>>>>>> which is
>>>>>>>>>> why I tried to put another hopefully efficient layer of
>>>>>>>>>> interfaces in
>>>>>>>>>> between the AbstractSecurityHandler and the jaspi auth
>>>>>>>>>> modules. I
>>>>>>>>>> was
>>>>>>>>>> hoping that we could simply implement the known auth methods
>>>>>>>>>> (FORM,
>>>>>>>>>> BASIC,...) in terms of the ServerAuthentication interface
>>>>>>>>>> directly
>>>>>>>>>> and retain all possible efficiencies. Not having done it yet
>>>>>>>>>> I might
>>>>>>>>>> have missed some important points :-)
>>>>>>>>>>
>>>>>>>>>> I'll think some more about your comments and get back to you.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>>>>>> give some more detailed comments.
>>>>>>>>>>>
>>>>>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>>>>>> like very much the refactoring of
>>>>>>>>>>> Abstract/ConstraintSecurityHandler
>>>>>>>>>>> methods.
>>>>>>>>>>>
>>>>>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>>>>>> coming :)
>>>>>>>>>>>
>>>>>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>>>>>> is a role restriction will result in the user being fully
>>>>>>>>>>> reauthenticated. I understand that even this is an
>>>>>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>>>>>> requires validateRequest to be called on each and every
>>>>>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>>>>>> authentication when there are no role constraints is another
>>>>>>>>>>> good optimization.
>>>>>>>>>>>
>>>>>>>>>>> As there is going to be more authenticating going on as
>>>>>>>>>>> compared with the previous situation, my next reservation
>>>>>>>>>>> takes on more significance, and that is the amount of
>>>>>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>>>>>> callback design.
>>>>>>>>>>>
>>>>>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>>>>>
>>>>>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>>>>>> in mind?
>>>>>>>>>>>
>>>>>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>>>>>> without code to show.
>>>>>>>>>>>
>>>>>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>>>>>> to modify some of the interfaces of UserIdentity and
>>>>>>>>>>> LoginService
>>>>>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>>>>>> things a little:
>>>>>>>>>>>
>>>>>>>>>>> UserIdentity
>>>>>>>>>>> ------------
>>>>>>>>>>> Principal getUserPrincipal()
>>>>>>>>>>> String getAuthMethod()
>>>>>>>>>>> boolean isUserInRole(String role)
>>>>>>>>>>> setRunAsRole(RunAsToken)
>>>>>>>>>>> setServletHandler(ServletHandler)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> UserRealm (was LoginService)
>>>>>>>>>>> ---------
>>>>>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> SecurityManager
>>>>>>>>>>> --------------
>>>>>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>>>>>> ----------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>>>>>> --------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> AbstractSecurityHandler
>>>>>>>>>>> ----------------------
>>>>>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>>>>>
>>>>>>>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>>>>>> where it currently invokes
>>>>>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>>>>>> (around line 169).
>>>>>>>>>>>
>>>>>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>>>>>> authenticator
>>>>>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>>>> did in the pre-jaspi version.
>>>>>>>>>>>
>>>>>>>>>>> The JaspiSecurityManager implementation would be equivalent
>>>>>>>>>>> to the
>>>>>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>>>>>
>>>>>>>>>>> Perhaps the biggest change would be to the LoginService,
>>>>>>>>>>> which I've
>>>>>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>>>>>> authentication related, rather than strictly login related. No
>>>>>>>>>>> problem though
>>>>>>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>>>>>>> method
>>>>>>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>>>>>>> LoginCallback
>>>>>>>>>>> instance on the Subject (via the ServletCallbackHandler). I
>>>>>>>>>>> don't
>>>>>>>>>>> see that as a major problem - the ServletCallbackHandler
>>>>>>>>>>> could set
>>>>>>>>>>> the UserIdentity object on the Subject instead. Note that in
>>>>>>>>>>> a jaspi
>>>>>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>>>>>> called, or
>>>>>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>>>>>
>>>>>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>>>>>> I think we'd need another set for the default jetty
>>>>>>>>>>> implementation
>>>>>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>>>>>> duplication
>>>>>>>>>>> would be highly desirable.
>>>>>>>>>>>
>>>>>>>>>>> From the user's perspective, it would be simple to configure
>>>>>>>>>>> jaspi:
>>>>>>>>>>>
>>>>>>>>>>> WebAppContext webApp = ...;
>>>>>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>>>>>> JaspiSecurityManager());
>>>>>>>>>>>
>>>>>>>>>>> I'm sure I haven't considered all aspects of pluggability.
>>>>>>>>>>> I'll try
>>>>>>>>>>> and get some time to turn the thoughts into code, which are
>>>>>>>>>>> a) more
>>>>>>>>>>> easily
>>>>>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>>>>>
>>>>>>>>>>> cheers
>>>>>>>>>>> Jan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>>>>>
>>>>>>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>>>>>>> future,
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235
>>>>>>>>>>>>> and
>>>>>>>>>>>>> 259.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>>>>>> again on
>>>>>>>>>>>>> the right connector (either the confidential or integral
>>>>>>>>>>>>> port as
>>>>>>>>>>>>> appropriate).
>>>>>>>>>>>>>
>>>>>>>>>>>>> cheers
>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>
>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>>>>>>>> noticed
>>>>>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>>>>>> notices the request was received on the wrong connector
>>>>>>>>>>>>>>> (ie on
>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>>> https) and does a redirect, the
>>>>>>>>>>>>>>> AbstractSecurityHandler.handle()
>>>>>>>>>>>>>>> method goes
>>>>>>>>>>>>>>> ahead and subjects the request to JASPI authentication.
>>>>>>>>>>>>>>> It seems
>>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>>>>>> altogether. It
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> be the redirected request that we're interested in
>>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>>> further
>>>>>>>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>>>>>> base_request.setHandled(true);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think there's something odd here, but IIUC something
>>>>>>>>>>>>>> other than
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>> you see.
>>>>>>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>> I've been worrying about this because it prevents redirecting
>>>>>>>>>>>>>> http
>>>>>>>>>>>>>> requests to the equivalent https requests. Until recently I
>>>>>>>>>>>>>> didn't
>>>>>>>>>>>>>> think it was possible to do this redirect using jacc
>>>>>>>>>>>>>> permissions
>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>> think there is a solution....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the actual request is denied and is http we could
>>>>>>>>>>>>>> create a new
>>>>>>>>>>>>>> request with the url converted to https and
>>>>>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>>>>>> it.... if that check succeeds we can redirect to the more
>>>>>>>>>>>>>> secure
>>>>>>>>>>>>>> url.
>>>>>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>>>>>> authentication is
>>>>>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> unauthenticated user.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the
>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are
>>>>>>>>>>>>>>>>> quasi
>>>>>>>>>>>>>>>>> analogous
>>>>>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour has
>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to
>>>>>>>>>>>>>>>>> retain
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>>>>>>> understand the
>>>>>>>>>>>>>>>> new code, I rather think it would be confusing. I'd really
>>>>>>>>>>>>>>>> rather not
>>>>>>>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> depending
>>>>>>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>> things. The main point of introducing it was that in jetty
>>>>>>>>>>>>>>>> integrations
>>>>>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the
>>>>>>>>>>>>>>>> UserPrincipal was
>>>>>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>>>>>> non-principal
>>>>>>>>>>>>>>>> information associated with the user's identity. I
>>>>>>>>>>>>>>>> think that
>>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>>>>>> whatever else the security system needs. I don't have
>>>>>>>>>>>>>>>> strong
>>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>>> to calling the LoginService UserRealm but I think its going
>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be
>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>> important for
>>>>>>>>>>>>>>>>> Jetty users to be able to make a smooth transition over
>>>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm
>>>>>>>>>>>>>>>>> and a
>>>>>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer and
>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>> descriptive for embedding jetty that the old ones. I could
>>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>>>>>> LoginService to
>>>>>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>> I'm not
>>>>>>>>>>>>>>>> at all sure the non login-service methods on UserRealm
>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>> plausibly
>>>>>>>>>>>>>>>> be called.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>>>> (well,
>>>>>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>>>>>> WebAppContext.getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>>>>>> LoginService is
>>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler,
>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>> line 1042
>>>>>>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this code
>>>>>>>>>>>>>>>> much...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of
>>>>>>>>>>>>>>>>> callbacks it
>>>>>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>>>> the right info, such as credentials, passwords,
>>>>>>>>>>>>>>>>> usernames and
>>>>>>>>>>>>>>>>> also extra request parameters from the login. I notice
>>>>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler
>>>>>>>>>>>>>>>>> instead? It
>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I
>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>>>>>>>> extracting
>>>>>>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>>>>>> service. A
>>>>>>>>>>>>>>>> login module that fishes directly in the request ought
>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>> refactored
>>>>>>>>>>>>>>>> into a plain login module that just validates the
>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>> and an
>>>>>>>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>>>>>>>> Despite all
>>>>>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and
>>>>>>>>>>>>>>>> worth
>>>>>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I guess someone who really really wanted to preserve their
>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>>> could write a subclass of LoginCallback that dealt with
>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>> parameters, and a JAASLoginService subclass. This would be
>>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>> easier
>>>>>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>>>>>>>> marker
>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>>>>>> mappings
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>>>>> This is an embedding thing also. It's pretty unclear what
>>>>>>>>>>>>>>>> run-as is
>>>>>>>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>>>>>>>> identity for
>>>>>>>>>>>>>>>> a web service client or other remote call is supposed to
>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>> (If the
>>>>>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>>>>>> credentials does
>>>>>>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>>>>>>> represent the
>>>>>>>>>>>>>>>> run-as role by a Subject obtained by logging into a
>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>> realm. So,
>>>>>>>>>>>>>>>> the geronimo run-as token has this Subject in it. We might
>>>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't
>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>> constraining the representation of the run-as identity
>>>>>>>>>>>>>>>> is wise.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>>>>>>>> more or
>>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>>> agree on the main interfaces, at which time I plan to
>>>>>>>>>>>>>>>> rewrite
>>>>>>>>>>>>>>>> them in
>>>>>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and
>>>>>>>>>>>>>>>>>>> light on
>>>>>>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi branch,
>>>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey
>>>>>>>>>>>>>>>>>>> around, where
>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in
>>>>>>>>>>>>>>>>>> modules/plus/jetty-plus
>>>>>>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to
>>>>>>>>>>>>>>>>>>> you with
>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you that
>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>>>>> them back into more jetty specific code. Of course if
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity
>>>>>>>>>>>>>>>>>>> @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>>>>>> on at the end when someone realized it was incomplete,
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>>>>>> of CallbackHandler for two way communication between the
>>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for
>>>>>>>>>>>>>>>>>>>> me to
>>>>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>>>>>> integration with jetty and its getting to a point
>>>>>>>>>>>>>>>>>>>> where I'm
>>>>>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for
>>>>>>>>>>>>>>>>>>>> messaging
>>>>>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> client you can add auth info to a request and
>>>>>>>>>>>>>>>>>>>> validate auth
>>>>>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>>> response. On the server you can validate auth info
>>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and
>>>>>>>>>>>>>>>>>>>> transmit the
>>>>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal for
>>>>>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi
>>>>>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it
>>>>>>>>>>>>>>>>>>>> is more
>>>>>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>>>>>> integration with other app servers with their own ideas
>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to
>>>>>>>>>>>>>>>>>>>> verify
>>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response
>>>>>>>>>>>>>>>>>>>> pair on
>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle. This
>>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>>>>>> method that runs through the following structure
>>>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the
>>>>>>>>>>>>>>>>>>>> user data
>>>>>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>>>>>> basically that the request arrived over the right
>>>>>>>>>>>>>>>>>>>> kind of
>>>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this
>>>>>>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>> jetty constraint based implementation or one based
>>>>>>>>>>>>>>>>>>>> on JACC.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>> we can often delay authentication until a method
>>>>>>>>>>>>>>>>>>>> relying on
>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory
>>>>>>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass
>>>>>>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will
>>>>>>>>>>>>>>>>>>>> extract the
>>>>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided
>>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash,
>>>>>>>>>>>>>>>>>>>> JDBC, etc
>>>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>>>>>> authentication when info is actually needed. In this
>>>>>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this
>>>>>>>>>>>>>>>>>>>> includes
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>>>>>> UserIdentity userIdentity =
>>>>>>>>>>>>>>>>>>>> newUserIdentity(authResult);
>>>>>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however they
>>>>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext,
>>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now
>>>>>>>>>>>>>>>>>>>> secure
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework
>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>>>>>> (rather than the bits actually needed for http which I
>>>>>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>>>>>> and have a nearly-untested openid implementation.
>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an
>>>>>>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just
>>>>>>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>>> workflow described about and delegates all actual
>>>>>>>>>>>>>>>>>>>> work to
>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> authentication delegate. This makes it easy to plug in
>>>>>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly
>>>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a
>>>>>>>>>>>>>>>>>>>> Principal
>>>>>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity
>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>>>>>> separate access to the auth results (user principal)
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> interface. These typically delegate to
>>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy
>>>>>>>>>>>>>>>>>>>> authentication if
>>>>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated
>>>>>>>>>>>>>>>>>>>> functions,
>>>>>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the
>>>>>>>>>>>>>>>>>>>> credential
>>>>>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>>>>>> in LoginService. Credential validation may not even be
>>>>>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from
>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> extracts credentials from the request.
>>>>>>>>>>>>>>>>>>>> Implementations are
>>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>>>>>> On the other hand the role handling is called by jetty
>>>>>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService
>>>>>>>>>>>>>>>>>>>> relate to
>>>>>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>>>>> subject)
>>>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication
>>>>>>>>>>>>>>>>>>>> packages
>>>>>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal and
>>>>>>>>>>>>>>>>>>>> group
>>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication
>>>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or.... you
>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>>>>>> and stuff it into an adapter,
>>>>>>>>>>>>>>>>>>>> JaspiServerAuthentication.
>>>>>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>> ServerAuthModule implementations (a
>>>>>>>>>>>>>>>>>>>> ServerAuthContext is
>>>>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which
>>>>>>>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of
>>>>>>>>>>>>>>>>>>>> asking for
>>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies the
>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing
>>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the
>>>>>>>>>>>>>>>>>>>> server:
>>>>>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller
>>>>>>>>>>>>>>>>>>>> principal so
>>>>>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user
>>>>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird
>>>>>>>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging,
>>>>>>>>>>>>>>>>>>>> including ejb
>>>>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>>>>>> normally not a secured response. Trying to evaluate
>>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the
>>>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't see how this implementation could be
>>>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time
>>>>>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>>> I can see that is possible with constraint
>>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request to
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>>>>>> https request if a user data constraint is
>>>>>>>>>>>>>>>>>>>> violated. I'm
>>>>>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>> whether this is something people want to do or
>>>>>>>>>>>>>>>>>>>> usually set
>>>>>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
Hi Jan,
I chatted with Greg a bit on IRC and think I understand a little
better why you might like the AuthenticationManager. IIUC it takes
the code that sets up the standard authentication methods out of
WebXmlConfiguration and puts it in a component that can be set from
jetty.xml (although the default implementation is hardcoded). Is this
more or less correct?
This seems sort of like a plausible goal to me but I still have some
concerns...
First of all, this is an entirely new level of flexibility beyond
anything previously in jetty. Jetty trunk just hardcodes the choice
of [Basic|Digest|Form|ClientCert]Authenticator directly in
WebXmlConfiguration, just like I did with the ServerAuthentication
replacements.
I'm not actually sure there's any chance anyone would use this added
flexibility and strongly suspect there's an easier way to get there
with less code. I think that we should look at the plausible choices
for authentication:
1. [Basic|Digest|Form|ClientCert]ServerAuthentication -- standard,
known methods. I can't see why someone would reimplement all of these
and want to base jetty on their reimplementation rather than just
installing the ServerAuthentication they want per app directly (see
(3) below)
2. A Jaspi ServerAuthModule or maybe ServerAuthContext. For instance
the OpenId module I wrote for geronimo or the spnego one Ron Monzillo
wrote. There's a sub-question of how people might like to install
this which I'll address later -- but we want to support jaspi somehow.
3. A custom implementation of jetty's ServerAuthentication. I would
hope that anyone who went to the trouble to write an auth method for
jetty would use this easier to use more optimized interface rather
than the jaspi one.
Do you see any other plausible choices?
IIUC what your AuthenticationManager code does is make it possible to
supply different implementations for the [Basic|Digest|Form|
ClientCert]ServerAuthentication other than the ones jetty ships with
and configure jetty (using jetty.xml) to install these instead of the
standard ones. I just cant see how this would be a plausible
scenario. I'm happy to be convinced though...
We still don't have code for (2). (I know you wrote
JaspiAuthenticationManager but its not created in code anywhere so
requires extra configuration -- and I haven't looked at it yet.) I've
been delaying writing it until we have agreement on more of the
interfaces.... maybe not so wise on my part :-) The official way to
use jaspi is rather complicated and IMO silly for jetty. You need a
Jaspi provider that lets the all-powerful sysadmin configure all sorts
of stuff including ServerAuthConfigs for specific apps. This is then
saved somehow by the jaspi impl ready for use by the world, indexed by
basically the context root of the app. Now when the app is deployed
you go through a bunch of classes using that context root and
eventually manage to extract the ServerAuthConfig for your app. The
jaspi spec says if there's an auth whoozits configured for your app
(based on the context root) then you should use it instead of the
standard auth method that might be configured. So we ought to
support this I guess but I doubt anyone will use this. What you
actually need is either a ServerAuthModule or ServerAuthContext and
you can configure those yourself and stuff them in the
JaspiServerAuthentication (possibly with a wrapper around them).
So I think what I'd like to see is...
if there's either a ServerAuthentication instance or jaspi
ServerAuthModule/Context/Config explicitly configured in context.xml
(IIUC this is the app-specific "jetty plan" for the web app) then
we'll use that.
Otherwise...
If there's a jaspi provider available and configured and there's
something configured for your app we'll use that
Otherwise...
we'll use the [Basic|Digest|Form|ClientCert]ServerAuthentication built
into jetty.
So that's why I don't think the added flexibility of
AuthenticationManager is very useful...
My other problem with it is that the methods on it are specific to the
built in auth methods and some -- like the login and error page
properties -- are specific to the form auth method. I think that
basic and digest also need a "realm" property. So if we continue
using AuthenticationManager I'd prefer that SecurityHandler just have
a ServerAuthentication instance inside and anyone who wants to use the
AuthenticationManager interface test for it. If the
ServerAuthentication is not an AuthenticationManager that means that
some other authentication configuration is in place and we shouldn't
try to set the standard methods up.
Finally.... I may not have made it clear enough that the [Basic|Digest|
Form|ClientCert]AuthModules left over are never going to be used for
anything except examples (maybe).... I left them there mostly for
reference in case I forgot something in the ServerAuthentication
implementations.
Even more finally... I want to reemphasize that I think we agree on
all major points and if you still want the AuthenticationManager I'll
still be very happy with the code.
many thanks
david jencks
On Nov 25, 2008, at 11:01 AM, David Jencks wrote:
> Hi Jan,
>
> I've taken a very quick look at the AuthenticationManager you've
> added. It looks to me (based on this very non-thorough glance) that
> the main effect is to move some of the auth setup code out of
> WebXmlConfiguration and make it more accessible to programatic
> setup. For instance instead of having to know to use a
> BasicServerAuthentication you just need to know the string "BASIC".
> Is this more or less correct?
>
> I like the idea of making it easier to configure authentication like
> this, but I think there might be a more flexible and less intrusive
> way. IIUC the runtime authentication behavior still works through
> the ServerAuthentication interface, and the added methods on
> AuthenticationManager are only used for setup. If someone wanted to
> implement their own ServerAuthentication these extra methods
> wouldn't really provide any extra value.
>
> What if we had something like a DefaultAuthenticationFactory that
> you set up with the security handler and called configure(String
> authMethod, String loginPage, String errorPage, String realm) on and
> it constructed the appropriate [Basic|Digest|Form|
> ClientCert]ServerAuthentication and set it in the security handler?
> We'd need something similar for the jaspi approach.
>
> To me this would seem to separate the configuration and runtime
> aspects nicely while still providing the advantages of simpler
> configuration of the default auth methods.
>
> I haven't looked at your jaspi code yet.... jaspi configuration is a
> bit convoluted IMNSHO and I actually suspect anyone using a jaspi
> module may want to set it up directly in code rather than dealing
> with a whole jaspi provider (which I wrote for geronimo but not
> jetty specifically) I'll look at this in a bit.
>
> Moving the login services seems like a very good idea :-)
>
> thanks
> david jencks
>
>
> On Nov 25, 2008, at 8:53 AM, Jan Bartel wrote:
>
>> Hi David,
>>
>> I've made some changes to attempt to make jaspi vs non-jaspi
>> authentication pluggable. I've checked the changes in, as I
>> thought it is easier to see the code than talk about it.
>>
>> In a nutshell, I've introduced an AuthenticationManager that
>> is used by a SecurityHandler to carry out all authentication,
>> and which delegates to either a non-jaspi or jaspi implementation.
>>
>> The ConstraintSecurityHandler uses a DefaultAuthenticationManager
>> (non-jaspi) by default, but one can plug in the
>> JaspiAuthenticationManager
>> as an alternative.
>>
>> The WebXmlConfiguration sets up information from the web.xml such
>> as the auth method and login/error pages on the
>> AuthenticationManager,
>> but no longer sets up the various auth modules such as Basic, Form,
>> Cert
>> etc. That is now done by the AuthenticationManager instance instead
>> when
>> it is started, based on the auth information passed into it by the
>> WebXmlConfiguration
>> (or programmatically of course).
>>
>> I've allowed for the JaspiAuthenticationManager to plugin a jaspi
>> auth module,
>> so that potentially we can plug in 3rd party jaspi auth modules.
>> The question is,
>> is the pluggability at the right level? That is, I've allowed a
>> ServerAuth instance
>> to be set on the JaspiAuthenticationManager, but the
>> JaspiServerAuthentication
>> class expects a ServerAuthContext instead (which all of the
>> FormAuth, BasicAuth
>> etc classes implement) - would a 3rd party jaspi module be likely
>> to implement
>> that interface? Should we be allowing for plugging in some other
>> class entirely?
>>
>> BTW I changed around a couple of packages, most notably the
>> HashLoginService and
>> JDBCLoginService I moved out of
>> org.mortbay.jetty.security.jaspi.modules and into
>> org.mortbay.jetty.security, as AFAICT they are not jaspi specific.
>>
>> I noticed along the way that the SSO stuff isn't really hooked up.
>> Difficult to
>> see how to shoe-horn that into the new structure. Perhaps its time
>> to ditch it
>> and allow for integration with "real" SSO implementations instead?
>>
>> The jaspi branch builds and tests without error, but I'm just
>> chasing down an
>> error when running the test webapp:
>>
>> Failed startup of context
>> org.mortbay.jetty.webapp.WebAppContext@1e59128{/,/home/janb/src/
>> jetty-jaspi/webapps/test}
>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>> content-administrator, known roles: []
>>
>> And the same for the test-jaas webapp:
>>
>> Failed startup of context
>> org.mortbay.jetty.webapp.WebAppContext@10ffb38{/test-jaas,file:/
>> home/janb/src/jetty-jaspi/webapps/test-jaas/}
>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>> roleA, known roles: []
>>
>> Looks like something amiss with the role merging, perhaps.
>>
>> Have a look at what I've committed, and please let me know what you
>> think. I'm all ears if
>> you've got any suggestions or a better way.
>>
>> cheers
>> Jan
>>
>>
>>
>> Jan Bartel wrote:
>>> David,
>>> [snip]
>>>>>>> BTW, the code needs to be reformatted to jetty standard
>>>>>>> conventions
>>>>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding
>>>>>>> +Standards) or
>>>>>>> gregw will have conniptions ;)
>>>>>> hmm.... I thought I'd done pretty well imitating the code
>>>>>> style. Do you
>>>>>> have some way to fix it automatically?
>>>>> Lemme see ... as far as the brackets go, I have an eclipse
>>>>> codestyle
>>>>> that I can apply to each file, but the rigorous naming of data
>>>>> members
>>>>> with leading _
>>>>> or __ would have to be done manually.
>>>> aha.... I can fix that, probably tomorrow. The brackets might be
>>>> tougher for me.
>>>
>>> I've reformatted and checked in classes in jetty and jetty-security
>>> packages.
>>>
>>>>> Correct me if I'm wrong, but the constraint preprocessing
>>>>> behaviour is
>>>>> separable
>>>>> from the jaspi authentication, so we could make that common
>>>>> between a
>>>>> ConstraintSecurityHandler
>>>>> that invoked non-jaspi authentication and another
>>>>> ConstraintSecurityHandler that invoked
>>>>> jaspi authentication?
>>>> The authentication (jaspi or ServerAuthentication) and
>>>> authorization
>>>> (constraints or jacc or....??) are completely separable, but I
>>>> would
>>>> not try to guarantee that the behavior of the legacy constraint
>>>> security
>>>> handler would be unchanged if we combined the constraints up
>>>> front. If
>>>> you guys are willing to risk that the legacy behavior will change
>>>> or
>>>> analyze it carefully enough so you're sure it won't, combining the
>>>> constraints up front would really simplify the code. I don't
>>>> understand
>>>> how the legacy code works well enough to be comfortable claiming
>>>> anything about it.
>>>
>>> Well, I think the existing "legacy" code is a bit difficult to
>>> understand,
>>> which is why I think it is clearer to go with your new structure
>>> that
>>> does the preprocessing.
>>>
>>>
>>>>> In terms of pluggability, I think so far I'm still leaning
>>>>> towards a
>>>>> default of current
>>>>> jetty authentication impl, with pluggability of the jaspi impl
>>>>> (probably via plugging in a
>>>>> JaspiConstraintSecurityHandler).
>>>> not sure what you mean here.... if you don't want to use the
>>>> ServerAuthentication, RunAsToken, and UserIdentity abstractions
>>>> it may
>>>> be difficult to switch back and forth. If you mean you want to
>>>> use the
>>>> [Basic|Digest|Form|ClientCert]ServerAuthentication
>>>> implementations for
>>>> the known auth methods rather than the jaspi modules, I
>>>> wholeheartedly
>>>> agree.
>>>
>>> What gregw has been discussing with me is the possibility to
>>> retain the
>>> existing jetty-7 authorization code, making judicious changes as
>>> necessary
>>> in order to permit a jaspi-flavoured implementation to be plugged
>>> in by
>>> choice. The new jaspi stuff could be debugged, profiled and
>>> generally
>>> kicked around a bit more until we could be comfortable that its at
>>> least as correct and performant (in the sense of least object
>>> creation
>>> per request, lazy auth all in the right places etc) so that it could
>>> then move to being the default authorization impl.
>>>
>>> Hence, a couple of emails ago I was starting to sketch out some
>>> ideas of how we could achieve that, but the code base has moved on
>>> somewhat since then, so I'm not sure how applicable those nascent
>>> ideas
>>> still are until I get a better grip on the changes.
>>>
>>> cheers
>>> Jan
>>>
>>>
>>>>> BTW, thanks for putting so much work into the security
>>>>> refactoring!
>>>> np!
>>>>
>>>> david jencks
>>>>
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>>> thanks!
>>>>>> david jencks
>>>>>>
>>>>>>>
>>>>>>> cheers
>>>>>>> Jan
>>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> I rewrote the standard auth methods as ServerAuthentication
>>>>>>>> classes on
>>>>>>>> the plane ride home. I implemented Lazy and Caching (in
>>>>>>>> session and
>>>>>>>> SSO) as wrappers. Seems to compile but I haven't tried the
>>>>>>>> tck yet.
>>>>>>>>
>>>>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>>>>> timeouts?? but
>>>>>>>> I think this is a lot more plausible than the pure jaspi
>>>>>>>> implementations.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>>
>>>>>>>>> I'm about to hop on a plane so will respond in more detail
>>>>>>>>> later.
>>>>>>>>>
>>>>>>>>> I share your concerns about efficiency of the jaspi model,
>>>>>>>>> which is
>>>>>>>>> why I tried to put another hopefully efficient layer of
>>>>>>>>> interfaces in
>>>>>>>>> between the AbstractSecurityHandler and the jaspi auth
>>>>>>>>> modules. I
>>>>>>>>> was
>>>>>>>>> hoping that we could simply implement the known auth methods
>>>>>>>>> (FORM,
>>>>>>>>> BASIC,...) in terms of the ServerAuthentication interface
>>>>>>>>> directly
>>>>>>>>> and retain all possible efficiencies. Not having done it
>>>>>>>>> yet I might
>>>>>>>>> have missed some important points :-)
>>>>>>>>>
>>>>>>>>> I'll think some more about your comments and get back to you.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>>>>> give some more detailed comments.
>>>>>>>>>>
>>>>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>>>>> like very much the refactoring of Abstract/
>>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>>> methods.
>>>>>>>>>>
>>>>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>>>>> coming :)
>>>>>>>>>>
>>>>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>>>>> is a role restriction will result in the user being fully
>>>>>>>>>> reauthenticated. I understand that even this is an
>>>>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>>>>> requires validateRequest to be called on each and every
>>>>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>>>>> authentication when there are no role constraints is another
>>>>>>>>>> good optimization.
>>>>>>>>>>
>>>>>>>>>> As there is going to be more authenticating going on as
>>>>>>>>>> compared with the previous situation, my next reservation
>>>>>>>>>> takes on more significance, and that is the amount of
>>>>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>>>>> callback design.
>>>>>>>>>>
>>>>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>>>>
>>>>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>>>>> to make them more efficient, we'd be getting ever farther
>>>>>>>>>> away
>>>>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>>>>> in mind?
>>>>>>>>>>
>>>>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>>>>> without code to show.
>>>>>>>>>>
>>>>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>>>>> to modify some of the interfaces of UserIdentity and
>>>>>>>>>> LoginService
>>>>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>>>>> things a little:
>>>>>>>>>>
>>>>>>>>>> UserIdentity
>>>>>>>>>> ------------
>>>>>>>>>> Principal getUserPrincipal()
>>>>>>>>>> String getAuthMethod()
>>>>>>>>>> boolean isUserInRole(String role)
>>>>>>>>>> setRunAsRole(RunAsToken)
>>>>>>>>>> setServletHandler(ServletHandler)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> UserRealm (was LoginService)
>>>>>>>>>> ---------
>>>>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SecurityManager
>>>>>>>>>> --------------
>>>>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>>>>> ----------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>>>>> --------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> AbstractSecurityHandler
>>>>>>>>>> ----------------------
>>>>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>>>>
>>>>>>>>>> The AbstractSecurityHandler would be pretty much unchanged
>>>>>>>>>> as it
>>>>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>>>>> where it currently invokes
>>>>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>>>>> (around line 169).
>>>>>>>>>>
>>>>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>>>>> authenticator
>>>>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>>> did in the pre-jaspi version.
>>>>>>>>>>
>>>>>>>>>> The JaspiSecurityManager implementation would be equivalent
>>>>>>>>>> to the
>>>>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>>>>
>>>>>>>>>> Perhaps the biggest change would be to the LoginService,
>>>>>>>>>> which I've
>>>>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>>>>> authentication related, rather than strictly login related.
>>>>>>>>>> No
>>>>>>>>>> problem though
>>>>>>>>>> to keep the name LoginService if preferred. The
>>>>>>>>>> authenticate()
>>>>>>>>>> method
>>>>>>>>>> returns a UserIdentity object, instead of ultimately
>>>>>>>>>> setting a
>>>>>>>>>> LoginCallback
>>>>>>>>>> instance on the Subject (via the ServletCallbackHandler). I
>>>>>>>>>> don't
>>>>>>>>>> see that as a major problem - the ServletCallbackHandler
>>>>>>>>>> could set
>>>>>>>>>> the UserIdentity object on the Subject instead. Note that
>>>>>>>>>> in a jaspi
>>>>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>>>>> called, or
>>>>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>>>>
>>>>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>>>>> I think we'd need another set for the default jetty
>>>>>>>>>> implementation
>>>>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>>>>> duplication
>>>>>>>>>> would be highly desirable.
>>>>>>>>>>
>>>>>>>>>> From the user's perspective, it would be simple to
>>>>>>>>>> configure jaspi:
>>>>>>>>>>
>>>>>>>>>> WebAppContext webApp = ...;
>>>>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>>>>> JaspiSecurityManager());
>>>>>>>>>>
>>>>>>>>>> I'm sure I haven't considered all aspects of pluggability.
>>>>>>>>>> I'll try
>>>>>>>>>> and get some time to turn the thoughts into code, which are
>>>>>>>>>> a) more
>>>>>>>>>> easily
>>>>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> Jan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>>>>
>>>>>>>>>>> hoping to read your messages carefully before replying in
>>>>>>>>>>> the
>>>>>>>>>>> future,
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>>>>
>>>>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line
>>>>>>>>>>>> 235 and
>>>>>>>>>>>> 259.
>>>>>>>>>>>>
>>>>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>>>>> again on
>>>>>>>>>>>> the right connector (either the confidential or integral
>>>>>>>>>>>> port as
>>>>>>>>>>>> appropriate).
>>>>>>>>>>>>
>>>>>>>>>>>> cheers
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I
>>>>>>>>>>>>>> just
>>>>>>>>>>>>>> noticed
>>>>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>>>>> notices the request was received on the wrong connector
>>>>>>>>>>>>>> (ie on
>>>>>>>>>>>>>> http
>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>> https) and does a redirect, the
>>>>>>>>>>>>>> AbstractSecurityHandler.handle()
>>>>>>>>>>>>>> method goes
>>>>>>>>>>>>>> ahead and subjects the request to JASPI authentication.
>>>>>>>>>>>>>> It seems
>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>>>>> altogether. It
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be the redirected request that we're interested in
>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>> further
>>>>>>>>>>>>>> (either doing the auth or doing a redirect to a login
>>>>>>>>>>>>>> form).
>>>>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>>>>
>>>>>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>>>>> {
>>>>>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>
>>>>>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>>>>> base_request.setHandled(true);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think there's something odd here, but IIUC something
>>>>>>>>>>>>> other than
>>>>>>>>>>>>> what
>>>>>>>>>>>>> you see.
>>>>>>>>>>>>> This is not proposing a redirect, it is plainly denying
>>>>>>>>>>>>> the
>>>>>>>>>>>>> request.
>>>>>>>>>>>>> I've been worrying about this because it prevents
>>>>>>>>>>>>> redirecting
>>>>>>>>>>>>> http
>>>>>>>>>>>>> requests to the equivalent https requests. Until
>>>>>>>>>>>>> recently I
>>>>>>>>>>>>> didn't
>>>>>>>>>>>>> think it was possible to do this redirect using jacc
>>>>>>>>>>>>> permissions
>>>>>>>>>>>>> but I
>>>>>>>>>>>>> think there is a solution....
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the actual request is denied and is http we could
>>>>>>>>>>>>> create a new
>>>>>>>>>>>>> request with the url converted to https and
>>>>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>>>>> it.... if that check succeeds we can redirect to the
>>>>>>>>>>>>> more secure
>>>>>>>>>>>>> url.
>>>>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>>>>> authentication is
>>>>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> unauthenticated user.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the
>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These
>>>>>>>>>>>>>>>> are quasi
>>>>>>>>>>>>>>>> analogous
>>>>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the
>>>>>>>>>>>>>>>> behaviour has
>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to
>>>>>>>>>>>>>>>> retain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure that keeping the old names would help
>>>>>>>>>>>>>>> anyone
>>>>>>>>>>>>>>> understand the
>>>>>>>>>>>>>>> new code, I rather think it would be confusing. I'd
>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>> rather not
>>>>>>>>>>>>>>> call UserIdentity a Principal since it isn't a
>>>>>>>>>>>>>>> Principal and
>>>>>>>>>>>>>>> depending
>>>>>>>>>>>>>>> on the security handler implementation can contain
>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> things. The main point of introducing it was that in
>>>>>>>>>>>>>>> jetty
>>>>>>>>>>>>>>> integrations
>>>>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the
>>>>>>>>>>>>>>> UserPrincipal was
>>>>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>>>>> non-principal
>>>>>>>>>>>>>>> information associated with the user's identity. I
>>>>>>>>>>>>>>> think that
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>>>>> whatever else the security system needs. I don't have
>>>>>>>>>>>>>>> strong
>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>> to calling the LoginService UserRealm but I think its
>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be
>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>> important for
>>>>>>>>>>>>>>>> Jetty users to be able to make a smooth transition
>>>>>>>>>>>>>>>> over to a
>>>>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>>>>> implementation. Do you think we can retain a
>>>>>>>>>>>>>>>> UserRealm and a
>>>>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> some extra methods and some changed implementations
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer
>>>>>>>>>>>>>>> and more
>>>>>>>>>>>>>>> descriptive for embedding jetty that the old ones. I
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>>>>> LoginService to
>>>>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>> I'm not
>>>>>>>>>>>>>>> at all sure the non login-service methods on UserRealm
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>> plausibly
>>>>>>>>>>>>>>> be called.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>>> (well,
>>>>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>>> .getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>>>>> I couldn't see specific support for that, only
>>>>>>>>>>>>>>>> getting a
>>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>>>>> LoginService is
>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler,
>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>> line 1042
>>>>>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> much...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of
>>>>>>>>>>>>>>>> callbacks it
>>>>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>>> the right info, such as credentials, passwords,
>>>>>>>>>>>>>>>> usernames and
>>>>>>>>>>>>>>>> also extra request parameters from the login. I
>>>>>>>>>>>>>>>> notice you're
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the
>>>>>>>>>>>>>>>> JAAS
>>>>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler
>>>>>>>>>>>>>>>> instead? It
>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I
>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>> extensions to a user-password callback handler all
>>>>>>>>>>>>>>> involve
>>>>>>>>>>>>>>> extracting
>>>>>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>>>>> service. A
>>>>>>>>>>>>>>> login module that fishes directly in the request ought
>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>> refactored
>>>>>>>>>>>>>>> into a plain login module that just validates the
>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>> and an
>>>>>>>>>>>>>>> auth module that extracts the credentials from the
>>>>>>>>>>>>>>> message.
>>>>>>>>>>>>>>> Despite all
>>>>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and
>>>>>>>>>>>>>>> worth
>>>>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I guess someone who really really wanted to preserve
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>> could write a subclass of LoginCallback that dealt
>>>>>>>>>>>>>>> with request
>>>>>>>>>>>>>>> parameters, and a JAASLoginService subclass. This
>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>> easier
>>>>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the
>>>>>>>>>>>>>>>> RunAsToken
>>>>>>>>>>>>>>>> marker
>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>>>>> mappings
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>>>> This is an embedding thing also. It's pretty unclear
>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>> run-as is
>>>>>>>>>>>>>>> actually supposed to mean and how things like
>>>>>>>>>>>>>>> supplying the
>>>>>>>>>>>>>>> identity for
>>>>>>>>>>>>>>> a web service client or other remote call is supposed
>>>>>>>>>>>>>>> to work.
>>>>>>>>>>>>>>> (If the
>>>>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>>>>> credentials does
>>>>>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>>>>>> represent the
>>>>>>>>>>>>>>> run-as role by a Subject obtained by logging into a
>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>> realm. So,
>>>>>>>>>>>>>>> the geronimo run-as token has this Subject in it. We
>>>>>>>>>>>>>>> might
>>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't
>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>> constraining the representation of the run-as identity
>>>>>>>>>>>>>>> is wise.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary
>>>>>>>>>>>>>>> until we
>>>>>>>>>>>>>>> more or
>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>> agree on the main interfaces, at which time I plan to
>>>>>>>>>>>>>>> rewrite
>>>>>>>>>>>>>>> them in
>>>>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and
>>>>>>>>>>>>>>>>>> light on
>>>>>>>>>>>>>>>>>> comprehensibility. Your email was way more
>>>>>>>>>>>>>>>>>> informative
>>>>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi
>>>>>>>>>>>>>>>>>> branch,
>>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey
>>>>>>>>>>>>>>>>>> around, where
>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/
>>>>>>>>>>>>>>>>> jetty-plus
>>>>>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to
>>>>>>>>>>>>>>>>>> you with
>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you
>>>>>>>>>>>>>>>>>> that your
>>>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in
>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>>>> them back into more jetty specific code. Of course
>>>>>>>>>>>>>>>>> if you
>>>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>>> PS I love this code-comment in
>>>>>>>>>>>>>>>>>> ServletCallbackHandler:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity
>>>>>>>>>>>>>>>>>> @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if
>>>>>>>>>>>>>>>>> they are
>>>>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>>>>> on at the end when someone realized it was
>>>>>>>>>>>>>>>>> incomplete, and
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>>>>> of CallbackHandler for two way communication between
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch
>>>>>>>>>>>>>>>>>>> for me to
>>>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>>>>> integration with jetty and its getting to a point
>>>>>>>>>>>>>>>>>>> where I'm
>>>>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for
>>>>>>>>>>>>>>>>>>> messaging
>>>>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> client you can add auth info to a request and
>>>>>>>>>>>>>>>>>>> validate auth
>>>>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>> response. On the server you can validate auth
>>>>>>>>>>>>>>>>>>> info on a
>>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and
>>>>>>>>>>>>>>>>>>> transmit the
>>>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100%
>>>>>>>>>>>>>>>>>>> ideal for
>>>>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the
>>>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it
>>>>>>>>>>>>>>>>>>> is more
>>>>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>>>>> integration with other app servers with their own
>>>>>>>>>>>>>>>>>>> ideas
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make
>>>>>>>>>>>>>>>>>>> jacc
>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried
>>>>>>>>>>>>>>>>>>> to verify
>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I
>>>>>>>>>>>>>>>>>>> plan to
>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response
>>>>>>>>>>>>>>>>>>> pair on
>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle.
>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>>>>> method that runs through the following structure
>>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the
>>>>>>>>>>>>>>>>>>> user data
>>>>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>>>>> basically that the request arrived over the right
>>>>>>>>>>>>>>>>>>> kind of
>>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this
>>>>>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>> jetty constraint based implementation or one based
>>>>>>>>>>>>>>>>>>> on JACC.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request,
>>>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>>>>> determine if the request actually needs
>>>>>>>>>>>>>>>>>>> authentication.
>>>>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> we can often delay authentication until a method
>>>>>>>>>>>>>>>>>>> relying on
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or
>>>>>>>>>>>>>>>>>>> isUserInRole).
>>>>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory
>>>>>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass
>>>>>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will
>>>>>>>>>>>>>>>>>>> extract the
>>>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>>>> client to request the credentials) and validate
>>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>> Validation can use a LoginService possibly
>>>>>>>>>>>>>>>>>>> provided to the
>>>>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash,
>>>>>>>>>>>>>>>>>>> JDBC, etc
>>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that
>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>>>>> authentication when info is actually needed. In
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this
>>>>>>>>>>>>>>>>>>> includes
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>>>>> UserIdentity userIdentity =
>>>>>>>>>>>>>>>>>>> newUserIdentity(authResult);
>>>>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> actually answering auth questions from the
>>>>>>>>>>>>>>>>>>> application
>>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however
>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext,
>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now
>>>>>>>>>>>>>>>>>>> secure
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework
>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>>>>> (rather than the bits actually needed for http
>>>>>>>>>>>>>>>>>>> which I
>>>>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>>>>> and have a nearly-untested openid
>>>>>>>>>>>>>>>>>>> implementation. This
>>>>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an
>>>>>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I
>>>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with
>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just
>>>>>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>> workflow described about and delegates all actual
>>>>>>>>>>>>>>>>>>> work to
>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> authentication delegate. This makes it easy to
>>>>>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>>>>> implementations such as a JACC implementation for
>>>>>>>>>>>>>>>>>>> an EE
>>>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly
>>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a
>>>>>>>>>>>>>>>>>>> Principal
>>>>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>>>>> apparent reason and made integration into app
>>>>>>>>>>>>>>>>>>> servers
>>>>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity
>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>>>>> separate access to the auth results (user
>>>>>>>>>>>>>>>>>>> principal) and
>>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> interface. These typically delegate to
>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy
>>>>>>>>>>>>>>>>>>> authentication if
>>>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated
>>>>>>>>>>>>>>>>>>> functions,
>>>>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the
>>>>>>>>>>>>>>>>>>> credential
>>>>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>>>>> in LoginService. Credential validation may not
>>>>>>>>>>>>>>>>>>> even be
>>>>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from
>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> extracts credentials from the request.
>>>>>>>>>>>>>>>>>>> Implementations are
>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>>>>> something like look up the user in a file or table
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>>>>> On the other hand the role handling is called by
>>>>>>>>>>>>>>>>>>> jetty
>>>>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> application and the implementation is done by the
>>>>>>>>>>>>>>>>>>> app
>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService
>>>>>>>>>>>>>>>>>>> relate to
>>>>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The JASPI interface similar to
>>>>>>>>>>>>>>>>>>> ServerAuthentication is
>>>>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>>>> subject)
>>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo
>>>>>>>>>>>>>>>>>>> messageInfo, Subject
>>>>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication
>>>>>>>>>>>>>>>>>>> packages
>>>>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal
>>>>>>>>>>>>>>>>>>> and group
>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication
>>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or....
>>>>>>>>>>>>>>>>>>> you can
>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>>>>> and stuff it into an adapter,
>>>>>>>>>>>>>>>>>>> JaspiServerAuthentication.
>>>>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>>>>> want to implement the built in auth methods as
>>>>>>>>>>>>>>>>>>> direct
>>>>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>> ServerAuthModule implementations (a
>>>>>>>>>>>>>>>>>>> ServerAuthContext is
>>>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which
>>>>>>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of
>>>>>>>>>>>>>>>>>>> asking for
>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>>> based on Callbacks. The container (jetty)
>>>>>>>>>>>>>>>>>>> supplies the
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth
>>>>>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing
>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the
>>>>>>>>>>>>>>>>>>> server:
>>>>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller
>>>>>>>>>>>>>>>>>>> principal so
>>>>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user
>>>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the
>>>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird
>>>>>>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> more sense in the context of other messaging
>>>>>>>>>>>>>>>>>>> systems:
>>>>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging,
>>>>>>>>>>>>>>>>>>> including ejb
>>>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>>>>> normally not a secured response. Trying to
>>>>>>>>>>>>>>>>>>> evaluate auth
>>>>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the
>>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't see how this implementation could be
>>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at
>>>>>>>>>>>>>>>>>>> problems.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long
>>>>>>>>>>>>>>>>>>> time now.
>>>>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>> I can see that is possible with constraint
>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request
>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>>>>> https request if a user data constraint is
>>>>>>>>>>>>>>>>>>> violated. I'm
>>>>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> whether this is something people want to do or
>>>>>>>>>>>>>>>>>>> usually set
>>>>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://
>>>>> www.webtide.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
Hi Jan,
I've taken a very quick look at the AuthenticationManager you've
added. It looks to me (based on this very non-thorough glance) that
the main effect is to move some of the auth setup code out of
WebXmlConfiguration and make it more accessible to programatic setup.
For instance instead of having to know to use a
BasicServerAuthentication you just need to know the string "BASIC".
Is this more or less correct?
I like the idea of making it easier to configure authentication like
this, but I think there might be a more flexible and less intrusive
way. IIUC the runtime authentication behavior still works through the
ServerAuthentication interface, and the added methods on
AuthenticationManager are only used for setup. If someone wanted to
implement their own ServerAuthentication these extra methods wouldn't
really provide any extra value.
What if we had something like a DefaultAuthenticationFactory that you
set up with the security handler and called configure(String
authMethod, String loginPage, String errorPage, String realm) on and
it constructed the appropriate [Basic|Digest|Form|
ClientCert]ServerAuthentication and set it in the security handler?
We'd need something similar for the jaspi approach.
To me this would seem to separate the configuration and runtime
aspects nicely while still providing the advantages of simpler
configuration of the default auth methods.
I haven't looked at your jaspi code yet.... jaspi configuration is a
bit convoluted IMNSHO and I actually suspect anyone using a jaspi
module may want to set it up directly in code rather than dealing with
a whole jaspi provider (which I wrote for geronimo but not jetty
specifically) I'll look at this in a bit.
Moving the login services seems like a very good idea :-)
thanks
david jencks
On Nov 25, 2008, at 8:53 AM, Jan Bartel wrote:
> Hi David,
>
> I've made some changes to attempt to make jaspi vs non-jaspi
> authentication pluggable. I've checked the changes in, as I
> thought it is easier to see the code than talk about it.
>
> In a nutshell, I've introduced an AuthenticationManager that
> is used by a SecurityHandler to carry out all authentication,
> and which delegates to either a non-jaspi or jaspi implementation.
>
> The ConstraintSecurityHandler uses a DefaultAuthenticationManager
> (non-jaspi) by default, but one can plug in the
> JaspiAuthenticationManager
> as an alternative.
>
> The WebXmlConfiguration sets up information from the web.xml such
> as the auth method and login/error pages on the AuthenticationManager,
> but no longer sets up the various auth modules such as Basic, Form,
> Cert
> etc. That is now done by the AuthenticationManager instance instead
> when
> it is started, based on the auth information passed into it by the
> WebXmlConfiguration
> (or programmatically of course).
>
> I've allowed for the JaspiAuthenticationManager to plugin a jaspi
> auth module,
> so that potentially we can plug in 3rd party jaspi auth modules. The
> question is,
> is the pluggability at the right level? That is, I've allowed a
> ServerAuth instance
> to be set on the JaspiAuthenticationManager, but the
> JaspiServerAuthentication
> class expects a ServerAuthContext instead (which all of the
> FormAuth, BasicAuth
> etc classes implement) - would a 3rd party jaspi module be likely to
> implement
> that interface? Should we be allowing for plugging in some other
> class entirely?
>
> BTW I changed around a couple of packages, most notably the
> HashLoginService and
> JDBCLoginService I moved out of
> org.mortbay.jetty.security.jaspi.modules and into
> org.mortbay.jetty.security, as AFAICT they are not jaspi specific.
>
> I noticed along the way that the SSO stuff isn't really hooked up.
> Difficult to
> see how to shoe-horn that into the new structure. Perhaps its time
> to ditch it
> and allow for integration with "real" SSO implementations instead?
>
> The jaspi branch builds and tests without error, but I'm just
> chasing down an
> error when running the test webapp:
>
> Failed startup of context
> org.mortbay.jetty.webapp.WebAppContext@1e59128{/,/home/janb/src/
> jetty-jaspi/webapps/test}
> java.lang.IllegalArgumentException: Attempt to use undeclared role:
> content-administrator, known roles: []
>
> And the same for the test-jaas webapp:
>
> Failed startup of context
> org.mortbay.jetty.webapp.WebAppContext@10ffb38{/test-jaas,file:/home/
> janb/src/jetty-jaspi/webapps/test-jaas/}
> java.lang.IllegalArgumentException: Attempt to use undeclared role:
> roleA, known roles: []
>
> Looks like something amiss with the role merging, perhaps.
>
> Have a look at what I've committed, and please let me know what you
> think. I'm all ears if
> you've got any suggestions or a better way.
>
> cheers
> Jan
>
>
>
> Jan Bartel wrote:
>> David,
>> [snip]
>>>>>> BTW, the code needs to be reformatted to jetty standard
>>>>>> conventions
>>>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards)
>>>>>> or
>>>>>> gregw will have conniptions ;)
>>>>> hmm.... I thought I'd done pretty well imitating the code style.
>>>>> Do you
>>>>> have some way to fix it automatically?
>>>> Lemme see ... as far as the brackets go, I have an eclipse
>>>> codestyle
>>>> that I can apply to each file, but the rigorous naming of data
>>>> members
>>>> with leading _
>>>> or __ would have to be done manually.
>>> aha.... I can fix that, probably tomorrow. The brackets might be
>>> tougher for me.
>>
>> I've reformatted and checked in classes in jetty and jetty-security
>> packages.
>>
>>>> Correct me if I'm wrong, but the constraint preprocessing
>>>> behaviour is
>>>> separable
>>>> from the jaspi authentication, so we could make that common
>>>> between a
>>>> ConstraintSecurityHandler
>>>> that invoked non-jaspi authentication and another
>>>> ConstraintSecurityHandler that invoked
>>>> jaspi authentication?
>>> The authentication (jaspi or ServerAuthentication) and authorization
>>> (constraints or jacc or....??) are completely separable, but I
>>> would
>>> not try to guarantee that the behavior of the legacy constraint
>>> security
>>> handler would be unchanged if we combined the constraints up
>>> front. If
>>> you guys are willing to risk that the legacy behavior will change or
>>> analyze it carefully enough so you're sure it won't, combining the
>>> constraints up front would really simplify the code. I don't
>>> understand
>>> how the legacy code works well enough to be comfortable claiming
>>> anything about it.
>>
>> Well, I think the existing "legacy" code is a bit difficult to
>> understand,
>> which is why I think it is clearer to go with your new structure that
>> does the preprocessing.
>>
>>
>>>> In terms of pluggability, I think so far I'm still leaning
>>>> towards a
>>>> default of current
>>>> jetty authentication impl, with pluggability of the jaspi impl
>>>> (probably via plugging in a
>>>> JaspiConstraintSecurityHandler).
>>> not sure what you mean here.... if you don't want to use the
>>> ServerAuthentication, RunAsToken, and UserIdentity abstractions it
>>> may
>>> be difficult to switch back and forth. If you mean you want to
>>> use the
>>> [Basic|Digest|Form|ClientCert]ServerAuthentication implementations
>>> for
>>> the known auth methods rather than the jaspi modules, I
>>> wholeheartedly
>>> agree.
>>
>> What gregw has been discussing with me is the possibility to retain
>> the
>> existing jetty-7 authorization code, making judicious changes as
>> necessary
>> in order to permit a jaspi-flavoured implementation to be plugged
>> in by
>> choice. The new jaspi stuff could be debugged, profiled and generally
>> kicked around a bit more until we could be comfortable that its at
>> least as correct and performant (in the sense of least object
>> creation
>> per request, lazy auth all in the right places etc) so that it could
>> then move to being the default authorization impl.
>>
>> Hence, a couple of emails ago I was starting to sketch out some
>> ideas of how we could achieve that, but the code base has moved on
>> somewhat since then, so I'm not sure how applicable those nascent
>> ideas
>> still are until I get a better grip on the changes.
>>
>> cheers
>> Jan
>>
>>
>>>> BTW, thanks for putting so much work into the security refactoring!
>>> np!
>>>
>>> david jencks
>>>
>>>>
>>>> Jan
>>>>
>>>>
>>>>> thanks!
>>>>> david jencks
>>>>>
>>>>>>
>>>>>> cheers
>>>>>> Jan
>>>>>>
>>>>>> David Jencks wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> I rewrote the standard auth methods as ServerAuthentication
>>>>>>> classes on
>>>>>>> the plane ride home. I implemented Lazy and Caching (in
>>>>>>> session and
>>>>>>> SSO) as wrappers. Seems to compile but I haven't tried the
>>>>>>> tck yet.
>>>>>>>
>>>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>>>> timeouts?? but
>>>>>>> I think this is a lot more plausible than the pure jaspi
>>>>>>> implementations.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>>>
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> I'm about to hop on a plane so will respond in more detail
>>>>>>>> later.
>>>>>>>>
>>>>>>>> I share your concerns about efficiency of the jaspi model,
>>>>>>>> which is
>>>>>>>> why I tried to put another hopefully efficient layer of
>>>>>>>> interfaces in
>>>>>>>> between the AbstractSecurityHandler and the jaspi auth
>>>>>>>> modules. I
>>>>>>>> was
>>>>>>>> hoping that we could simply implement the known auth methods
>>>>>>>> (FORM,
>>>>>>>> BASIC,...) in terms of the ServerAuthentication interface
>>>>>>>> directly
>>>>>>>> and retain all possible efficiencies. Not having done it yet
>>>>>>>> I might
>>>>>>>> have missed some important points :-)
>>>>>>>>
>>>>>>>> I'll think some more about your comments and get back to you.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>>>> give some more detailed comments.
>>>>>>>>>
>>>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>>>> like very much the refactoring of Abstract/
>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>> methods.
>>>>>>>>>
>>>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>>>> coming :)
>>>>>>>>>
>>>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>>>> is a role restriction will result in the user being fully
>>>>>>>>> reauthenticated. I understand that even this is an
>>>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>>>> requires validateRequest to be called on each and every
>>>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>>>> authentication when there are no role constraints is another
>>>>>>>>> good optimization.
>>>>>>>>>
>>>>>>>>> As there is going to be more authenticating going on as
>>>>>>>>> compared with the previous situation, my next reservation
>>>>>>>>> takes on more significance, and that is the amount of
>>>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>>>> callback design.
>>>>>>>>>
>>>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>>>
>>>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>>>> in mind?
>>>>>>>>>
>>>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>>>> without code to show.
>>>>>>>>>
>>>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>>>> to modify some of the interfaces of UserIdentity and
>>>>>>>>> LoginService
>>>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>>>> things a little:
>>>>>>>>>
>>>>>>>>> UserIdentity
>>>>>>>>> ------------
>>>>>>>>> Principal getUserPrincipal()
>>>>>>>>> String getAuthMethod()
>>>>>>>>> boolean isUserInRole(String role)
>>>>>>>>> setRunAsRole(RunAsToken)
>>>>>>>>> setServletHandler(ServletHandler)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> UserRealm (was LoginService)
>>>>>>>>> ---------
>>>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SecurityManager
>>>>>>>>> --------------
>>>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>>>> ----------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>>>> --------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> AbstractSecurityHandler
>>>>>>>>> ----------------------
>>>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>>>
>>>>>>>>> The AbstractSecurityHandler would be pretty much unchanged
>>>>>>>>> as it
>>>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>>>> where it currently invokes
>>>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>>>> (around line 169).
>>>>>>>>>
>>>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>>>> authenticator
>>>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>> did in the pre-jaspi version.
>>>>>>>>>
>>>>>>>>> The JaspiSecurityManager implementation would be equivalent
>>>>>>>>> to the
>>>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>>>
>>>>>>>>> Perhaps the biggest change would be to the LoginService,
>>>>>>>>> which I've
>>>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>>>> authentication related, rather than strictly login related. No
>>>>>>>>> problem though
>>>>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>>>>> method
>>>>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>>>>> LoginCallback
>>>>>>>>> instance on the Subject (via the ServletCallbackHandler). I
>>>>>>>>> don't
>>>>>>>>> see that as a major problem - the ServletCallbackHandler
>>>>>>>>> could set
>>>>>>>>> the UserIdentity object on the Subject instead. Note that in
>>>>>>>>> a jaspi
>>>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>>>> called, or
>>>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>>>
>>>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>>>> I think we'd need another set for the default jetty
>>>>>>>>> implementation
>>>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>>>> duplication
>>>>>>>>> would be highly desirable.
>>>>>>>>>
>>>>>>>>> From the user's perspective, it would be simple to configure
>>>>>>>>> jaspi:
>>>>>>>>>
>>>>>>>>> WebAppContext webApp = ...;
>>>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>>>> JaspiSecurityManager());
>>>>>>>>>
>>>>>>>>> I'm sure I haven't considered all aspects of pluggability.
>>>>>>>>> I'll try
>>>>>>>>> and get some time to turn the thoughts into code, which are
>>>>>>>>> a) more
>>>>>>>>> easily
>>>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> David Jencks wrote:
>>>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>>>
>>>>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>>>>> future,
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>>>
>>>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line
>>>>>>>>>>> 235 and
>>>>>>>>>>> 259.
>>>>>>>>>>>
>>>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>>>> again on
>>>>>>>>>>> the right connector (either the confidential or integral
>>>>>>>>>>> port as
>>>>>>>>>>> appropriate).
>>>>>>>>>>>
>>>>>>>>>>> cheers
>>>>>>>>>>> Jan
>>>>>>>>>>>
>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I
>>>>>>>>>>>>> just
>>>>>>>>>>>>> noticed
>>>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>>>> notices the request was received on the wrong connector
>>>>>>>>>>>>> (ie on
>>>>>>>>>>>>> http
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>> https) and does a redirect, the
>>>>>>>>>>>>> AbstractSecurityHandler.handle()
>>>>>>>>>>>>> method goes
>>>>>>>>>>>>> ahead and subjects the request to JASPI authentication.
>>>>>>>>>>>>> It seems
>>>>>>>>>>>>> to me
>>>>>>>>>>>>> that
>>>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>>>> altogether. It
>>>>>>>>>>>>> will
>>>>>>>>>>>>> be the redirected request that we're interested in
>>>>>>>>>>>>> processing
>>>>>>>>>>>>> further
>>>>>>>>>>>>> (either doing the auth or doing a redirect to a login
>>>>>>>>>>>>> form).
>>>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>>>
>>>>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>>>> {
>>>>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>>>>> {
>>>>>>>>>>>>
>>>>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>>>> base_request.setHandled(true);
>>>>>>>>>>>> }
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> I think there's something odd here, but IIUC something
>>>>>>>>>>>> other than
>>>>>>>>>>>> what
>>>>>>>>>>>> you see.
>>>>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>>>>> request.
>>>>>>>>>>>> I've been worrying about this because it prevents
>>>>>>>>>>>> redirecting
>>>>>>>>>>>> http
>>>>>>>>>>>> requests to the equivalent https requests. Until
>>>>>>>>>>>> recently I
>>>>>>>>>>>> didn't
>>>>>>>>>>>> think it was possible to do this redirect using jacc
>>>>>>>>>>>> permissions
>>>>>>>>>>>> but I
>>>>>>>>>>>> think there is a solution....
>>>>>>>>>>>>
>>>>>>>>>>>> If the actual request is denied and is http we could
>>>>>>>>>>>> create a new
>>>>>>>>>>>> request with the url converted to https and
>>>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>>>> it.... if that check succeeds we can redirect to the more
>>>>>>>>>>>> secure
>>>>>>>>>>>> url.
>>>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>>>> authentication is
>>>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>>>> with the
>>>>>>>>>>>> unauthenticated user.
>>>>>>>>>>>>
>>>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> cheers
>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>
>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the
>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are
>>>>>>>>>>>>>>> quasi
>>>>>>>>>>>>>>> analogous
>>>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour
>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to
>>>>>>>>>>>>>>> retain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>>>>> understand the
>>>>>>>>>>>>>> new code, I rather think it would be confusing. I'd
>>>>>>>>>>>>>> really
>>>>>>>>>>>>>> rather not
>>>>>>>>>>>>>> call UserIdentity a Principal since it isn't a
>>>>>>>>>>>>>> Principal and
>>>>>>>>>>>>>> depending
>>>>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> things. The main point of introducing it was that in
>>>>>>>>>>>>>> jetty
>>>>>>>>>>>>>> integrations
>>>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the
>>>>>>>>>>>>>> UserPrincipal was
>>>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>>>> non-principal
>>>>>>>>>>>>>> information associated with the user's identity. I
>>>>>>>>>>>>>> think that
>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>>>> whatever else the security system needs. I don't have
>>>>>>>>>>>>>> strong
>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>> to calling the LoginService UserRealm but I think its
>>>>>>>>>>>>>> going
>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be
>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>> important for
>>>>>>>>>>>>>>> Jetty users to be able to make a smooth transition
>>>>>>>>>>>>>>> over to a
>>>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm
>>>>>>>>>>>>>>> and a
>>>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> some extra methods and some changed implementations of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer
>>>>>>>>>>>>>> and more
>>>>>>>>>>>>>> descriptive for embedding jetty that the old ones. I
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>> look
>>>>>>>>>>>>>> into
>>>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>>>> LoginService to
>>>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>> I'm not
>>>>>>>>>>>>>> at all sure the non login-service methods on UserRealm
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>> plausibly
>>>>>>>>>>>>>> be called.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>> (well,
>>>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>> .getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>>>> LoginService is
>>>>>>>>>>>>>> final
>>>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler,
>>>>>>>>>>>>>> around
>>>>>>>>>>>>>> line 1042
>>>>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> much...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of
>>>>>>>>>>>>>>> callbacks it
>>>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>> the right info, such as credentials, passwords,
>>>>>>>>>>>>>>> usernames and
>>>>>>>>>>>>>>> also extra request parameters from the login. I notice
>>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the
>>>>>>>>>>>>>>> JAAS
>>>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler
>>>>>>>>>>>>>>> instead? It
>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I
>>>>>>>>>>>>>> think
>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>> extensions to a user-password callback handler all
>>>>>>>>>>>>>> involve
>>>>>>>>>>>>>> extracting
>>>>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>>>> service. A
>>>>>>>>>>>>>> login module that fishes directly in the request ought
>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>> refactored
>>>>>>>>>>>>>> into a plain login module that just validates the
>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>> and an
>>>>>>>>>>>>>> auth module that extracts the credentials from the
>>>>>>>>>>>>>> message.
>>>>>>>>>>>>>> Despite all
>>>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and
>>>>>>>>>>>>>> worth
>>>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I guess someone who really really wanted to preserve
>>>>>>>>>>>>>> their
>>>>>>>>>>>>>> login
>>>>>>>>>>>>>> module
>>>>>>>>>>>>>> could write a subclass of LoginCallback that dealt with
>>>>>>>>>>>>>> request
>>>>>>>>>>>>>> parameters, and a JAASLoginService subclass. This
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> made
>>>>>>>>>>>>>> easier
>>>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the
>>>>>>>>>>>>>>> RunAsToken
>>>>>>>>>>>>>>> marker
>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>>>> mappings
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>>> This is an embedding thing also. It's pretty unclear
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>> run-as is
>>>>>>>>>>>>>> actually supposed to mean and how things like supplying
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> identity for
>>>>>>>>>>>>>> a web service client or other remote call is supposed
>>>>>>>>>>>>>> to work.
>>>>>>>>>>>>>> (If the
>>>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>>>> credentials does
>>>>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>>>>> represent the
>>>>>>>>>>>>>> run-as role by a Subject obtained by logging into a
>>>>>>>>>>>>>> security
>>>>>>>>>>>>>> realm. So,
>>>>>>>>>>>>>> the geronimo run-as token has this Subject in it. We
>>>>>>>>>>>>>> might
>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't
>>>>>>>>>>>>>> think
>>>>>>>>>>>>>> constraining the representation of the run-as identity
>>>>>>>>>>>>>> is wise.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>> more or
>>>>>>>>>>>>>> less
>>>>>>>>>>>>>> agree on the main interfaces, at which time I plan to
>>>>>>>>>>>>>> rewrite
>>>>>>>>>>>>>> them in
>>>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and
>>>>>>>>>>>>>>>>> light on
>>>>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi
>>>>>>>>>>>>>>>>> branch,
>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey
>>>>>>>>>>>>>>>>> around, where
>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/jetty-
>>>>>>>>>>>>>>>> plus
>>>>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to
>>>>>>>>>>>>>>>>> you with
>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you
>>>>>>>>>>>>>>>>> that your
>>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in
>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>>> them back into more jetty specific code. Of course
>>>>>>>>>>>>>>>> if you
>>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity @#*($)#@&^)
>>>>>>>>>>>>>>>>> $@#&*$@
>>>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>>>> on at the end when someone realized it was
>>>>>>>>>>>>>>>> incomplete, and
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>>>> of CallbackHandler for two way communication between
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch
>>>>>>>>>>>>>>>>>> for me to
>>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>>>> integration with jetty and its getting to a point
>>>>>>>>>>>>>>>>>> where I'm
>>>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for
>>>>>>>>>>>>>>>>>> messaging
>>>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> client you can add auth info to a request and
>>>>>>>>>>>>>>>>>> validate auth
>>>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>> response. On the server you can validate auth info
>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and
>>>>>>>>>>>>>>>>>> transmit the
>>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the
>>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it
>>>>>>>>>>>>>>>>>> is more
>>>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>>>> integration with other app servers with their own
>>>>>>>>>>>>>>>>>> ideas
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make
>>>>>>>>>>>>>>>>>> jacc
>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried
>>>>>>>>>>>>>>>>>> to verify
>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I
>>>>>>>>>>>>>>>>>> plan to
>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response
>>>>>>>>>>>>>>>>>> pair on
>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle.
>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>>>> method that runs through the following structure
>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the
>>>>>>>>>>>>>>>>>> user data
>>>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>>>> basically that the request arrived over the right
>>>>>>>>>>>>>>>>>> kind of
>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this
>>>>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>> jetty constraint based implementation or one based
>>>>>>>>>>>>>>>>>> on JACC.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>>>> determine if the request actually needs
>>>>>>>>>>>>>>>>>> authentication.
>>>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> we can often delay authentication until a method
>>>>>>>>>>>>>>>>>> relying on
>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory
>>>>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass
>>>>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will
>>>>>>>>>>>>>>>>>> extract the
>>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided
>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash,
>>>>>>>>>>>>>>>>>> JDBC, etc
>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that
>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>>>> authentication when info is actually needed. In this
>>>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this
>>>>>>>>>>>>>>>>>> includes
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>>>> UserIdentity userIdentity =
>>>>>>>>>>>>>>>>>> newUserIdentity(authResult);
>>>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> actually answering auth questions from the
>>>>>>>>>>>>>>>>>> application
>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however
>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext,
>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now
>>>>>>>>>>>>>>>>>> secure
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework
>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>>>> (rather than the bits actually needed for http
>>>>>>>>>>>>>>>>>> which I
>>>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>>>> and have a nearly-untested openid implementation.
>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an
>>>>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with
>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just
>>>>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>> workflow described about and delegates all actual
>>>>>>>>>>>>>>>>>> work to
>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> authentication delegate. This makes it easy to
>>>>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>>>> implementations such as a JACC implementation for
>>>>>>>>>>>>>>>>>> an EE
>>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly
>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a
>>>>>>>>>>>>>>>>>> Principal
>>>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity
>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>>>> separate access to the auth results (user
>>>>>>>>>>>>>>>>>> principal) and
>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> interface. These typically delegate to
>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy
>>>>>>>>>>>>>>>>>> authentication if
>>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated
>>>>>>>>>>>>>>>>>> functions,
>>>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the
>>>>>>>>>>>>>>>>>> credential
>>>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>>>> in LoginService. Credential validation may not
>>>>>>>>>>>>>>>>>> even be
>>>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from
>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> extracts credentials from the request.
>>>>>>>>>>>>>>>>>> Implementations are
>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>>>> On the other hand the role handling is called by
>>>>>>>>>>>>>>>>>> jetty
>>>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService
>>>>>>>>>>>>>>>>>> relate to
>>>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>>> subject)
>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication
>>>>>>>>>>>>>>>>>> packages
>>>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal
>>>>>>>>>>>>>>>>>> and group
>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication
>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or....
>>>>>>>>>>>>>>>>>> you can
>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>>>> and stuff it into an adapter,
>>>>>>>>>>>>>>>>>> JaspiServerAuthentication.
>>>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>> ServerAuthModule implementations (a
>>>>>>>>>>>>>>>>>> ServerAuthContext is
>>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which
>>>>>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of
>>>>>>>>>>>>>>>>>> asking for
>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing
>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the
>>>>>>>>>>>>>>>>>> server:
>>>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller
>>>>>>>>>>>>>>>>>> principal so
>>>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user
>>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the
>>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird
>>>>>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging,
>>>>>>>>>>>>>>>>>> including ejb
>>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>>>> normally not a secured response. Trying to
>>>>>>>>>>>>>>>>>> evaluate auth
>>>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the
>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't see how this implementation could be
>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at
>>>>>>>>>>>>>>>>>> problems.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time
>>>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>> I can see that is possible with constraint
>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request
>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>>>> https request if a user data constraint is
>>>>>>>>>>>>>>>>>> violated. I'm
>>>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>> whether this is something people want to do or
>>>>>>>>>>>>>>>>>> usually set
>>>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>
>
> --
> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
Hi David,
David Jencks wrote:
> I've taken a very quick look at the AuthenticationManager you've added.
> It looks to me (based on this very non-thorough glance) that the main
> effect is to move some of the auth setup code out of WebXmlConfiguration
> and make it more accessible to programatic setup. For instance instead
> of having to know to use a BasicServerAuthentication you just need to
> know the string "BASIC". Is this more or less correct?
Yes, this means that WebXmlConfiguration no longer needs knowledge of what
authentication mechanism (jaspi or non-jaspi) is being used, and we can
defer the decision to the user which flavour they prefer.
> I like the idea of making it easier to configure authentication like
> this, but I think there might be a more flexible and less intrusive
> way. IIUC the runtime authentication behavior still works through the
> ServerAuthentication interface, and the added methods on
> AuthenticationManager are only used for setup. If someone wanted to
> implement their own ServerAuthentication these extra methods wouldn't
> really provide any extra value.
>
> What if we had something like a DefaultAuthenticationFactory that you
> set up with the security handler and called configure(String authMethod,
> String loginPage, String errorPage, String realm) on and it constructed
> the appropriate [Basic|Digest|Form|ClientCert]ServerAuthentication and
> set it in the security handler? We'd need something similar for the
> jaspi approach.
In general, Jetty doesn't really do factory pattern. Greg has even got
a bit of a factory-phobia :) He likes to refer to jetty's use of dependency
injection rather than factories. So the pluggable AuthenticationManager
does follow a Handler->Manager pattern that is already established in
the SessionHandler->SessionManager. We make the various implementations of
session clustering pluggable via the SessionManager.
I do agree that the AuthenticationManager and ServerAuthentication could
be simplified. But my suggestion would instead be to merge the
ServerAuthentication behaviour into the AuthenticationManager.
cheers
Jan
> To me this would seem to separate the configuration and runtime aspects
> nicely while still providing the advantages of simpler configuration of
> the default auth methods.
>
> I haven't looked at your jaspi code yet.... jaspi configuration is a bit
> convoluted IMNSHO and I actually suspect anyone using a jaspi module may
> want to set it up directly in code rather than dealing with a whole
> jaspi provider (which I wrote for geronimo but not jetty specifically)
> I'll look at this in a bit.
>
> Moving the login services seems like a very good idea :-)
>
> thanks
> david jencks
>
>
> On Nov 25, 2008, at 8:53 AM, Jan Bartel wrote:
>
>> Hi David,
>>
>> I've made some changes to attempt to make jaspi vs non-jaspi
>> authentication pluggable. I've checked the changes in, as I
>> thought it is easier to see the code than talk about it.
>>
>> In a nutshell, I've introduced an AuthenticationManager that
>> is used by a SecurityHandler to carry out all authentication,
>> and which delegates to either a non-jaspi or jaspi implementation.
>>
>> The ConstraintSecurityHandler uses a DefaultAuthenticationManager
>> (non-jaspi) by default, but one can plug in the
>> JaspiAuthenticationManager
>> as an alternative.
>>
>> The WebXmlConfiguration sets up information from the web.xml such
>> as the auth method and login/error pages on the AuthenticationManager,
>> but no longer sets up the various auth modules such as Basic, Form, Cert
>> etc. That is now done by the AuthenticationManager instance instead when
>> it is started, based on the auth information passed into it by the
>> WebXmlConfiguration
>> (or programmatically of course).
>>
>> I've allowed for the JaspiAuthenticationManager to plugin a jaspi auth
>> module,
>> so that potentially we can plug in 3rd party jaspi auth modules. The
>> question is,
>> is the pluggability at the right level? That is, I've allowed a
>> ServerAuth instance
>> to be set on the JaspiAuthenticationManager, but the
>> JaspiServerAuthentication
>> class expects a ServerAuthContext instead (which all of the FormAuth,
>> BasicAuth
>> etc classes implement) - would a 3rd party jaspi module be likely to
>> implement
>> that interface? Should we be allowing for plugging in some other class
>> entirely?
>>
>> BTW I changed around a couple of packages, most notably the
>> HashLoginService and
>> JDBCLoginService I moved out of
>> org.mortbay.jetty.security.jaspi.modules and into
>> org.mortbay.jetty.security, as AFAICT they are not jaspi specific.
>>
>> I noticed along the way that the SSO stuff isn't really hooked up.
>> Difficult to
>> see how to shoe-horn that into the new structure. Perhaps its time to
>> ditch it
>> and allow for integration with "real" SSO implementations instead?
>>
>> The jaspi branch builds and tests without error, but I'm just chasing
>> down an
>> error when running the test webapp:
>>
>> Failed startup of context
>> org.mortbay.jetty.webapp.WebAppContext@1e59128{/,/home/janb/src/jetty-jaspi/webapps/test}
>>
>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>> content-administrator, known roles: []
>>
>> And the same for the test-jaas webapp:
>>
>> Failed startup of context
>> org.mortbay.jetty.webapp.WebAppContext@10ffb38{/test-jaas,file:/home/janb/src/jetty-jaspi/webapps/test-jaas/}
>>
>> java.lang.IllegalArgumentException: Attempt to use undeclared role:
>> roleA, known roles: []
>>
>> Looks like something amiss with the role merging, perhaps.
>>
>> Have a look at what I've committed, and please let me know what you
>> think. I'm all ears if
>> you've got any suggestions or a better way.
>>
>> cheers
>> Jan
>>
>>
>>
>> Jan Bartel wrote:
>>> David,
>>> [snip]
>>>>>>> BTW, the code needs to be reformatted to jetty standard conventions
>>>>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>>>>>>> gregw will have conniptions ;)
>>>>>> hmm.... I thought I'd done pretty well imitating the code style.
>>>>>> Do you
>>>>>> have some way to fix it automatically?
>>>>> Lemme see ... as far as the brackets go, I have an eclipse codestyle
>>>>> that I can apply to each file, but the rigorous naming of data members
>>>>> with leading _
>>>>> or __ would have to be done manually.
>>>> aha.... I can fix that, probably tomorrow. The brackets might be
>>>> tougher for me.
>>>
>>> I've reformatted and checked in classes in jetty and jetty-security
>>> packages.
>>>
>>>>> Correct me if I'm wrong, but the constraint preprocessing behaviour is
>>>>> separable
>>>>> from the jaspi authentication, so we could make that common between a
>>>>> ConstraintSecurityHandler
>>>>> that invoked non-jaspi authentication and another
>>>>> ConstraintSecurityHandler that invoked
>>>>> jaspi authentication?
>>>> The authentication (jaspi or ServerAuthentication) and authorization
>>>> (constraints or jacc or....??) are completely separable, but I would
>>>> not try to guarantee that the behavior of the legacy constraint
>>>> security
>>>> handler would be unchanged if we combined the constraints up front. If
>>>> you guys are willing to risk that the legacy behavior will change or
>>>> analyze it carefully enough so you're sure it won't, combining the
>>>> constraints up front would really simplify the code. I don't
>>>> understand
>>>> how the legacy code works well enough to be comfortable claiming
>>>> anything about it.
>>>
>>> Well, I think the existing "legacy" code is a bit difficult to
>>> understand,
>>> which is why I think it is clearer to go with your new structure that
>>> does the preprocessing.
>>>
>>>
>>>>> In terms of pluggability, I think so far I'm still leaning towards a
>>>>> default of current
>>>>> jetty authentication impl, with pluggability of the jaspi impl
>>>>> (probably via plugging in a
>>>>> JaspiConstraintSecurityHandler).
>>>> not sure what you mean here.... if you don't want to use the
>>>> ServerAuthentication, RunAsToken, and UserIdentity abstractions it may
>>>> be difficult to switch back and forth. If you mean you want to use the
>>>> [Basic|Digest|Form|ClientCert]ServerAuthentication implementations for
>>>> the known auth methods rather than the jaspi modules, I wholeheartedly
>>>> agree.
>>>
>>> What gregw has been discussing with me is the possibility to retain the
>>> existing jetty-7 authorization code, making judicious changes as
>>> necessary
>>> in order to permit a jaspi-flavoured implementation to be plugged in by
>>> choice. The new jaspi stuff could be debugged, profiled and generally
>>> kicked around a bit more until we could be comfortable that its at
>>> least as correct and performant (in the sense of least object creation
>>> per request, lazy auth all in the right places etc) so that it could
>>> then move to being the default authorization impl.
>>>
>>> Hence, a couple of emails ago I was starting to sketch out some
>>> ideas of how we could achieve that, but the code base has moved on
>>> somewhat since then, so I'm not sure how applicable those nascent ideas
>>> still are until I get a better grip on the changes.
>>>
>>> cheers
>>> Jan
>>>
>>>
>>>>> BTW, thanks for putting so much work into the security refactoring!
>>>> np!
>>>>
>>>> david jencks
>>>>
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>>> thanks!
>>>>>> david jencks
>>>>>>
>>>>>>>
>>>>>>> cheers
>>>>>>> Jan
>>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> I rewrote the standard auth methods as ServerAuthentication
>>>>>>>> classes on
>>>>>>>> the plane ride home. I implemented Lazy and Caching (in session
>>>>>>>> and
>>>>>>>> SSO) as wrappers. Seems to compile but I haven't tried the tck
>>>>>>>> yet.
>>>>>>>>
>>>>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>>>>> timeouts?? but
>>>>>>>> I think this is a lot more plausible than the pure jaspi
>>>>>>>> implementations.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>>
>>>>>>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>>>>>>
>>>>>>>>> I share your concerns about efficiency of the jaspi model,
>>>>>>>>> which is
>>>>>>>>> why I tried to put another hopefully efficient layer of
>>>>>>>>> interfaces in
>>>>>>>>> between the AbstractSecurityHandler and the jaspi auth modules. I
>>>>>>>>> was
>>>>>>>>> hoping that we could simply implement the known auth methods
>>>>>>>>> (FORM,
>>>>>>>>> BASIC,...) in terms of the ServerAuthentication interface
>>>>>>>>> directly
>>>>>>>>> and retain all possible efficiencies. Not having done it yet I
>>>>>>>>> might
>>>>>>>>> have missed some important points :-)
>>>>>>>>>
>>>>>>>>> I'll think some more about your comments and get back to you.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>>>>> give some more detailed comments.
>>>>>>>>>>
>>>>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>>>>> like very much the refactoring of
>>>>>>>>>> Abstract/ConstraintSecurityHandler
>>>>>>>>>> methods.
>>>>>>>>>>
>>>>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>>>>> coming :)
>>>>>>>>>>
>>>>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>>>>> is a role restriction will result in the user being fully
>>>>>>>>>> reauthenticated. I understand that even this is an
>>>>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>>>>> requires validateRequest to be called on each and every
>>>>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>>>>> authentication when there are no role constraints is another
>>>>>>>>>> good optimization.
>>>>>>>>>>
>>>>>>>>>> As there is going to be more authenticating going on as
>>>>>>>>>> compared with the previous situation, my next reservation
>>>>>>>>>> takes on more significance, and that is the amount of
>>>>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>>>>> callback design.
>>>>>>>>>>
>>>>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>>>>
>>>>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>>>>> in mind?
>>>>>>>>>>
>>>>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>>>>> without code to show.
>>>>>>>>>>
>>>>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>>>>> to modify some of the interfaces of UserIdentity and LoginService
>>>>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>>>>> things a little:
>>>>>>>>>>
>>>>>>>>>> UserIdentity
>>>>>>>>>> ------------
>>>>>>>>>> Principal getUserPrincipal()
>>>>>>>>>> String getAuthMethod()
>>>>>>>>>> boolean isUserInRole(String role)
>>>>>>>>>> setRunAsRole(RunAsToken)
>>>>>>>>>> setServletHandler(ServletHandler)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> UserRealm (was LoginService)
>>>>>>>>>> ---------
>>>>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SecurityManager
>>>>>>>>>> --------------
>>>>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>>>>> ----------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>>>>> --------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> AbstractSecurityHandler
>>>>>>>>>> ----------------------
>>>>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>>>>
>>>>>>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>>>>> where it currently invokes
>>>>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>>>>> (around line 169).
>>>>>>>>>>
>>>>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>>>>> authenticator
>>>>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>>>>> ConstraintSecurityHandler
>>>>>>>>>> did in the pre-jaspi version.
>>>>>>>>>>
>>>>>>>>>> The JaspiSecurityManager implementation would be equivalent to
>>>>>>>>>> the
>>>>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>>>>
>>>>>>>>>> Perhaps the biggest change would be to the LoginService, which
>>>>>>>>>> I've
>>>>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>>>>> authentication related, rather than strictly login related. No
>>>>>>>>>> problem though
>>>>>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>>>>>> method
>>>>>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>>>>>> LoginCallback
>>>>>>>>>> instance on the Subject (via the ServletCallbackHandler). I don't
>>>>>>>>>> see that as a major problem - the ServletCallbackHandler could
>>>>>>>>>> set
>>>>>>>>>> the UserIdentity object on the Subject instead. Note that in a
>>>>>>>>>> jaspi
>>>>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>>>>> called, or
>>>>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>>>>
>>>>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>>>>> I think we'd need another set for the default jetty
>>>>>>>>>> implementation
>>>>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>>>>> duplication
>>>>>>>>>> would be highly desirable.
>>>>>>>>>>
>>>>>>>>>> From the user's perspective, it would be simple to configure
>>>>>>>>>> jaspi:
>>>>>>>>>>
>>>>>>>>>> WebAppContext webApp = ...;
>>>>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>>>>> JaspiSecurityManager());
>>>>>>>>>>
>>>>>>>>>> I'm sure I haven't considered all aspects of pluggability.
>>>>>>>>>> I'll try
>>>>>>>>>> and get some time to turn the thoughts into code, which are a)
>>>>>>>>>> more
>>>>>>>>>> easily
>>>>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> Jan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>>>>
>>>>>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>>>>>> future,
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>>>>
>>>>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235 and
>>>>>>>>>>>> 259.
>>>>>>>>>>>>
>>>>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>>>>> again on
>>>>>>>>>>>> the right connector (either the confidential or integral
>>>>>>>>>>>> port as
>>>>>>>>>>>> appropriate).
>>>>>>>>>>>>
>>>>>>>>>>>> cheers
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>>>>>>> noticed
>>>>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>>>>> notices the request was received on the wrong connector
>>>>>>>>>>>>>> (ie on
>>>>>>>>>>>>>> http
>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>> https) and does a redirect, the
>>>>>>>>>>>>>> AbstractSecurityHandler.handle()
>>>>>>>>>>>>>> method goes
>>>>>>>>>>>>>> ahead and subjects the request to JASPI authentication. It
>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>> to me
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>>>>> altogether. It
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be the redirected request that we're interested in processing
>>>>>>>>>>>>>> further
>>>>>>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>>>>
>>>>>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>>>>> {
>>>>>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>>>>>> {
>>>>>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>>>>> base_request.setHandled(true);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think there's something odd here, but IIUC something
>>>>>>>>>>>>> other than
>>>>>>>>>>>>> what
>>>>>>>>>>>>> you see.
>>>>>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>>>>>> request.
>>>>>>>>>>>>> I've been worrying about this because it prevents redirecting
>>>>>>>>>>>>> http
>>>>>>>>>>>>> requests to the equivalent https requests. Until recently I
>>>>>>>>>>>>> didn't
>>>>>>>>>>>>> think it was possible to do this redirect using jacc
>>>>>>>>>>>>> permissions
>>>>>>>>>>>>> but I
>>>>>>>>>>>>> think there is a solution....
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the actual request is denied and is http we could create
>>>>>>>>>>>>> a new
>>>>>>>>>>>>> request with the url converted to https and
>>>>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>>>>> it.... if that check succeeds we can redirect to the more
>>>>>>>>>>>>> secure
>>>>>>>>>>>>> url.
>>>>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>>>>> authentication is
>>>>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> unauthenticated user.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the jaspi
>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are
>>>>>>>>>>>>>>>> quasi
>>>>>>>>>>>>>>>> analogous
>>>>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour has
>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to retain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>>>>>> understand the
>>>>>>>>>>>>>>> new code, I rather think it would be confusing. I'd really
>>>>>>>>>>>>>>> rather not
>>>>>>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal and
>>>>>>>>>>>>>>> depending
>>>>>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> things. The main point of introducing it was that in jetty
>>>>>>>>>>>>>>> integrations
>>>>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the
>>>>>>>>>>>>>>> UserPrincipal was
>>>>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>>>>> non-principal
>>>>>>>>>>>>>>> information associated with the user's identity. I think
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>>>>> whatever else the security system needs. I don't have
>>>>>>>>>>>>>>> strong
>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>> to calling the LoginService UserRealm but I think its going
>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be quite
>>>>>>>>>>>>>>>> important for
>>>>>>>>>>>>>>>> Jetty users to be able to make a smooth transition over
>>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm
>>>>>>>>>>>>>>>> and a
>>>>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer and
>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>> descriptive for embedding jetty that the old ones. I could
>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>>>>> LoginService to
>>>>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>> I'm not
>>>>>>>>>>>>>>> at all sure the non login-service methods on UserRealm could
>>>>>>>>>>>>>>> plausibly
>>>>>>>>>>>>>>> be called.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>>>> (well,
>>>>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>>>>> WebAppContext.getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>>>>> LoginService is
>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler, around
>>>>>>>>>>>>>>> line 1042
>>>>>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this code
>>>>>>>>>>>>>>> much...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of
>>>>>>>>>>>>>>>> callbacks it
>>>>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>>>> the right info, such as credentials, passwords,
>>>>>>>>>>>>>>>> usernames and
>>>>>>>>>>>>>>>> also extra request parameters from the login. I notice
>>>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler
>>>>>>>>>>>>>>>> instead? It
>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I think
>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>>>>>>> extracting
>>>>>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>>>>> service. A
>>>>>>>>>>>>>>> login module that fishes directly in the request ought to be
>>>>>>>>>>>>>>> refactored
>>>>>>>>>>>>>>> into a plain login module that just validates the
>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>> and an
>>>>>>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>>>>>>> Despite all
>>>>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and worth
>>>>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I guess someone who really really wanted to preserve their
>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>> could write a subclass of LoginCallback that dealt with
>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>> parameters, and a JAASLoginService subclass. This would be
>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>> easier
>>>>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>>>>> into a
>>>>>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>>>>>>> marker
>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>>>>> mappings
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>>>> This is an embedding thing also. It's pretty unclear what
>>>>>>>>>>>>>>> run-as is
>>>>>>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>>>>>>> identity for
>>>>>>>>>>>>>>> a web service client or other remote call is supposed to
>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>> (If the
>>>>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>>>>> credentials does
>>>>>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>>>>>> represent the
>>>>>>>>>>>>>>> run-as role by a Subject obtained by logging into a security
>>>>>>>>>>>>>>> realm. So,
>>>>>>>>>>>>>>> the geronimo run-as token has this Subject in it. We might
>>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't think
>>>>>>>>>>>>>>> constraining the representation of the run-as identity is
>>>>>>>>>>>>>>> wise.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>>>>>>> more or
>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>> agree on the main interfaces, at which time I plan to
>>>>>>>>>>>>>>> rewrite
>>>>>>>>>>>>>>> them in
>>>>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and
>>>>>>>>>>>>>>>>>> light on
>>>>>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi branch,
>>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey around,
>>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/jetty-plus
>>>>>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to
>>>>>>>>>>>>>>>>>> you with
>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you that
>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>>>> them back into more jetty specific code. Of course if you
>>>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity
>>>>>>>>>>>>>>>>>> @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>>>>> on at the end when someone realized it was incomplete, and
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>>>>> of CallbackHandler for two way communication between the
>>>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for
>>>>>>>>>>>>>>>>>>> me to
>>>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>>>>> integration with jetty and its getting to a point
>>>>>>>>>>>>>>>>>>> where I'm
>>>>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for
>>>>>>>>>>>>>>>>>>> messaging
>>>>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> client you can add auth info to a request and
>>>>>>>>>>>>>>>>>>> validate auth
>>>>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>> response. On the server you can validate auth info on a
>>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and
>>>>>>>>>>>>>>>>>>> transmit the
>>>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal for
>>>>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi
>>>>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it is
>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>>>>> integration with other app servers with their own ideas
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to
>>>>>>>>>>>>>>>>>>> verify
>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response pair on
>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle. This
>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>>>>> method that runs through the following structure calling
>>>>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the user
>>>>>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>>>>> basically that the request arrived over the right
>>>>>>>>>>>>>>>>>>> kind of
>>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this
>>>>>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>> jetty constraint based implementation or one based on
>>>>>>>>>>>>>>>>>>> JACC.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> we can often delay authentication until a method
>>>>>>>>>>>>>>>>>>> relying on
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory into a
>>>>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass
>>>>>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will
>>>>>>>>>>>>>>>>>>> extract the
>>>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided
>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash, JDBC,
>>>>>>>>>>>>>>>>>>> etc
>>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>>>>> authentication when info is actually needed. In this
>>>>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this includes
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>>>>> UserIdentity userIdentity = newUserIdentity(authResult);
>>>>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however they
>>>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext, base_request,
>>>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now secure
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework implementation
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>>>>> (rather than the bits actually needed for http which I
>>>>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>>>>> and have a nearly-untested openid implementation. This
>>>>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an
>>>>>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just
>>>>>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>> workflow described about and delegates all actual
>>>>>>>>>>>>>>>>>>> work to
>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> authentication delegate. This makes it easy to plug in
>>>>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly these
>>>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a
>>>>>>>>>>>>>>>>>>> Principal
>>>>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity
>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>>>>> separate access to the auth results (user principal) and
>>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> interface. These typically delegate to
>>>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy
>>>>>>>>>>>>>>>>>>> authentication if
>>>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated
>>>>>>>>>>>>>>>>>>> functions,
>>>>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the
>>>>>>>>>>>>>>>>>>> credential
>>>>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>>>>> in LoginService. Credential validation may not even be
>>>>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from
>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> extracts credentials from the request.
>>>>>>>>>>>>>>>>>>> Implementations are
>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>>>>> On the other hand the role handling is called by jetty
>>>>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService relate to
>>>>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>>>> subject)
>>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo,
>>>>>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication
>>>>>>>>>>>>>>>>>>> packages
>>>>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal and
>>>>>>>>>>>>>>>>>>> group
>>>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication
>>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or.... you can
>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>>>>> and stuff it into an adapter, JaspiServerAuthentication.
>>>>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>> ServerAuthModule implementations (a ServerAuthContext is
>>>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which have
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of
>>>>>>>>>>>>>>>>>>> asking for
>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies the
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing response
>>>>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the
>>>>>>>>>>>>>>>>>>> server:
>>>>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller
>>>>>>>>>>>>>>>>>>> principal so
>>>>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user may be
>>>>>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird to me
>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging, including
>>>>>>>>>>>>>>>>>>> ejb
>>>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>>>>> normally not a secured response. Trying to evaluate
>>>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the
>>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't see how this implementation could be
>>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time now.
>>>>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>> I can see that is possible with constraint
>>>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request to the
>>>>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>>>>> https request if a user data constraint is violated.
>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> whether this is something people want to do or
>>>>>>>>>>>>>>>>>>> usually set
>>>>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
Hi David,
I've made some changes to attempt to make jaspi vs non-jaspi
authentication pluggable. I've checked the changes in, as I
thought it is easier to see the code than talk about it.
In a nutshell, I've introduced an AuthenticationManager that
is used by a SecurityHandler to carry out all authentication,
and which delegates to either a non-jaspi or jaspi implementation.
The ConstraintSecurityHandler uses a DefaultAuthenticationManager
(non-jaspi) by default, but one can plug in the JaspiAuthenticationManager
as an alternative.
The WebXmlConfiguration sets up information from the web.xml such
as the auth method and login/error pages on the AuthenticationManager,
but no longer sets up the various auth modules such as Basic, Form, Cert
etc. That is now done by the AuthenticationManager instance instead when
it is started, based on the auth information passed into it by the WebXmlConfiguration
(or programmatically of course).
I've allowed for the JaspiAuthenticationManager to plugin a jaspi auth module,
so that potentially we can plug in 3rd party jaspi auth modules. The question is,
is the pluggability at the right level? That is, I've allowed a ServerAuth instance
to be set on the JaspiAuthenticationManager, but the JaspiServerAuthentication
class expects a ServerAuthContext instead (which all of the FormAuth, BasicAuth
etc classes implement) - would a 3rd party jaspi module be likely to implement
that interface? Should we be allowing for plugging in some other class entirely?
BTW I changed around a couple of packages, most notably the HashLoginService and
JDBCLoginService I moved out of org.mortbay.jetty.security.jaspi.modules and into
org.mortbay.jetty.security, as AFAICT they are not jaspi specific.
I noticed along the way that the SSO stuff isn't really hooked up. Difficult to
see how to shoe-horn that into the new structure. Perhaps its time to ditch it
and allow for integration with "real" SSO implementations instead?
The jaspi branch builds and tests without error, but I'm just chasing down an
error when running the test webapp:
Failed startup of context org.mortbay.jetty.webapp.WebAppContext@1e59128{/,/home/janb/src/jetty-jaspi/webapps/test}
java.lang.IllegalArgumentException: Attempt to use undeclared role: content-administrator, known roles: []
And the same for the test-jaas webapp:
Failed startup of context org.mortbay.jetty.webapp.WebAppContext@10ffb38{/test-jaas,file:/home/janb/src/jetty-jaspi/webapps/test-jaas/}
java.lang.IllegalArgumentException: Attempt to use undeclared role: roleA, known roles: []
Looks like something amiss with the role merging, perhaps.
Have a look at what I've committed, and please let me know what you think. I'm all ears if
you've got any suggestions or a better way.
cheers
Jan
Jan Bartel wrote:
> David,
> [snip]
>>>>> BTW, the code needs to be reformatted to jetty standard conventions
>>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>>>>> gregw will have conniptions ;)
>>>> hmm.... I thought I'd done pretty well imitating the code style. Do you
>>>> have some way to fix it automatically?
>>> Lemme see ... as far as the brackets go, I have an eclipse codestyle
>>> that I can apply to each file, but the rigorous naming of data members
>>> with leading _
>>> or __ would have to be done manually.
>> aha.... I can fix that, probably tomorrow. The brackets might be
>> tougher for me.
>
> I've reformatted and checked in classes in jetty and jetty-security
> packages.
>
>>> Correct me if I'm wrong, but the constraint preprocessing behaviour is
>>> separable
>>> from the jaspi authentication, so we could make that common between a
>>> ConstraintSecurityHandler
>>> that invoked non-jaspi authentication and another
>>> ConstraintSecurityHandler that invoked
>>> jaspi authentication?
>> The authentication (jaspi or ServerAuthentication) and authorization
>> (constraints or jacc or....??) are completely separable, but I would
>> not try to guarantee that the behavior of the legacy constraint security
>> handler would be unchanged if we combined the constraints up front. If
>> you guys are willing to risk that the legacy behavior will change or
>> analyze it carefully enough so you're sure it won't, combining the
>> constraints up front would really simplify the code. I don't understand
>> how the legacy code works well enough to be comfortable claiming
>> anything about it.
>
> Well, I think the existing "legacy" code is a bit difficult to understand,
> which is why I think it is clearer to go with your new structure that
> does the preprocessing.
>
>
>>> In terms of pluggability, I think so far I'm still leaning towards a
>>> default of current
>>> jetty authentication impl, with pluggability of the jaspi impl
>>> (probably via plugging in a
>>> JaspiConstraintSecurityHandler).
>> not sure what you mean here.... if you don't want to use the
>> ServerAuthentication, RunAsToken, and UserIdentity abstractions it may
>> be difficult to switch back and forth. If you mean you want to use the
>> [Basic|Digest|Form|ClientCert]ServerAuthentication implementations for
>> the known auth methods rather than the jaspi modules, I wholeheartedly
>> agree.
>
> What gregw has been discussing with me is the possibility to retain the
> existing jetty-7 authorization code, making judicious changes as necessary
> in order to permit a jaspi-flavoured implementation to be plugged in by
> choice. The new jaspi stuff could be debugged, profiled and generally
> kicked around a bit more until we could be comfortable that its at
> least as correct and performant (in the sense of least object creation
> per request, lazy auth all in the right places etc) so that it could
> then move to being the default authorization impl.
>
> Hence, a couple of emails ago I was starting to sketch out some
> ideas of how we could achieve that, but the code base has moved on
> somewhat since then, so I'm not sure how applicable those nascent ideas
> still are until I get a better grip on the changes.
>
> cheers
> Jan
>
>
>>> BTW, thanks for putting so much work into the security refactoring!
>> np!
>>
>> david jencks
>>
>>>
>>> Jan
>>>
>>>
>>>> thanks!
>>>> david jencks
>>>>
>>>>>
>>>>> cheers
>>>>> Jan
>>>>>
>>>>> David Jencks wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> I rewrote the standard auth methods as ServerAuthentication classes on
>>>>>> the plane ride home. I implemented Lazy and Caching (in session and
>>>>>> SSO) as wrappers. Seems to compile but I haven't tried the tck yet.
>>>>>>
>>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>>> timeouts?? but
>>>>>> I think this is a lot more plausible than the pure jaspi
>>>>>> implementations.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>>
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>>>>
>>>>>>> I share your concerns about efficiency of the jaspi model, which is
>>>>>>> why I tried to put another hopefully efficient layer of interfaces in
>>>>>>> between the AbstractSecurityHandler and the jaspi auth modules. I
>>>>>>> was
>>>>>>> hoping that we could simply implement the known auth methods (FORM,
>>>>>>> BASIC,...) in terms of the ServerAuthentication interface directly
>>>>>>> and retain all possible efficiencies. Not having done it yet I might
>>>>>>> have missed some important points :-)
>>>>>>>
>>>>>>> I'll think some more about your comments and get back to you.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>>> give some more detailed comments.
>>>>>>>>
>>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>>> like very much the refactoring of Abstract/ConstraintSecurityHandler
>>>>>>>> methods.
>>>>>>>>
>>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>>> coming :)
>>>>>>>>
>>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>>> is a role restriction will result in the user being fully
>>>>>>>> reauthenticated. I understand that even this is an
>>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>>> requires validateRequest to be called on each and every
>>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>>> authentication when there are no role constraints is another
>>>>>>>> good optimization.
>>>>>>>>
>>>>>>>> As there is going to be more authenticating going on as
>>>>>>>> compared with the previous situation, my next reservation
>>>>>>>> takes on more significance, and that is the amount of
>>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>>> callback design.
>>>>>>>>
>>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>>
>>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>>> in mind?
>>>>>>>>
>>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>>> without code to show.
>>>>>>>>
>>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>>> to modify some of the interfaces of UserIdentity and LoginService
>>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>>> things a little:
>>>>>>>>
>>>>>>>> UserIdentity
>>>>>>>> ------------
>>>>>>>> Principal getUserPrincipal()
>>>>>>>> String getAuthMethod()
>>>>>>>> boolean isUserInRole(String role)
>>>>>>>> setRunAsRole(RunAsToken)
>>>>>>>> setServletHandler(ServletHandler)
>>>>>>>>
>>>>>>>>
>>>>>>>> UserRealm (was LoginService)
>>>>>>>> ---------
>>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>>
>>>>>>>>
>>>>>>>> SecurityManager
>>>>>>>> --------------
>>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>>
>>>>>>>>
>>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>>> ----------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>>> --------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> AbstractSecurityHandler
>>>>>>>> ----------------------
>>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>>
>>>>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>>> where it currently invokes
>>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>>> (around line 169).
>>>>>>>>
>>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>>> authenticator
>>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>>> ConstraintSecurityHandler
>>>>>>>> did in the pre-jaspi version.
>>>>>>>>
>>>>>>>> The JaspiSecurityManager implementation would be equivalent to the
>>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>>
>>>>>>>> Perhaps the biggest change would be to the LoginService, which I've
>>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>>> authentication related, rather than strictly login related. No
>>>>>>>> problem though
>>>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>>>> method
>>>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>>>> LoginCallback
>>>>>>>> instance on the Subject (via the ServletCallbackHandler). I don't
>>>>>>>> see that as a major problem - the ServletCallbackHandler could set
>>>>>>>> the UserIdentity object on the Subject instead. Note that in a jaspi
>>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>>> called, or
>>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>>
>>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>>> I think we'd need another set for the default jetty implementation
>>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>>> duplication
>>>>>>>> would be highly desirable.
>>>>>>>>
>>>>>>>> From the user's perspective, it would be simple to configure jaspi:
>>>>>>>>
>>>>>>>> WebAppContext webApp = ...;
>>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>>> JaspiSecurityManager());
>>>>>>>>
>>>>>>>> I'm sure I haven't considered all aspects of pluggability. I'll try
>>>>>>>> and get some time to turn the thoughts into code, which are a) more
>>>>>>>> easily
>>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> Jan
>>>>>>>>
>>>>>>>>
>>>>>>>> David Jencks wrote:
>>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>>
>>>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>>>> future,
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>>
>>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235 and
>>>>>>>>>> 259.
>>>>>>>>>>
>>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>>> again on
>>>>>>>>>> the right connector (either the confidential or integral port as
>>>>>>>>>> appropriate).
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> Jan
>>>>>>>>>>
>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>>>>> noticed
>>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>>> notices the request was received on the wrong connector (ie on
>>>>>>>>>>>> http
>>>>>>>>>>>> instead of
>>>>>>>>>>>> https) and does a redirect, the AbstractSecurityHandler.handle()
>>>>>>>>>>>> method goes
>>>>>>>>>>>> ahead and subjects the request to JASPI authentication. It seems
>>>>>>>>>>>> to me
>>>>>>>>>>>> that
>>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>>> altogether. It
>>>>>>>>>>>> will
>>>>>>>>>>>> be the redirected request that we're interested in processing
>>>>>>>>>>>> further
>>>>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>>
>>>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>>> {
>>>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>>>> {
>>>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>>> base_request.setHandled(true);
>>>>>>>>>>> }
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I think there's something odd here, but IIUC something other than
>>>>>>>>>>> what
>>>>>>>>>>> you see.
>>>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>>>> request.
>>>>>>>>>>> I've been worrying about this because it prevents redirecting
>>>>>>>>>>> http
>>>>>>>>>>> requests to the equivalent https requests. Until recently I
>>>>>>>>>>> didn't
>>>>>>>>>>> think it was possible to do this redirect using jacc permissions
>>>>>>>>>>> but I
>>>>>>>>>>> think there is a solution....
>>>>>>>>>>>
>>>>>>>>>>> If the actual request is denied and is http we could create a new
>>>>>>>>>>> request with the url converted to https and
>>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>>> it.... if that check succeeds we can redirect to the more secure
>>>>>>>>>>> url.
>>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>>> authentication is
>>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>>> with the
>>>>>>>>>>> unauthenticated user.
>>>>>>>>>>>
>>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> cheers
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the jaspi
>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are quasi
>>>>>>>>>>>>>> analogous
>>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour has
>>>>>>>>>>>>>> been
>>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to retain
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> old
>>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>>>> understand the
>>>>>>>>>>>>> new code, I rather think it would be confusing. I'd really
>>>>>>>>>>>>> rather not
>>>>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal and
>>>>>>>>>>>>> depending
>>>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>>>> different
>>>>>>>>>>>>> things. The main point of introducing it was that in jetty
>>>>>>>>>>>>> integrations
>>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the UserPrincipal was
>>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>>> non-principal
>>>>>>>>>>>>> information associated with the user's identity. I think that
>>>>>>>>>>>>> instead
>>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>>> whatever else the security system needs. I don't have strong
>>>>>>>>>>>>> objection
>>>>>>>>>>>>> to calling the LoginService UserRealm but I think its going
>>>>>>>>>>>>> to be
>>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be quite
>>>>>>>>>>>>>> important for
>>>>>>>>>>>>>> Jetty users to be able to make a smooth transition over to a
>>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm and a
>>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer and more
>>>>>>>>>>>>> descriptive for embedding jetty that the old ones. I could
>>>>>>>>>>>>> look
>>>>>>>>>>>>> into
>>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>>> LoginService to
>>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>>>> particular
>>>>>>>>>>>>> I'm not
>>>>>>>>>>>>> at all sure the non login-service methods on UserRealm could
>>>>>>>>>>>>> plausibly
>>>>>>>>>>>>> be called.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>>> (well,
>>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>>> WebAppContext.getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>>> LoginService is
>>>>>>>>>>>>> final
>>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler, around
>>>>>>>>>>>>> line 1042
>>>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this code
>>>>>>>>>>>>> much...
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of callbacks it
>>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>>>> plug in
>>>>>>>>>>>>>> the right info, such as credentials, passwords, usernames and
>>>>>>>>>>>>>> also extra request parameters from the login. I notice you're
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler instead? It
>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>> may
>>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I think
>>>>>>>>>>>>> that the
>>>>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>>>>> extracting
>>>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>>>> this is
>>>>>>>>>>>>> the
>>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>>> service. A
>>>>>>>>>>>>> login module that fishes directly in the request ought to be
>>>>>>>>>>>>> refactored
>>>>>>>>>>>>> into a plain login module that just validates the credentials
>>>>>>>>>>>>> and an
>>>>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>>>>> Despite all
>>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and worth
>>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess someone who really really wanted to preserve their
>>>>>>>>>>>>> login
>>>>>>>>>>>>> module
>>>>>>>>>>>>> could write a subclass of LoginCallback that dealt with request
>>>>>>>>>>>>> parameters, and a JAASLoginService subclass. This would be
>>>>>>>>>>>>> made
>>>>>>>>>>>>> easier
>>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>>> into a
>>>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>>>> handling
>>>>>>>>>>>>> there
>>>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>>>>> marker
>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>>> mappings
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>> This is an embedding thing also. It's pretty unclear what
>>>>>>>>>>>>> run-as is
>>>>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>>>>> identity for
>>>>>>>>>>>>> a web service client or other remote call is supposed to work.
>>>>>>>>>>>>> (If the
>>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>>> than the
>>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>>> credentials does
>>>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>>>> represent the
>>>>>>>>>>>>> run-as role by a Subject obtained by logging into a security
>>>>>>>>>>>>> realm. So,
>>>>>>>>>>>>> the geronimo run-as token has this Subject in it. We might
>>>>>>>>>>>>> want to
>>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't think
>>>>>>>>>>>>> constraining the representation of the run-as identity is wise.
>>>>>>>>>>>>>
>>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>>>>> more or
>>>>>>>>>>>>> less
>>>>>>>>>>>>> agree on the main interfaces, at which time I plan to rewrite
>>>>>>>>>>>>> them in
>>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and light on
>>>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi branch,
>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey around, where
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/jetty-plus
>>>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to you with
>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you that your
>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>> them back into more jetty specific code. Of course if you
>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>>> on at the end when someone realized it was incomplete, and
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>>> of CallbackHandler for two way communication between the
>>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for me to
>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>>> integration with jetty and its getting to a point where I'm
>>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for messaging
>>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> client you can add auth info to a request and validate auth
>>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>> response. On the server you can validate auth info on a
>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and transmit the
>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal for
>>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi
>>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it is more
>>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>>> integration with other app servers with their own ideas
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to verify
>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response pair on
>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle. This
>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>>> method that runs through the following structure calling
>>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the user data
>>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>>> basically that the request arrived over the right kind of
>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this are the
>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>> jetty constraint based implementation or one based on JACC.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> we can often delay authentication until a method relying on
>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory into a
>>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass various
>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will extract the
>>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided to the
>>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash, JDBC, etc
>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>>> authentication when info is actually needed. In this
>>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this includes
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>>> UserIdentity userIdentity = newUserIdentity(authResult);
>>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however they
>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext, base_request,
>>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now secure
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework implementation
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>>> (rather than the bits actually needed for http which I
>>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>>> and have a nearly-untested openid implementation. This
>>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an appropriate
>>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just has the
>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>> workflow described about and delegates all actual work to
>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> authentication delegate. This makes it easy to plug in
>>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly these
>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a Principal
>>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity interface
>>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>>> separate access to the auth results (user principal) and
>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> interface. These typically delegate to implementations of
>>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy authentication if
>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated functions,
>>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the credential
>>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>>> in LoginService. Credential validation may not even be
>>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from something
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> extracts credentials from the request. Implementations are
>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>>> On the other hand the role handling is called by jetty
>>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService relate to
>>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject subject)
>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication packages
>>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal and group
>>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication support
>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or.... you can
>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>>> and stuff it into an adapter, JaspiServerAuthentication.
>>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>> ServerAuthModule implementations (a ServerAuthContext is
>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which have the
>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of asking for
>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies the
>>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing response
>>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the server:
>>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller principal so
>>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user may be
>>>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird to me
>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging, including ejb
>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>>> normally not a secured response. Trying to evaluate auth
>>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the original
>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't see how this implementation could be significantly
>>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time now.
>>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>> I can see that is possible with constraint implementations
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request to the
>>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>>> https request if a user data constraint is violated. I'm
>>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> whether this is something people want to do or usually set
>>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>> --
>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
--
Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
David,
[snip]
>>>> BTW, the code needs to be reformatted to jetty standard conventions
>>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>>>> gregw will have conniptions ;)
>>>
>>> hmm.... I thought I'd done pretty well imitating the code style. Do you
>>> have some way to fix it automatically?
>>
>> Lemme see ... as far as the brackets go, I have an eclipse codestyle
>> that I can apply to each file, but the rigorous naming of data members
>> with leading _
>> or __ would have to be done manually.
>
> aha.... I can fix that, probably tomorrow. The brackets might be
> tougher for me.
I've reformatted and checked in classes in jetty and jetty-security
packages.
>> Correct me if I'm wrong, but the constraint preprocessing behaviour is
>> separable
>> from the jaspi authentication, so we could make that common between a
>> ConstraintSecurityHandler
>> that invoked non-jaspi authentication and another
>> ConstraintSecurityHandler that invoked
>> jaspi authentication?
>
> The authentication (jaspi or ServerAuthentication) and authorization
> (constraints or jacc or....??) are completely separable, but I would
> not try to guarantee that the behavior of the legacy constraint security
> handler would be unchanged if we combined the constraints up front. If
> you guys are willing to risk that the legacy behavior will change or
> analyze it carefully enough so you're sure it won't, combining the
> constraints up front would really simplify the code. I don't understand
> how the legacy code works well enough to be comfortable claiming
> anything about it.
Well, I think the existing "legacy" code is a bit difficult to understand,
which is why I think it is clearer to go with your new structure that
does the preprocessing.
>> In terms of pluggability, I think so far I'm still leaning towards a
>> default of current
>> jetty authentication impl, with pluggability of the jaspi impl
>> (probably via plugging in a
>> JaspiConstraintSecurityHandler).
>
> not sure what you mean here.... if you don't want to use the
> ServerAuthentication, RunAsToken, and UserIdentity abstractions it may
> be difficult to switch back and forth. If you mean you want to use the
> [Basic|Digest|Form|ClientCert]ServerAuthentication implementations for
> the known auth methods rather than the jaspi modules, I wholeheartedly
> agree.
What gregw has been discussing with me is the possibility to retain the
existing jetty-7 authorization code, making judicious changes as necessary
in order to permit a jaspi-flavoured implementation to be plugged in by
choice. The new jaspi stuff could be debugged, profiled and generally
kicked around a bit more until we could be comfortable that its at
least as correct and performant (in the sense of least object creation
per request, lazy auth all in the right places etc) so that it could
then move to being the default authorization impl.
Hence, a couple of emails ago I was starting to sketch out some
ideas of how we could achieve that, but the code base has moved on
somewhat since then, so I'm not sure how applicable those nascent ideas
still are until I get a better grip on the changes.
cheers
Jan
>> BTW, thanks for putting so much work into the security refactoring!
>
> np!
>
> david jencks
>
>>
>>
>> Jan
>>
>>
>>>
>>> thanks!
>>> david jencks
>>>
>>>>
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>> David Jencks wrote:
>>>>> Hi Jan,
>>>>>
>>>>> I rewrote the standard auth methods as ServerAuthentication classes on
>>>>> the plane ride home. I implemented Lazy and Caching (in session and
>>>>> SSO) as wrappers. Seems to compile but I haven't tried the tck yet.
>>>>>
>>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>>> timeouts?? but
>>>>> I think this is a lot more plausible than the pure jaspi
>>>>> implementations.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>>
>>>>>> Hi Jan,
>>>>>>
>>>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>>>
>>>>>> I share your concerns about efficiency of the jaspi model, which is
>>>>>> why I tried to put another hopefully efficient layer of interfaces in
>>>>>> between the AbstractSecurityHandler and the jaspi auth modules. I
>>>>>> was
>>>>>> hoping that we could simply implement the known auth methods (FORM,
>>>>>> BASIC,...) in terms of the ServerAuthentication interface directly
>>>>>> and retain all possible efficiencies. Not having done it yet I might
>>>>>> have missed some important points :-)
>>>>>>
>>>>>> I'll think some more about your comments and get back to you.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>>> having looked more closely at the code, I'm in a position to
>>>>>>> give some more detailed comments.
>>>>>>>
>>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>>> made with the UserIdentity and LoginService as compared
>>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>>> like very much the refactoring of Abstract/ConstraintSecurityHandler
>>>>>>> methods.
>>>>>>>
>>>>>>> Here's the place where your antennae should sense a "but"
>>>>>>> coming :)
>>>>>>>
>>>>>>> But ... I have some reservations about the efficiency of
>>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>>> is a role restriction will result in the user being fully
>>>>>>> reauthenticated. I understand that even this is an
>>>>>>> optimization and departure from the jaspi spec, which
>>>>>>> requires validateRequest to be called on each and every
>>>>>>> request, unless you know apriori that there is an exclusion
>>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>>> authentication when there are no role constraints is another
>>>>>>> good optimization.
>>>>>>>
>>>>>>> As there is going to be more authenticating going on as
>>>>>>> compared with the previous situation, my next reservation
>>>>>>> takes on more significance, and that is the amount of
>>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>>> callback design.
>>>>>>>
>>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>>> In a clustered environment that would be undesirable.
>>>>>>>
>>>>>>> It seems to me that although we could tweak things a bit,
>>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>>> from the spec which does not seem to have efficiency as a
>>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>>> in mind?
>>>>>>>
>>>>>>> I'm wondering whether we could give the user the choice
>>>>>>> of security implmentation, but making both jetty "default"
>>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>>> had a brief poke around and I don't think it would take that
>>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>>> without code to show.
>>>>>>>
>>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>>> to modify some of the interfaces of UserIdentity and LoginService
>>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>>> things a little:
>>>>>>>
>>>>>>> UserIdentity
>>>>>>> ------------
>>>>>>> Principal getUserPrincipal()
>>>>>>> String getAuthMethod()
>>>>>>> boolean isUserInRole(String role)
>>>>>>> setRunAsRole(RunAsToken)
>>>>>>> setServletHandler(ServletHandler)
>>>>>>>
>>>>>>>
>>>>>>> UserRealm (was LoginService)
>>>>>>> ---------
>>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>>
>>>>>>>
>>>>>>> SecurityManager
>>>>>>> --------------
>>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>>
>>>>>>>
>>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>>> ----------------------
>>>>>>>
>>>>>>>
>>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>>> --------------------
>>>>>>>
>>>>>>>
>>>>>>> AbstractSecurityHandler
>>>>>>> ----------------------
>>>>>>> + setSecurityManager (SecurityManager)
>>>>>>>
>>>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>>>> is now, except for the addition of a setter and getter for a
>>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>>> where it currently invokes
>>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>>> (around line 169).
>>>>>>>
>>>>>>> The DefaultSecurityManager implementation would call the
>>>>>>> authenticator
>>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>>> ConstraintSecurityHandler
>>>>>>> did in the pre-jaspi version.
>>>>>>>
>>>>>>> The JaspiSecurityManager implementation would be equivalent to the
>>>>>>> JaspiServerAuthentication class functionality.
>>>>>>>
>>>>>>> Perhaps the biggest change would be to the LoginService, which I've
>>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>>> authentication related, rather than strictly login related. No
>>>>>>> problem though
>>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>>> method
>>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>>> LoginCallback
>>>>>>> instance on the Subject (via the ServletCallbackHandler). I don't
>>>>>>> see that as a major problem - the ServletCallbackHandler could set
>>>>>>> the UserIdentity object on the Subject instead. Note that in a jaspi
>>>>>>> implementation, I expect that reauthenticate would never be
>>>>>>> called, or
>>>>>>> if it was, it would call authenticate() instead.
>>>>>>>
>>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>>> I think we'd need another set for the default jetty implementation
>>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>>> they should be able to share a majority of code - avoiding
>>>>>>> duplication
>>>>>>> would be highly desirable.
>>>>>>>
>>>>>>> From the user's perspective, it would be simple to configure jaspi:
>>>>>>>
>>>>>>> WebAppContext webApp = ...;
>>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>>> JaspiSecurityManager());
>>>>>>>
>>>>>>> I'm sure I haven't considered all aspects of pluggability. I'll try
>>>>>>> and get some time to turn the thoughts into code, which are a) more
>>>>>>> easily
>>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>>
>>>>>>> cheers
>>>>>>> Jan
>>>>>>>
>>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>>
>>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>>> future,
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> No, I'm referring to this code:
>>>>>>>>>
>>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235 and
>>>>>>>>> 259.
>>>>>>>>>
>>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>>> again on
>>>>>>>>> the right connector (either the confidential or integral port as
>>>>>>>>> appropriate).
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>>> David Jencks wrote:
>>>>>>>>>>
>>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>>>> noticed
>>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>>> notices the request was received on the wrong connector (ie on
>>>>>>>>>>> http
>>>>>>>>>>> instead of
>>>>>>>>>>> https) and does a redirect, the AbstractSecurityHandler.handle()
>>>>>>>>>>> method goes
>>>>>>>>>>> ahead and subjects the request to JASPI authentication. It seems
>>>>>>>>>>> to me
>>>>>>>>>>> that
>>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>>> altogether. It
>>>>>>>>>>> will
>>>>>>>>>>> be the redirected request that we're interested in processing
>>>>>>>>>>> further
>>>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>>>
>>>>>>>>>> I think you are referring to this code?
>>>>>>>>>>
>>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>>> {
>>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>>> {
>>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>>> base_request.setHandled(true);
>>>>>>>>>> }
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> I think there's something odd here, but IIUC something other than
>>>>>>>>>> what
>>>>>>>>>> you see.
>>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>>> request.
>>>>>>>>>> I've been worrying about this because it prevents redirecting
>>>>>>>>>> http
>>>>>>>>>> requests to the equivalent https requests. Until recently I
>>>>>>>>>> didn't
>>>>>>>>>> think it was possible to do this redirect using jacc permissions
>>>>>>>>>> but I
>>>>>>>>>> think there is a solution....
>>>>>>>>>>
>>>>>>>>>> If the actual request is denied and is http we could create a new
>>>>>>>>>> request with the url converted to https and
>>>>>>>>>> checkUserDataPermissions on
>>>>>>>>>> it.... if that check succeeds we can redirect to the more secure
>>>>>>>>>> url.
>>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>>> authentication is
>>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>>> with the
>>>>>>>>>> unauthenticated user.
>>>>>>>>>>
>>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> cheers
>>>>>>>>>>> Jan
>>>>>>>>>>>
>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm still snatching time to tiptoe further around the jaspi
>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are quasi
>>>>>>>>>>>>> analogous
>>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour has
>>>>>>>>>>>>> been
>>>>>>>>>>>>> refactored).
>>>>>>>>>>>>> I'm wondering whether it might not be a good idea to retain
>>>>>>>>>>>>> the
>>>>>>>>>>>>> old
>>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>>> users/developers
>>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>>> understand the
>>>>>>>>>>>> new code, I rather think it would be confusing. I'd really
>>>>>>>>>>>> rather not
>>>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal and
>>>>>>>>>>>> depending
>>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>>> different
>>>>>>>>>>>> things. The main point of introducing it was that in jetty
>>>>>>>>>>>> integrations
>>>>>>>>>>>> (Geronimo and from distant memory JBoss) the UserPrincipal was
>>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>>> non-principal
>>>>>>>>>>>> information associated with the user's identity. I think that
>>>>>>>>>>>> instead
>>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>>> whatever else the security system needs. I don't have strong
>>>>>>>>>>>> objection
>>>>>>>>>>>> to calling the LoginService UserRealm but I think its going
>>>>>>>>>>>> to be
>>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>>
>>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be quite
>>>>>>>>>>>>> important for
>>>>>>>>>>>>> Jetty users to be able to make a smooth transition over to a
>>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm and a
>>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>>> with
>>>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>>>> existing
>>>>>>>>>>>>> apis?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer and more
>>>>>>>>>>>> descriptive for embedding jetty that the old ones. I could
>>>>>>>>>>>> look
>>>>>>>>>>>> into
>>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>>> LoginService to
>>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>>> particular
>>>>>>>>>>>> I'm not
>>>>>>>>>>>> at all sure the non login-service methods on UserRealm could
>>>>>>>>>>>> plausibly
>>>>>>>>>>>> be called.
>>>>>>>>>>>>
>>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>>> (well,
>>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>>> WebAppContext.getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>>> list of
>>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>>> enough to
>>>>>>>>>>>>> put in though?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>>> LoginService is
>>>>>>>>>>>> final
>>>>>>>>>>>> and set in the constructor of ServletCallbackHandler, around
>>>>>>>>>>>> line 1042
>>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this code
>>>>>>>>>>>> much...
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of callbacks it
>>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>>> plug in
>>>>>>>>>>>>> the right info, such as credentials, passwords, usernames and
>>>>>>>>>>>>> also extra request parameters from the login. I notice you're
>>>>>>>>>>>>> using
>>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler instead? It
>>>>>>>>>>>>> supports
>>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>>> implementations
>>>>>>>>>>>>> may
>>>>>>>>>>>>> depend on.
>>>>>>>>>>>>
>>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I think
>>>>>>>>>>>> that the
>>>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>>>> extracting
>>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>>> this is
>>>>>>>>>>>> the
>>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>>> service. A
>>>>>>>>>>>> login module that fishes directly in the request ought to be
>>>>>>>>>>>> refactored
>>>>>>>>>>>> into a plain login module that just validates the credentials
>>>>>>>>>>>> and an
>>>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>>>> Despite all
>>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and worth
>>>>>>>>>>>> enforcing.
>>>>>>>>>>>>
>>>>>>>>>>>> I guess someone who really really wanted to preserve their
>>>>>>>>>>>> login
>>>>>>>>>>>> module
>>>>>>>>>>>> could write a subclass of LoginCallback that dealt with request
>>>>>>>>>>>> parameters, and a JAASLoginService subclass. This would be
>>>>>>>>>>>> made
>>>>>>>>>>>> easier
>>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>>> JAASLoginService
>>>>>>>>>>>> into a
>>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>>> handling
>>>>>>>>>>>> there
>>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>>>> marker
>>>>>>>>>>>>> interface
>>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>>> mappings
>>>>>>>>>>>>> are
>>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>>> utility is?
>>>>>>>>>>>>
>>>>>>>>>>>> This is an embedding thing also. It's pretty unclear what
>>>>>>>>>>>> run-as is
>>>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>>>> identity for
>>>>>>>>>>>> a web service client or other remote call is supposed to work.
>>>>>>>>>>>> (If the
>>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>>> than the
>>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>>> credentials does
>>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>>> represent the
>>>>>>>>>>>> run-as role by a Subject obtained by logging into a security
>>>>>>>>>>>> realm. So,
>>>>>>>>>>>> the geronimo run-as token has this Subject in it. We might
>>>>>>>>>>>> want to
>>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't think
>>>>>>>>>>>> constraining the representation of the run-as identity is wise.
>>>>>>>>>>>>
>>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>>>> more or
>>>>>>>>>>>> less
>>>>>>>>>>>> agree on the main interfaces, at which time I plan to rewrite
>>>>>>>>>>>> them in
>>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Many thanks!
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> best regards
>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>
>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and light on
>>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi branch,
>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>>> that so far I've only just had a cursory nosey around, where
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/jetty-plus
>>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>>> modification of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to you with
>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>> informed comments. This mail is to re-assure you that your
>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>>> only
>>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>> them back into more jetty specific code. Of course if you
>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>>>> sort of
>>>>>>>>>>>>>> stuck
>>>>>>>>>>>>>> on at the end when someone realized it was incomplete, and
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>>> of CallbackHandler for two way communication between the
>>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for me to
>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>>> integration with jetty and its getting to a point where I'm
>>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for messaging
>>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> client you can add auth info to a request and validate auth
>>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>> response. On the server you can validate auth info on a
>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and transmit the
>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal for
>>>>>>>>>>>>>>>> http
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi
>>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've also tried to rework the implementation so it is more
>>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>>> integration with other app servers with their own ideas
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to verify
>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response pair on
>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle. This
>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>>> method that runs through the following structure calling
>>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the user data
>>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>>> basically that the request arrived over the right kind of
>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this are the
>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>> jetty constraint based implementation or one based on JACC.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> we can often delay authentication until a method relying on
>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory into a
>>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass various
>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will extract the
>>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided to the
>>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash, JDBC, etc
>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>>> authentication when info is actually needed. In this
>>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this includes
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>>> UserIdentity userIdentity = newUserIdentity(authResult);
>>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>> allows app servers to handle run-as roles however they
>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext, base_request,
>>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now secure
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework implementation
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>>> (rather than the bits actually needed for http which I
>>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>>> and have a nearly-untested openid implementation. This
>>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an appropriate
>>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just has the
>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>> workflow described about and delegates all actual work to
>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> authentication delegate. This makes it easy to plug in
>>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly these
>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a Principal
>>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity interface
>>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>>> separate access to the auth results (user principal) and
>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> interface. These typically delegate to implementations of
>>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy authentication if
>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated functions,
>>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>>> role handling code now in UserIdentity and the credential
>>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>>> in LoginService. Credential validation may not even be
>>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from something
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> extracts credentials from the request. Implementations are
>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>>> On the other hand the role handling is called by jetty
>>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService relate to
>>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject subject)
>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The main difference is that ServerAuthentication packages
>>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> clientSubject directly and hiding user principal and group
>>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication support
>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or.... you can
>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>>> and stuff it into an adapter, JaspiServerAuthentication.
>>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>> ServerAuthModule implementations (a ServerAuthContext is
>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which have the
>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of asking for
>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies the
>>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing response
>>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the server:
>>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller principal so
>>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user may be
>>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird to me
>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>>> to be applicable to all sorts of messaging, including ejb
>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>> normally not a secured response. Trying to evaluate auth
>>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the original
>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't see how this implementation could be significantly
>>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time now.
>>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>> I can see that is possible with constraint implementations
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>> possible with jacc is redirecting an http request to the
>>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>>> https request if a user data constraint is violated. I'm
>>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> whether this is something people want to do or usually set
>>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>> http://www.webtide.com
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>> --
>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
On Nov 23, 2008, at 10:16 AM, Jan Bartel wrote:
> Hi David,
>
> David Jencks wrote:
>>
>> On Nov 21, 2008, at 4:59 AM, Jan Bartel wrote:
>>
>>> Hi David,
>>>
>>> I've been looking at the changes to the constraint implementation to
>>> do the up-front merging.
>>>
>>> There are a couple of functional differences I noticed:
>>>
>>> 1. when there is an unrecognized data constraint, the new
>>> ConstraintSecurityHandler throws an IllegalArgumentException
>>> which is thrown out of the handler (line 250), which I think
>>> will result in a 500 response. Whereas, the jetty-6&7 code
>>> would send a 403 response.
>>
>> Well, it's an enumeration, so the only way this could happen is if
>> someone added a new value to the enumeration and recompiled. A
>> better
>> error message might be OK :-)
>
> Fair enough.
>
>>
>>>
>>>
>>> 2. if there is a forbidden constraint (ie no roles), the new code
>>> will always send back a 403, whereas the standard jetty code
>>> is lenient on forbidden constraints on form login and error
>>> pages (see lines 351 of jetty6 or 7 SecurityHandler).
>>
>> This is certainly a difference. Is it important? At the moment the
>> only ways I can think of to support this are by adding a
>> "notReallyForbidden" method to ServerAuthentication.
>
> I asked gregw about this behaviour, and the word is that the tck
> explicitly tests for this. If you have access to the tck, you
> might be able to verify that?
I haven't hooked the latest ServerAuthentication code up to geronimo
yet, but the previous version using the jaspi auth modules seemed ok
with the tck. (That version has the same lack of "notReallyForbidden"
for login/error pages) I'll double check. I thought the spec and tck
indicated that role-based constraints couldn't be applied to the login
and error pages, but said nothing about forbidden constraints.....
again I'll double check.
>
>
>
>>> Just by the by, is there a huge benefit in the UserDataConstraint
>>> being
>>> an enum rather than a class providing a primitive value that can be
>>> used in a
>>> switch statement? I'm thinking of the code at 206 in
>>> ConstraintSecurityHandler.
>>> I guess its one of those personal preference things, but I find the
>>> switch
>>> statements easier to read than the if-then-else series. But YMMV.
>>
>> I really like enums since they let the compiler limit the choices
>> -- see
>> (1) above. We could use the ordinal values in a switch
>> statement.....
>>
>> if (dataConstraint == null) return true;
>> switch (constraint.ordinal()).....
>>
>> but I think the if statements are less convoluted.
>>
>>>
>>>
>>> BTW, the code needs to be reformatted to jetty standard conventions
>>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>>> gregw will have conniptions ;)
>>
>> hmm.... I thought I'd done pretty well imitating the code style. Do
>> you
>> have some way to fix it automatically?
>
> Lemme see ... as far as the brackets go, I have an eclipse codestyle
> that I can apply to each file, but the rigorous naming of data
> members with leading _
> or __ would have to be done manually.
aha.... I can fix that, probably tomorrow. The brackets might be
tougher for me.
>
>
>
>>> I'll look at the latest updates to the authenticators and the
>>> jaspi stuff
>>> next.
>
> On the top of Monday's TODO list.
>
> BTW I think we should make your pre-processing of the constraints
> part of the
> standard jetty security handler (what you've called
> LegacyConstraintSecurityHandler).
>
> Correct me if I'm wrong, but the constraint preprocessing behaviour
> is separable
> from the jaspi authentication, so we could make that common between
> a ConstraintSecurityHandler
> that invoked non-jaspi authentication and another
> ConstraintSecurityHandler that invoked
> jaspi authentication?
The authentication (jaspi or ServerAuthentication) and authorization
(constraints or jacc or....??) are completely separable, but I would
not try to guarantee that the behavior of the legacy constraint
security handler would be unchanged if we combined the constraints up
front. If you guys are willing to risk that the legacy behavior will
change or analyze it carefully enough so you're sure it won't,
combining the constraints up front would really simplify the code. I
don't understand how the legacy code works well enough to be
comfortable claiming anything about it.
>
>
> In terms of pluggability, I think so far I'm still leaning towards a
> default of current
> jetty authentication impl, with pluggability of the jaspi impl
> (probably via plugging in a
> JaspiConstraintSecurityHandler).
not sure what you mean here.... if you don't want to use the
ServerAuthentication, RunAsToken, and UserIdentity abstractions it may
be difficult to switch back and forth. If you mean you want to use
the [Basic|Digest|Form|ClientCert]ServerAuthentication implementations
for the known auth methods rather than the jaspi modules, I
wholeheartedly agree.
>
>
> BTW, thanks for putting so much work into the security refactoring!
np!
david jencks
>
>
> Jan
>
>
>>
>> thanks!
>> david jencks
>>
>>>
>>>
>>> cheers
>>> Jan
>>>
>>> David Jencks wrote:
>>>> Hi Jan,
>>>>
>>>> I rewrote the standard auth methods as ServerAuthentication
>>>> classes on
>>>> the plane ride home. I implemented Lazy and Caching (in session
>>>> and
>>>> SSO) as wrappers. Seems to compile but I haven't tried the tck
>>>> yet.
>>>>
>>>> I'm not sure if I've put in all the necessary stuff e.g.
>>>> timeouts?? but
>>>> I think this is a lot more plausible than the pure jaspi
>>>> implementations.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>>
>>>>> Hi Jan,
>>>>>
>>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>>
>>>>> I share your concerns about efficiency of the jaspi model, which
>>>>> is
>>>>> why I tried to put another hopefully efficient layer of
>>>>> interfaces in
>>>>> between the AbstractSecurityHandler and the jaspi auth modules.
>>>>> I was
>>>>> hoping that we could simply implement the known auth methods
>>>>> (FORM,
>>>>> BASIC,...) in terms of the ServerAuthentication interface
>>>>> directly
>>>>> and retain all possible efficiencies. Not having done it yet I
>>>>> might
>>>>> have missed some important points :-)
>>>>>
>>>>> I'll think some more about your comments and get back to you.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> Having pored over the jaspi spec a few more times, and then
>>>>>> having looked more closely at the code, I'm in a position to
>>>>>> give some more detailed comments.
>>>>>>
>>>>>> Firstly, I like the cleaner distinction in functionality
>>>>>> made with the UserIdentity and LoginService as compared
>>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>>> like very much the refactoring of Abstract/
>>>>>> ConstraintSecurityHandler
>>>>>> methods.
>>>>>>
>>>>>> Here's the place where your antennae should sense a "but"
>>>>>> coming :)
>>>>>>
>>>>>> But ... I have some reservations about the efficiency of
>>>>>> the Jaspi Way. In particular, every request for which there
>>>>>> is a role restriction will result in the user being fully
>>>>>> reauthenticated. I understand that even this is an
>>>>>> optimization and departure from the jaspi spec, which
>>>>>> requires validateRequest to be called on each and every
>>>>>> request, unless you know apriori that there is an exclusion
>>>>>> constraint for the resource of the request. BTW the lazy
>>>>>> authentication when there are no role constraints is another
>>>>>> good optimization.
>>>>>>
>>>>>> As there is going to be more authenticating going on as
>>>>>> compared with the previous situation, my next reservation
>>>>>> takes on more significance, and that is the amount of
>>>>>> object creation required to satisfy the convoluted jaspi
>>>>>> callback design.
>>>>>>
>>>>>> Finally, IIUC the FormAuthenticator will call
>>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>>> In a clustered environment that would be undesirable.
>>>>>>
>>>>>> It seems to me that although we could tweak things a bit,
>>>>>> to make them more efficient, we'd be getting ever farther away
>>>>>> from the spec which does not seem to have efficiency as a
>>>>>> design goal. Do you agree, or do you have some optimizations
>>>>>> in mind?
>>>>>>
>>>>>> I'm wondering whether we could give the user the choice
>>>>>> of security implmentation, but making both jetty "default"
>>>>>> security AND jaspi security pluggable alternatives? I've
>>>>>> had a brief poke around and I don't think it would take that
>>>>>> much to achieve, but at this stage its a thought experiment
>>>>>> without code to show.
>>>>>>
>>>>>> The ideas I've been tossing around to make it pluggable are
>>>>>> to modify some of the interfaces of UserIdentity and LoginService
>>>>>> and introduce a SecurityManager class to orchestrate
>>>>>> things a little:
>>>>>>
>>>>>> UserIdentity
>>>>>> ------------
>>>>>> Principal getUserPrincipal()
>>>>>> String getAuthMethod()
>>>>>> boolean isUserInRole(String role)
>>>>>> setRunAsRole(RunAsToken)
>>>>>> setServletHandler(ServletHandler)
>>>>>>
>>>>>>
>>>>>> UserRealm (was LoginService)
>>>>>> ---------
>>>>>> UserIdentity authenticate (String user, Object credential)
>>>>>> boolean reauthenticate (UserIdentity)
>>>>>>
>>>>>>
>>>>>> SecurityManager
>>>>>> --------------
>>>>>> UserIdentity authenticate (Request, Response)
>>>>>>
>>>>>>
>>>>>> DefaultSecurityManager //implements SecurityManager
>>>>>> ----------------------
>>>>>>
>>>>>>
>>>>>> JaspiSecurityManager //implements SecurityManager
>>>>>> --------------------
>>>>>>
>>>>>>
>>>>>> AbstractSecurityHandler
>>>>>> ----------------------
>>>>>> + setSecurityManager (SecurityManager)
>>>>>>
>>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>>> is now, except for the addition of a setter and getter for a
>>>>>> SecurityManager instance, and the invocation of that manager
>>>>>> where it currently invokes
>>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>>> (around line 169).
>>>>>>
>>>>>> The DefaultSecurityManager implementation would call the
>>>>>> authenticator
>>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>>> ConstraintSecurityHandler
>>>>>> did in the pre-jaspi version.
>>>>>>
>>>>>> The JaspiSecurityManager implementation would be equivalent to
>>>>>> the
>>>>>> JaspiServerAuthentication class functionality.
>>>>>>
>>>>>> Perhaps the biggest change would be to the LoginService, which
>>>>>> I've
>>>>>> named back to UserRealm, simply because its behaviour is more
>>>>>> authentication related, rather than strictly login related. No
>>>>>> problem though
>>>>>> to keep the name LoginService if preferred. The authenticate()
>>>>>> method
>>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>>> LoginCallback
>>>>>> instance on the Subject (via the ServletCallbackHandler). I don't
>>>>>> see that as a major problem - the ServletCallbackHandler could
>>>>>> set
>>>>>> the UserIdentity object on the Subject instead. Note that in a
>>>>>> jaspi
>>>>>> implementation, I expect that reauthenticate would never be
>>>>>> called, or
>>>>>> if it was, it would call authenticate() instead.
>>>>>>
>>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>>> I think we'd need another set for the default jetty
>>>>>> implementation
>>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>>> they should be able to share a majority of code - avoiding
>>>>>> duplication
>>>>>> would be highly desirable.
>>>>>>
>>>>>> From the user's perspective, it would be simple to configure
>>>>>> jaspi:
>>>>>>
>>>>>> WebAppContext webApp = ...;
>>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>>> JaspiSecurityManager());
>>>>>>
>>>>>> I'm sure I haven't considered all aspects of pluggability. I'll
>>>>>> try
>>>>>> and get some time to turn the thoughts into code, which are a)
>>>>>> more
>>>>>> easily
>>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>>
>>>>>> cheers
>>>>>> Jan
>>>>>>
>>>>>>
>>>>>> David Jencks wrote:
>>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>>
>>>>>>> hoping to read your messages carefully before replying in the
>>>>>>> future,
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> No, I'm referring to this code:
>>>>>>>>
>>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235
>>>>>>>> and 259.
>>>>>>>>
>>>>>>>> It is doing a redirect there to get the request to come in
>>>>>>>> again on
>>>>>>>> the right connector (either the confidential or integral port
>>>>>>>> as
>>>>>>>> appropriate).
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> Jan
>>>>>>>>
>>>>>>>> David Jencks wrote:
>>>>>>>>>
>>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>>> noticed
>>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>>> checkUserDataPermissions()
>>>>>>>>>> notices the request was received on the wrong connector (ie
>>>>>>>>>> on
>>>>>>>>>> http
>>>>>>>>>> instead of
>>>>>>>>>> https) and does a redirect, the
>>>>>>>>>> AbstractSecurityHandler.handle()
>>>>>>>>>> method goes
>>>>>>>>>> ahead and subjects the request to JASPI authentication. It
>>>>>>>>>> seems
>>>>>>>>>> to me
>>>>>>>>>> that
>>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>>> altogether. It
>>>>>>>>>> will
>>>>>>>>>> be the redirected request that we're interested in processing
>>>>>>>>>> further
>>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>>
>>>>>>>>> I think you are referring to this code?
>>>>>>>>>
>>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>>> {
>>>>>>>>> if (!base_request.isHandled())
>>>>>>>>> {
>>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>>> base_request.setHandled(true);
>>>>>>>>> }
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I think there's something odd here, but IIUC something other
>>>>>>>>> than
>>>>>>>>> what
>>>>>>>>> you see.
>>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>>> request.
>>>>>>>>> I've been worrying about this because it prevents
>>>>>>>>> redirecting http
>>>>>>>>> requests to the equivalent https requests. Until recently I
>>>>>>>>> didn't
>>>>>>>>> think it was possible to do this redirect using jacc
>>>>>>>>> permissions
>>>>>>>>> but I
>>>>>>>>> think there is a solution....
>>>>>>>>>
>>>>>>>>> If the actual request is denied and is http we could create
>>>>>>>>> a new
>>>>>>>>> request with the url converted to https and
>>>>>>>>> checkUserDataPermissions on
>>>>>>>>> it.... if that check succeeds we can redirect to the more
>>>>>>>>> secure
>>>>>>>>> url.
>>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>>> authentication is
>>>>>>>>> mandatory, namely by doing a web resource permission check
>>>>>>>>> with the
>>>>>>>>> unauthenticated user.
>>>>>>>>>
>>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> Jan
>>>>>>>>>>
>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>
>>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm still snatching time to tiptoe further around the jaspi
>>>>>>>>>>>> branch.
>>>>>>>>>>>>
>>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are
>>>>>>>>>>>> quasi
>>>>>>>>>>>> analogous
>>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour
>>>>>>>>>>>> has been
>>>>>>>>>>>> refactored).
>>>>>>>>>>>> I'm wondering whether it might not be a good idea to
>>>>>>>>>>>> retain the
>>>>>>>>>>>> old
>>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>>> users/developers
>>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>>> understand the
>>>>>>>>>>> new code, I rather think it would be confusing. I'd really
>>>>>>>>>>> rather not
>>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal and
>>>>>>>>>>> depending
>>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>>> different
>>>>>>>>>>> things. The main point of introducing it was that in jetty
>>>>>>>>>>> integrations
>>>>>>>>>>> (Geronimo and from distant memory JBoss) the UserPrincipal
>>>>>>>>>>> was
>>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>>> non-principal
>>>>>>>>>>> information associated with the user's identity. I think
>>>>>>>>>>> that
>>>>>>>>>>> instead
>>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>>> whatever else the security system needs. I don't have
>>>>>>>>>>> strong
>>>>>>>>>>> objection
>>>>>>>>>>> to calling the LoginService UserRealm but I think its
>>>>>>>>>>> going to be
>>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>>
>>>>>>>>>>>> 1a. Actually thinking about this, it will probably be quite
>>>>>>>>>>>> important for
>>>>>>>>>>>> Jetty users to be able to make a smooth transition over
>>>>>>>>>>>> to a
>>>>>>>>>>>> jaspi-based
>>>>>>>>>>>> implementation. Do you think we can retain a UserRealm
>>>>>>>>>>>> and a
>>>>>>>>>>>> UserPrincipal
>>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>>> jaspi-ness
>>>>>>>>>>>> with
>>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>>> existing
>>>>>>>>>>>> apis?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer and
>>>>>>>>>>> more
>>>>>>>>>>> descriptive for embedding jetty that the old ones. I
>>>>>>>>>>> could look
>>>>>>>>>>> into
>>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>>> LoginService to
>>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In
>>>>>>>>>>> particular
>>>>>>>>>>> I'm not
>>>>>>>>>>> at all sure the non login-service methods on UserRealm could
>>>>>>>>>>> plausibly
>>>>>>>>>>> be called.
>>>>>>>>>>>
>>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a
>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>> (well,
>>>>>>>>>>>> strictly speaking its
>>>>>>>>>>>> WebAppContext
>>>>>>>>>>>> .getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>>> I couldn't see specific support for that, only getting a
>>>>>>>>>>>> list of
>>>>>>>>>>>> LoginServices from the Server instance. Should be easy
>>>>>>>>>>>> enough to
>>>>>>>>>>>> put in though?
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure how my code is different, except the
>>>>>>>>>>> LoginService is
>>>>>>>>>>> final
>>>>>>>>>>> and set in the constructor of ServletCallbackHandler, around
>>>>>>>>>>> line 1042
>>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this code
>>>>>>>>>>> much...
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of
>>>>>>>>>>>> callbacks it
>>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to
>>>>>>>>>>>> plug in
>>>>>>>>>>>> the right info, such as credentials, passwords, usernames
>>>>>>>>>>>> and
>>>>>>>>>>>> also extra request parameters from the login. I notice
>>>>>>>>>>>> you're
>>>>>>>>>>>> using
>>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>>> LoginContext.
>>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler instead?
>>>>>>>>>>>> It
>>>>>>>>>>>> supports
>>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>>> implementations
>>>>>>>>>>>> may
>>>>>>>>>>>> depend on.
>>>>>>>>>>>
>>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I think
>>>>>>>>>>> that the
>>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>>> extracting
>>>>>>>>>>> credentials from the request. In the jaspi architecture
>>>>>>>>>>> this is
>>>>>>>>>>> the
>>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>>> service. A
>>>>>>>>>>> login module that fishes directly in the request ought to be
>>>>>>>>>>> refactored
>>>>>>>>>>> into a plain login module that just validates the
>>>>>>>>>>> credentials
>>>>>>>>>>> and an
>>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>>> Despite all
>>>>>>>>>>> the weirdness in jaspi I think this is a good idea and worth
>>>>>>>>>>> enforcing.
>>>>>>>>>>>
>>>>>>>>>>> I guess someone who really really wanted to preserve their
>>>>>>>>>>> login
>>>>>>>>>>> module
>>>>>>>>>>> could write a subclass of LoginCallback that dealt with
>>>>>>>>>>> request
>>>>>>>>>>> parameters, and a JAASLoginService subclass. This would
>>>>>>>>>>> be made
>>>>>>>>>>> easier
>>>>>>>>>>> by factoring out the CallbackHandler creation in
>>>>>>>>>>> JAASLoginService
>>>>>>>>>>> into a
>>>>>>>>>>> protected method. Looks like I left out some exception
>>>>>>>>>>> handling
>>>>>>>>>>> there
>>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>>> marker
>>>>>>>>>>>> interface
>>>>>>>>>>>> as opposed to just having a String? The roles and role
>>>>>>>>>>>> mappings
>>>>>>>>>>>> are
>>>>>>>>>>>> themselves just Strings, so I was wondering what the
>>>>>>>>>>>> utility is?
>>>>>>>>>>>
>>>>>>>>>>> This is an embedding thing also. It's pretty unclear what
>>>>>>>>>>> run-as is
>>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>>> identity for
>>>>>>>>>>> a web service client or other remote call is supposed to
>>>>>>>>>>> work.
>>>>>>>>>>> (If the
>>>>>>>>>>> web service is supposed to be called as the user, rather
>>>>>>>>>>> than the
>>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>>> credentials does
>>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>>> represent the
>>>>>>>>>>> run-as role by a Subject obtained by logging into a security
>>>>>>>>>>> realm. So,
>>>>>>>>>>> the geronimo run-as token has this Subject in it. We might
>>>>>>>>>>> want to
>>>>>>>>>>> store a UserIdentity there instead..... anyway I don't think
>>>>>>>>>>> constraining the representation of the run-as identity is
>>>>>>>>>>> wise.
>>>>>>>>>>>
>>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>>> more or
>>>>>>>>>>> less
>>>>>>>>>>> agree on the main interfaces, at which time I plan to
>>>>>>>>>>> rewrite
>>>>>>>>>>> them in
>>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>>
>>>>>>>>>>> Many thanks!
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> best regards
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your
>>>>>>>>>>>>>> extraordinary
>>>>>>>>>>>>>> efforts
>>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>>> tails of
>>>>>>>>>>>>>> it c)
>>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>>
>>>>>>>>>>>>> :-D
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet
>>>>>>>>>>>>>> another
>>>>>>>>>>>>>> jcp
>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>> that is at the same time heavy on the verbiage and
>>>>>>>>>>>>>> light on
>>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi
>>>>>>>>>>>>>> branch, and I
>>>>>>>>>>>>>> admit
>>>>>>>>>>>>>> that so far I've only just had a cursory nosey around,
>>>>>>>>>>>>>> where
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>>
>>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/jetty-plus
>>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>>> modification of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll have a deeper look at the code and get back to you
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> more
>>>>>>>>>>>>>> informed comments. This mail is to re-assure you that
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>> post
>>>>>>>>>>>>>> hasn't fallen into the void and that we are looking
>>>>>>>>>>>>>> forward to
>>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>>
>>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>>> "modules"
>>>>>>>>>>>>> only
>>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>>> thinking to
>>>>>>>>>>>>> convert
>>>>>>>>>>>>> them back into more jetty specific code. Of course if you
>>>>>>>>>>>>> decide
>>>>>>>>>>>>> you
>>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jan
>>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Idiot class required by jaspi stupidity @#*($)#@&^)
>>>>>>>>>>>>>> $@#&*$@
>>>>>>>>>>>>>
>>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>>> sort of
>>>>>>>>>>>>> stuck
>>>>>>>>>>>>> on at the end when someone realized it was incomplete,
>>>>>>>>>>>>> and the
>>>>>>>>>>>>> heavy use
>>>>>>>>>>>>> of CallbackHandler for two way communication between the
>>>>>>>>>>>>> jaspi
>>>>>>>>>>>>> modules
>>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for
>>>>>>>>>>>>>>> me to
>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider
>>>>>>>>>>>>>>> Interface)
>>>>>>>>>>>>>>> integration with jetty and its getting to a point
>>>>>>>>>>>>>>> where I'm
>>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for
>>>>>>>>>>>>>>> messaging
>>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> client you can add auth info to a request and validate
>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>> info
>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>> response. On the server you can validate auth info on a
>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>>> auth info to a response. The auth code can conduct
>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>> exchanges to negotiate what info is needed and
>>>>>>>>>>>>>>> transmit the
>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal
>>>>>>>>>>>>>>> for http
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi
>>>>>>>>>>>>>>> ones.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've also tried to rework the implementation so it is
>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>>> integration with other app servers with their own
>>>>>>>>>>>>>>> ideas about
>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to
>>>>>>>>>>>>>>> verify
>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response pair
>>>>>>>>>>>>>>> on its
>>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle.
>>>>>>>>>>>>>>> This is a
>>>>>>>>>>>>>>> template
>>>>>>>>>>>>>>> method that runs through the following structure calling
>>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>>> base_response, constraintInfo). This checks the user
>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>>> basically that the request arrived over the right kind
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>> (http/https). Two obvious implementations of this are
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>> jetty constraint based implementation or one based on
>>>>>>>>>>>>>>> JACC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> we can often delay authentication until a method
>>>>>>>>>>>>>>> relying on
>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>> results
>>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole).
>>>>>>>>>>>>>>> Again
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3. packs the request, response, and authManditory into a
>>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass
>>>>>>>>>>>>>>> various
>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will extract
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>>> from the request (possibly conducing a multi-message
>>>>>>>>>>>>>>> exchange
>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>>> Validation can use a LoginService possibly provided to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash, JDBC,
>>>>>>>>>>>>>>> etc
>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>>> authentication when info is actually needed. In this
>>>>>>>>>>>>>>> case no
>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this
>>>>>>>>>>>>>>> includes the
>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>>> UserIdentity userIdentity =
>>>>>>>>>>>>>>> newUserIdentity(authResult);
>>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>> allows app servers to handle run-as roles however they
>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we
>>>>>>>>>>>>>>> know the
>>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext, base_request,
>>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now
>>>>>>>>>>>>>>> secure the
>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo,
>>>>>>>>>>>>>>> authResult);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework
>>>>>>>>>>>>>>> implementation for
>>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>>> (rather than the bits actually needed for http which I
>>>>>>>>>>>>>>> wrote
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>>> and have a nearly-untested openid implementation. This
>>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>>> lets you openid-enable your app by supplying an
>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>> login
>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just has
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>> workflow described about and delegates all actual work
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> authentication delegate. This makes it easy to plug in
>>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly
>>>>>>>>>>>>>>> these were
>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>> directly set in the request (possibly using lazy
>>>>>>>>>>>>>>> evaluation,
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> again in Request) or stuffed into a Principal
>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a
>>>>>>>>>>>>>>> Principal
>>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity
>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>>> separate access to the auth results (user principal)
>>>>>>>>>>>>>>> and role
>>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> interface. These typically delegate to
>>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy authentication
>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated
>>>>>>>>>>>>>>> functions,
>>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>>> role handling code now in UserIdentity and the
>>>>>>>>>>>>>>> credential
>>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>>> in LoginService. Credential validation may not even be
>>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from
>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> extracts credentials from the request.
>>>>>>>>>>>>>>> Implementations are
>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>>> On the other hand the role handling is called by jetty
>>>>>>>>>>>>>>> or by
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> application and the implementation is done by the app
>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How does ServerAuthentication and LoginService relate to
>>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>>> subject)
>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo,
>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo,
>>>>>>>>>>>>>>> Subject
>>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws
>>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The main difference is that ServerAuthentication
>>>>>>>>>>>>>>> packages
>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>> results into a ServerAuthResult object rather than
>>>>>>>>>>>>>>> modifying
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> clientSubject directly and hiding user principal and
>>>>>>>>>>>>>>> group
>>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication
>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As far as configuration goes. you get a
>>>>>>>>>>>>>>> ServerAuthContext by
>>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>>> whole lotta methods on some other stuff. or.... you
>>>>>>>>>>>>>>> can just
>>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>>> and stuff it into an adapter, JaspiServerAuthentication.
>>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>>> ServerAuthentication implementations rather than the
>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>> ServerAuthModule implementations (a ServerAuthContext is
>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which have
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> LoginService is a pretty straightforward way of asking
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>> validation and getting some info back. JASPI has a
>>>>>>>>>>>>>>> peculiar
>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies
>>>>>>>>>>>>>>> the auth
>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module
>>>>>>>>>>>>>>> ask for
>>>>>>>>>>>>>>> password
>>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback,
>>>>>>>>>>>>>>> SecretKeyCallback, and
>>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>>> services. AFAICT these are mostly for securing response
>>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the
>>>>>>>>>>>>>>> server:
>>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller principal
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user may be
>>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The use of callbacks here still seems rather weird to
>>>>>>>>>>>>>>> me but
>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>>> to be applicable to all sorts of messaging, including
>>>>>>>>>>>>>>> ejb
>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>>> object where they can be accessed directly (although
>>>>>>>>>>>>>>> possibly
>>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be
>>>>>>>>>>>>>>> non-lazy
>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>> normally not a secured response. Trying to evaluate
>>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>>> lazily doesn't work... you never get back to the
>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't see how this implementation could be
>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time now.
>>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>> I can see that is possible with constraint
>>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>> possible with jacc is redirecting an http request to the
>>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>>> https request if a user data constraint is violated.
>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>> whether this is something people want to do or usually
>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>
>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>> http://www.webtide.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>
>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> --
> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
Hi David,
David Jencks wrote:
>
> On Nov 21, 2008, at 4:59 AM, Jan Bartel wrote:
>
>> Hi David,
>>
>> I've been looking at the changes to the constraint implementation to
>> do the up-front merging.
>>
>> There are a couple of functional differences I noticed:
>>
>> 1. when there is an unrecognized data constraint, the new
>> ConstraintSecurityHandler throws an IllegalArgumentException
>> which is thrown out of the handler (line 250), which I think
>> will result in a 500 response. Whereas, the jetty-6&7 code
>> would send a 403 response.
>
> Well, it's an enumeration, so the only way this could happen is if
> someone added a new value to the enumeration and recompiled. A better
> error message might be OK :-)
Fair enough.
>
>>
>>
>> 2. if there is a forbidden constraint (ie no roles), the new code
>> will always send back a 403, whereas the standard jetty code
>> is lenient on forbidden constraints on form login and error
>> pages (see lines 351 of jetty6 or 7 SecurityHandler).
>
> This is certainly a difference. Is it important? At the moment the
> only ways I can think of to support this are by adding a
> "notReallyForbidden" method to ServerAuthentication.
I asked gregw about this behaviour, and the word is that the tck
explicitly tests for this. If you have access to the tck, you
might be able to verify that?
>> Just by the by, is there a huge benefit in the UserDataConstraint being
>> an enum rather than a class providing a primitive value that can be
>> used in a
>> switch statement? I'm thinking of the code at 206 in
>> ConstraintSecurityHandler.
>> I guess its one of those personal preference things, but I find the
>> switch
>> statements easier to read than the if-then-else series. But YMMV.
>
> I really like enums since they let the compiler limit the choices -- see
> (1) above. We could use the ordinal values in a switch statement.....
>
> if (dataConstraint == null) return true;
> switch (constraint.ordinal()).....
>
> but I think the if statements are less convoluted.
>
>>
>>
>> BTW, the code needs to be reformatted to jetty standard conventions
>> (http://docs.codehaus.org/display/JETTY/Jetty+Coding+Standards) or
>> gregw will have conniptions ;)
>
> hmm.... I thought I'd done pretty well imitating the code style. Do you
> have some way to fix it automatically?
Lemme see ... as far as the brackets go, I have an eclipse codestyle
that I can apply to each file, but the rigorous naming of data members with leading _
or __ would have to be done manually.
>> I'll look at the latest updates to the authenticators and the jaspi stuff
>> next.
On the top of Monday's TODO list.
BTW I think we should make your pre-processing of the constraints part of the
standard jetty security handler (what you've called LegacyConstraintSecurityHandler).
Correct me if I'm wrong, but the constraint preprocessing behaviour is separable
from the jaspi authentication, so we could make that common between a ConstraintSecurityHandler
that invoked non-jaspi authentication and another ConstraintSecurityHandler that invoked
jaspi authentication?
In terms of pluggability, I think so far I'm still leaning towards a default of current
jetty authentication impl, with pluggability of the jaspi impl (probably via plugging in a
JaspiConstraintSecurityHandler).
BTW, thanks for putting so much work into the security refactoring!
Jan
>
> thanks!
> david jencks
>
>>
>>
>> cheers
>> Jan
>>
>> David Jencks wrote:
>>> Hi Jan,
>>>
>>> I rewrote the standard auth methods as ServerAuthentication classes on
>>> the plane ride home. I implemented Lazy and Caching (in session and
>>> SSO) as wrappers. Seems to compile but I haven't tried the tck yet.
>>>
>>> I'm not sure if I've put in all the necessary stuff e.g. timeouts?? but
>>> I think this is a lot more plausible than the pure jaspi
>>> implementations.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Nov 3, 2008, at 9:13 AM, David Jencks wrote:
>>>
>>>> Hi Jan,
>>>>
>>>> I'm about to hop on a plane so will respond in more detail later.
>>>>
>>>> I share your concerns about efficiency of the jaspi model, which is
>>>> why I tried to put another hopefully efficient layer of interfaces in
>>>> between the AbstractSecurityHandler and the jaspi auth modules. I was
>>>> hoping that we could simply implement the known auth methods (FORM,
>>>> BASIC,...) in terms of the ServerAuthentication interface directly
>>>> and retain all possible efficiencies. Not having done it yet I might
>>>> have missed some important points :-)
>>>>
>>>> I'll think some more about your comments and get back to you.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Nov 3, 2008, at 1:56 AM, Jan Bartel wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> Having pored over the jaspi spec a few more times, and then
>>>>> having looked more closely at the code, I'm in a position to
>>>>> give some more detailed comments.
>>>>>
>>>>> Firstly, I like the cleaner distinction in functionality
>>>>> made with the UserIdentity and LoginService as compared
>>>>> with the previous UserPrincipal and UserRealm. I also
>>>>> like very much the refactoring of Abstract/ConstraintSecurityHandler
>>>>> methods.
>>>>>
>>>>> Here's the place where your antennae should sense a "but"
>>>>> coming :)
>>>>>
>>>>> But ... I have some reservations about the efficiency of
>>>>> the Jaspi Way. In particular, every request for which there
>>>>> is a role restriction will result in the user being fully
>>>>> reauthenticated. I understand that even this is an
>>>>> optimization and departure from the jaspi spec, which
>>>>> requires validateRequest to be called on each and every
>>>>> request, unless you know apriori that there is an exclusion
>>>>> constraint for the resource of the request. BTW the lazy
>>>>> authentication when there are no role constraints is another
>>>>> good optimization.
>>>>>
>>>>> As there is going to be more authenticating going on as
>>>>> compared with the previous situation, my next reservation
>>>>> takes on more significance, and that is the amount of
>>>>> object creation required to satisfy the convoluted jaspi
>>>>> callback design.
>>>>>
>>>>> Finally, IIUC the FormAuthenticator will call
>>>>> session.setAttribute(__J_AUTHENTICATED, form_cred) every time
>>>>> authentication is done (see line 365 of FormAuthenticator).
>>>>> In a clustered environment that would be undesirable.
>>>>>
>>>>> It seems to me that although we could tweak things a bit,
>>>>> to make them more efficient, we'd be getting ever farther away
>>>>> from the spec which does not seem to have efficiency as a
>>>>> design goal. Do you agree, or do you have some optimizations
>>>>> in mind?
>>>>>
>>>>> I'm wondering whether we could give the user the choice
>>>>> of security implmentation, but making both jetty "default"
>>>>> security AND jaspi security pluggable alternatives? I've
>>>>> had a brief poke around and I don't think it would take that
>>>>> much to achieve, but at this stage its a thought experiment
>>>>> without code to show.
>>>>>
>>>>> The ideas I've been tossing around to make it pluggable are
>>>>> to modify some of the interfaces of UserIdentity and LoginService
>>>>> and introduce a SecurityManager class to orchestrate
>>>>> things a little:
>>>>>
>>>>> UserIdentity
>>>>> ------------
>>>>> Principal getUserPrincipal()
>>>>> String getAuthMethod()
>>>>> boolean isUserInRole(String role)
>>>>> setRunAsRole(RunAsToken)
>>>>> setServletHandler(ServletHandler)
>>>>>
>>>>>
>>>>> UserRealm (was LoginService)
>>>>> ---------
>>>>> UserIdentity authenticate (String user, Object credential)
>>>>> boolean reauthenticate (UserIdentity)
>>>>>
>>>>>
>>>>> SecurityManager
>>>>> --------------
>>>>> UserIdentity authenticate (Request, Response)
>>>>>
>>>>>
>>>>> DefaultSecurityManager //implements SecurityManager
>>>>> ----------------------
>>>>>
>>>>>
>>>>> JaspiSecurityManager //implements SecurityManager
>>>>> --------------------
>>>>>
>>>>>
>>>>> AbstractSecurityHandler
>>>>> ----------------------
>>>>> + setSecurityManager (SecurityManager)
>>>>>
>>>>> The AbstractSecurityHandler would be pretty much unchanged as it
>>>>> is now, except for the addition of a setter and getter for a
>>>>> SecurityManager instance, and the invocation of that manager
>>>>> where it currently invokes
>>>>> JaspiServerAuthentication.validateRequest(...)
>>>>> (around line 169).
>>>>>
>>>>> The DefaultSecurityManager implementation would call the authenticator
>>>>> (Basic, Form, Credential etc) directly, much as the
>>>>> ConstraintSecurityHandler
>>>>> did in the pre-jaspi version.
>>>>>
>>>>> The JaspiSecurityManager implementation would be equivalent to the
>>>>> JaspiServerAuthentication class functionality.
>>>>>
>>>>> Perhaps the biggest change would be to the LoginService, which I've
>>>>> named back to UserRealm, simply because its behaviour is more
>>>>> authentication related, rather than strictly login related. No
>>>>> problem though
>>>>> to keep the name LoginService if preferred. The authenticate() method
>>>>> returns a UserIdentity object, instead of ultimately setting a
>>>>> LoginCallback
>>>>> instance on the Subject (via the ServletCallbackHandler). I don't
>>>>> see that as a major problem - the ServletCallbackHandler could set
>>>>> the UserIdentity object on the Subject instead. Note that in a jaspi
>>>>> implementation, I expect that reauthenticate would never be called, or
>>>>> if it was, it would call authenticate() instead.
>>>>>
>>>>> The other issue is the Form, Basic, Digest etc AuthModules.
>>>>> I think we'd need another set for the default jetty implementation
>>>>> that had no jaspi-style interfaces in it. I think though that
>>>>> they should be able to share a majority of code - avoiding duplication
>>>>> would be highly desirable.
>>>>>
>>>>> From the user's perspective, it would be simple to configure jaspi:
>>>>>
>>>>> WebAppContext webApp = ...;
>>>>> webApp.getSecurityHandler().setSecurityManager(new
>>>>> JaspiSecurityManager());
>>>>>
>>>>> I'm sure I haven't considered all aspects of pluggability. I'll try
>>>>> and get some time to turn the thoughts into code, which are a) more
>>>>> easily
>>>>> comprehended and b) will show up any areas I've neglected.
>>>>>
>>>>> cheers
>>>>> Jan
>>>>>
>>>>>
>>>>> David Jencks wrote:
>>>>>> Yup, that's wrong.... should be fixed now
>>>>>>
>>>>>> hoping to read your messages carefully before replying in the future,
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Oct 31, 2008, at 12:42 AM, Jan Bartel wrote:
>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> No, I'm referring to this code:
>>>>>>>
>>>>>>> ConstraintSecurityHandler.checkUserDataPermissions line 235 and 259.
>>>>>>>
>>>>>>> It is doing a redirect there to get the request to come in again on
>>>>>>> the right connector (either the confidential or integral port as
>>>>>>> appropriate).
>>>>>>>
>>>>>>> cheers
>>>>>>> Jan
>>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>>
>>>>>>>> On Oct 30, 2008, at 10:54 PM, Jan Bartel wrote:
>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> I'll reply to your reply in a later posting. For now, I just
>>>>>>>>> noticed
>>>>>>>>> something odd in the ConstraintSecurityHandler. If
>>>>>>>>> checkUserDataPermissions()
>>>>>>>>> notices the request was received on the wrong connector (ie on
>>>>>>>>> http
>>>>>>>>> instead of
>>>>>>>>> https) and does a redirect, the AbstractSecurityHandler.handle()
>>>>>>>>> method goes
>>>>>>>>> ahead and subjects the request to JASPI authentication. It seems
>>>>>>>>> to me
>>>>>>>>> that
>>>>>>>>> at that point we want to stop processing the request
>>>>>>>>> altogether. It
>>>>>>>>> will
>>>>>>>>> be the redirected request that we're interested in processing
>>>>>>>>> further
>>>>>>>>> (either doing the auth or doing a redirect to a login form).
>>>>>>>>
>>>>>>>> I think you are referring to this code?
>>>>>>>>
>>>>>>>> if (!checkUserDataPermissions(pathInContext,
>>>>>>>> base_request, base_response, constraintInfo))
>>>>>>>> {
>>>>>>>> if (!base_request.isHandled())
>>>>>>>> {
>>>>>>>> response.sendError(Response.SC_FORBIDDEN);
>>>>>>>> base_request.setHandled(true);
>>>>>>>> }
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> I think there's something odd here, but IIUC something other than
>>>>>>>> what
>>>>>>>> you see.
>>>>>>>> This is not proposing a redirect, it is plainly denying the
>>>>>>>> request.
>>>>>>>> I've been worrying about this because it prevents redirecting http
>>>>>>>> requests to the equivalent https requests. Until recently I didn't
>>>>>>>> think it was possible to do this redirect using jacc permissions
>>>>>>>> but I
>>>>>>>> think there is a solution....
>>>>>>>>
>>>>>>>> If the actual request is denied and is http we could create a new
>>>>>>>> request with the url converted to https and
>>>>>>>> checkUserDataPermissions on
>>>>>>>> it.... if that check succeeds we can redirect to the more secure
>>>>>>>> url.
>>>>>>>> This is somewhat analogous to the way we determine if
>>>>>>>> authentication is
>>>>>>>> mandatory, namely by doing a web resource permission check with the
>>>>>>>> unauthenticated user.
>>>>>>>>
>>>>>>>> I might also have missed what you are looking at...
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>>> David Jencks wrote:
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> On Oct 29, 2008, at 7:37 PM, Jan Bartel wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> I'm still snatching time to tiptoe further around the jaspi
>>>>>>>>>>> branch.
>>>>>>>>>>>
>>>>>>>>>>> A couple of thoughts to run by you:
>>>>>>>>>>>
>>>>>>>>>>> 1. UserIdentity and LoginService classnames. These are quasi
>>>>>>>>>>> analogous
>>>>>>>>>>> to UserPrincipal and UserRealm (although the behaviour has been
>>>>>>>>>>> refactored).
>>>>>>>>>>> I'm wondering whether it might not be a good idea to retain the
>>>>>>>>>>> old
>>>>>>>>>>> classnames, just so it might be easier for jetty
>>>>>>>>>>> users/developers
>>>>>>>>>>> to ease into understanding the new security structures?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm not sure that keeping the old names would help anyone
>>>>>>>>>> understand the
>>>>>>>>>> new code, I rather think it would be confusing. I'd really
>>>>>>>>>> rather not
>>>>>>>>>> call UserIdentity a Principal since it isn't a Principal and
>>>>>>>>>> depending
>>>>>>>>>> on the security handler implementation can contain rather
>>>>>>>>>> different
>>>>>>>>>> things. The main point of introducing it was that in jetty
>>>>>>>>>> integrations
>>>>>>>>>> (Geronimo and from distant memory JBoss) the UserPrincipal was
>>>>>>>>>> ridiculously overloaded to contain incredible amounts of
>>>>>>>>>> non-principal
>>>>>>>>>> information associated with the user's identity. I think that
>>>>>>>>>> instead
>>>>>>>>>> it makes sense to have an object that supplies the
>>>>>>>>>> UserPrincipal, plus
>>>>>>>>>> whatever else the security system needs. I don't have strong
>>>>>>>>>> objection
>>>>>>>>>> to calling the LoginService UserRealm but I think its going to be
>>>>>>>>>> confusing and less informative since it doesn't have the
>>>>>>>>>> non-login-service methods any more.
>>>>>>>>>>
>>>>>>>>>>> 1a. Actually thinking about this, it will probably be quite
>>>>>>>>>>> important for
>>>>>>>>>>> Jetty users to be able to make a smooth transition over to a
>>>>>>>>>>> jaspi-based
>>>>>>>>>>> implementation. Do you think we can retain a UserRealm and a
>>>>>>>>>>> UserPrincipal
>>>>>>>>>>> with all their methods intact, but just "blend in" the
>>>>>>>>>>> jaspi-ness
>>>>>>>>>>> with
>>>>>>>>>>> some extra methods and some changed implementations of the
>>>>>>>>>>> existing
>>>>>>>>>>> apis?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maybe. I think the new interfaces are a lot clearer and more
>>>>>>>>>> descriptive for embedding jetty that the old ones. I could look
>>>>>>>>>> into
>>>>>>>>>> writing adapters from UserIdentity to UserPrincipal and
>>>>>>>>>> LoginService to
>>>>>>>>>> UserRealm but I'm not entirely sure it will work. In particular
>>>>>>>>>> I'm not
>>>>>>>>>> at all sure the non login-service methods on UserRealm could
>>>>>>>>>> plausibly
>>>>>>>>>> be called.
>>>>>>>>>>
>>>>>>>>>>> 2. We allow a UserRealm to be explicitly set on a WebAppContext
>>>>>>>>>>> (well,
>>>>>>>>>>> strictly speaking its
>>>>>>>>>>> WebAppContext.getSecurityHandler().setUserRealm(UserRealm)).
>>>>>>>>>>> I couldn't see specific support for that, only getting a list of
>>>>>>>>>>> LoginServices from the Server instance. Should be easy enough to
>>>>>>>>>>> put in though?
>>>>>>>>>>
>>>>>>>>>> I'm not sure how my code is different, except the LoginService is
>>>>>>>>>> final
>>>>>>>>>> and set in the constructor of ServletCallbackHandler, around
>>>>>>>>>> line 1042
>>>>>>>>>> of WebXmlConfiguration. I don't recall changing this code
>>>>>>>>>> much...
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 3. With the JAAS stuff, which has its own set of callbacks it
>>>>>>>>>>> uses to obtain info, we used a DefaultCallbackHandler to plug in
>>>>>>>>>>> the right info, such as credentials, passwords, usernames and
>>>>>>>>>>> also extra request parameters from the login. I notice you're
>>>>>>>>>>> using
>>>>>>>>>>> an anonymous CallbackHandler instead to pass into the JAAS
>>>>>>>>>>> LoginContext.
>>>>>>>>>>> Is it possible to use the DefaultCallbackHandler instead? It
>>>>>>>>>>> supports
>>>>>>>>>>> a couple more callback types that some LoginModule
>>>>>>>>>>> implementations
>>>>>>>>>>> may
>>>>>>>>>>> depend on.
>>>>>>>>>>
>>>>>>>>>> I could misunderstand the DefaultCallbackHandler but I think
>>>>>>>>>> that the
>>>>>>>>>> extensions to a user-password callback handler all involve
>>>>>>>>>> extracting
>>>>>>>>>> credentials from the request. In the jaspi architecture this is
>>>>>>>>>> the
>>>>>>>>>> function of the auth module, not the password validation
>>>>>>>>>> service. A
>>>>>>>>>> login module that fishes directly in the request ought to be
>>>>>>>>>> refactored
>>>>>>>>>> into a plain login module that just validates the credentials
>>>>>>>>>> and an
>>>>>>>>>> auth module that extracts the credentials from the message.
>>>>>>>>>> Despite all
>>>>>>>>>> the weirdness in jaspi I think this is a good idea and worth
>>>>>>>>>> enforcing.
>>>>>>>>>>
>>>>>>>>>> I guess someone who really really wanted to preserve their login
>>>>>>>>>> module
>>>>>>>>>> could write a subclass of LoginCallback that dealt with request
>>>>>>>>>> parameters, and a JAASLoginService subclass. This would be made
>>>>>>>>>> easier
>>>>>>>>>> by factoring out the CallbackHandler creation in JAASLoginService
>>>>>>>>>> into a
>>>>>>>>>> protected method. Looks like I left out some exception handling
>>>>>>>>>> there
>>>>>>>>>> too :-( I'd rather not encourage this however.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 4. Minor thing - is there a lot of value in the RunAsToken
>>>>>>>>>>> marker
>>>>>>>>>>> interface
>>>>>>>>>>> as opposed to just having a String? The roles and role mappings
>>>>>>>>>>> are
>>>>>>>>>>> themselves just Strings, so I was wondering what the utility is?
>>>>>>>>>>
>>>>>>>>>> This is an embedding thing also. It's pretty unclear what
>>>>>>>>>> run-as is
>>>>>>>>>> actually supposed to mean and how things like supplying the
>>>>>>>>>> identity for
>>>>>>>>>> a web service client or other remote call is supposed to work.
>>>>>>>>>> (If the
>>>>>>>>>> web service is supposed to be called as the user, rather than the
>>>>>>>>>> server's identity, and you are in a run-as role, what
>>>>>>>>>> credentials does
>>>>>>>>>> this run-as-role identity supply????) In Geronimo we
>>>>>>>>>> represent the
>>>>>>>>>> run-as role by a Subject obtained by logging into a security
>>>>>>>>>> realm. So,
>>>>>>>>>> the geronimo run-as token has this Subject in it. We might
>>>>>>>>>> want to
>>>>>>>>>> store a UserIdentity there instead..... anyway I don't think
>>>>>>>>>> constraining the representation of the run-as identity is wise.
>>>>>>>>>>
>>>>>>>>>> BTW remember that the current auth modules implementing
>>>>>>>>>> BASIC/DIGEST/FORM auth are more or less temporary until we
>>>>>>>>>> more or
>>>>>>>>>> less
>>>>>>>>>> agree on the main interfaces, at which time I plan to rewrite
>>>>>>>>>> them in
>>>>>>>>>> more jetty-friendly form (also after apachecon :-)
>>>>>>>>>>
>>>>>>>>>> Many thanks!
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> best regards
>>>>>>>>>>> Jan
>>>>>>>>>>>
>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Firstly, let me genuflect in recognition of your extraordinary
>>>>>>>>>>>>> efforts
>>>>>>>>>>>>> for a) reading the spec b) being able to make heads or
>>>>>>>>>>>>> tails of
>>>>>>>>>>>>> it c)
>>>>>>>>>>>>> coming up with an implementation based on it!
>>>>>>>>>>>>
>>>>>>>>>>>> :-D
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm surpressing the urge to have a bit of rant at yet another
>>>>>>>>>>>>> jcp
>>>>>>>>>>>>> spec
>>>>>>>>>>>>> that is at the same time heavy on the verbiage and light on
>>>>>>>>>>>>> comprehensibility. Your email was way more informative
>>>>>>>>>>>>> than what 29 people managed to produce in the spec.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyway, looking at the code in the jetty-7-jaspi branch, and I
>>>>>>>>>>>>> admit
>>>>>>>>>>>>> that so far I've only just had a cursory nosey around, where
>>>>>>>>>>>>> would
>>>>>>>>>>>>> we integrate the JAAS side of things? Implement a
>>>>>>>>>>>>> JAASLoginService?
>>>>>>>>>>>>
>>>>>>>>>>>> see org.mortbay.jetty.plus.jaas in modules/plus/jetty-plus
>>>>>>>>>>>> Not sure if it is ideal, it's pretty much a simple
>>>>>>>>>>>> modification of
>>>>>>>>>>>> the
>>>>>>>>>>>> former JAASUserRealm
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll have a deeper look at the code and get back to you with
>>>>>>>>>>>>> more
>>>>>>>>>>>>> informed comments. This mail is to re-assure you that your
>>>>>>>>>>>>> post
>>>>>>>>>>>>> hasn't fallen into the void and that we are looking forward to
>>>>>>>>>>>>> integrating this into jetty-7 trunk!
>>>>>>>>>>>>
>>>>>>>>>>>> The main thing to remember might be that the current
>>>>>>>>>>>> implementations of
>>>>>>>>>>>> built-in security (FORM, BASIC, DIGEST etc) are in jaspi
>>>>>>>>>>>> "modules"
>>>>>>>>>>>> only
>>>>>>>>>>>> until we agree on the jetty api at which point I was
>>>>>>>>>>>> thinking to
>>>>>>>>>>>> convert
>>>>>>>>>>>> them back into more jetty specific code. Of course if you
>>>>>>>>>>>> decide
>>>>>>>>>>>> you
>>>>>>>>>>>> really like jaspi.... :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jan
>>>>>>>>>>>>> PS I love this code-comment in ServletCallbackHandler:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Idiot class required by jaspi stupidity @#*($)#@&^)$@#&*$@
>>>>>>>>>>>>
>>>>>>>>>>>> Several parts of the jaspi spec look to me as if they are
>>>>>>>>>>>> sort of
>>>>>>>>>>>> stuck
>>>>>>>>>>>> on at the end when someone realized it was incomplete, and the
>>>>>>>>>>>> heavy use
>>>>>>>>>>>> of CallbackHandler for two way communication between the jaspi
>>>>>>>>>>>> modules
>>>>>>>>>>>> and the container strikes me as one such point.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>>> Greg and Jan were kind enough to create a branch for me to
>>>>>>>>>>>>>> play
>>>>>>>>>>>>>> around
>>>>>>>>>>>>>> with a JASPI (Java Authentication Service Provider Interface)
>>>>>>>>>>>>>> integration with jetty and its getting to a point where I'm
>>>>>>>>>>>>>> willing to
>>>>>>>>>>>>>> talk about it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Code is at
>>>>>>>>>>>>>> https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JASPI attempts to provide a uniform framework for messaging
>>>>>>>>>>>>>> systems,
>>>>>>>>>>>>>> both client and server side, to plug in message
>>>>>>>>>>>>>> authentication. On
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> client you can add auth info to a request and validate auth
>>>>>>>>>>>>>> info
>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>> response. On the server you can validate auth info on a
>>>>>>>>>>>>>> request
>>>>>>>>>>>>>> and add
>>>>>>>>>>>>>> auth info to a response. The auth code can conduct arbitrary
>>>>>>>>>>>>>> message
>>>>>>>>>>>>>> exchanges to negotiate what info is needed and transmit the
>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>> been working on the server side auth for jetty.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The actual spec jaspi interfaces are not 100% ideal for http
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>> allow stuff like lazy authentication for unsecured
>>>>>>>>>>>>>> resources so
>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>> come up with interfaces similar in spirit to the jaspi ones.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've also tried to rework the implementation so it is more
>>>>>>>>>>>>>> friendly to
>>>>>>>>>>>>>> integration with other app servers with their own ideas about
>>>>>>>>>>>>>> security
>>>>>>>>>>>>>> frameworks such as geronimo and in particular make jacc
>>>>>>>>>>>>>> implementations
>>>>>>>>>>>>>> easier. I expect these changes will also simplify
>>>>>>>>>>>>>> integration with
>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>> jboss and glassfish but I haven't seriously tried to verify
>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Currently all the authentication code (replacing the
>>>>>>>>>>>>>> *Authenticator
>>>>>>>>>>>>>> classes) is implemented in terms of jaspi but I plan to
>>>>>>>>>>>>>> change
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>> to use the jetty specific interfaces directly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So.... lets follow a HttpServletRequest/Response pair on its
>>>>>>>>>>>>>> voyage
>>>>>>>>>>>>>> through the security system...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ... it arrives at AbstractSecurityHandler.handle. This is a
>>>>>>>>>>>>>> template
>>>>>>>>>>>>>> method that runs through the following structure calling
>>>>>>>>>>>>>> out to
>>>>>>>>>>>>>> subclasses and the authentication system:
>>>>>>>>>>>>>> 1. calls checkUserDataPermissions(pathInContext,
>>>>>>>>>>>>>> base_request,
>>>>>>>>>>>>>> base_response, constraintInfo). This checks the user data
>>>>>>>>>>>>>> constraints,
>>>>>>>>>>>>>> basically that the request arrived over the right kind of
>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>> (http/https). Two obvious implementations of this are the
>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>> jetty constraint based implementation or one based on JACC.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. calls isAuthMandatory(base_request, base_response,
>>>>>>>>>>>>>> constraintInfo) to
>>>>>>>>>>>>>> determine if the request actually needs authentication.
>>>>>>>>>>>>>> If it
>>>>>>>>>>>>>> does
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> we can often delay authentication until a method relying on
>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>> results
>>>>>>>>>>>>>> is called (such as getUserPrincipal or isUserInRole). Again
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>> implemented using constraints or JACC.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. packs the request, response, and authManditory into a
>>>>>>>>>>>>>> JettyMessageInfo holder object which can also pass various
>>>>>>>>>>>>>> auth
>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>> a map.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4. delegates the authentication to the jaspi-like
>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>> authResult =
>>>>>>>>>>>>>> serverAuthentication.validateRequest(messageInfo);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> assuming we are not doing lazy auth, this will extract the
>>>>>>>>>>>>>> credentials
>>>>>>>>>>>>>> from the request (possibly conducing a multi-message exchange
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> client to request the credentials) and validate them.
>>>>>>>>>>>>>> Validation can use a LoginService possibly provided to the
>>>>>>>>>>>>>> ServerAuthentication which could be JAAS, Hash, JDBC, etc
>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>> Lazy auth results in returning a lazy result that only
>>>>>>>>>>>>>> attempts
>>>>>>>>>>>>>> authentication when info is actually needed. In this case no
>>>>>>>>>>>>>> message
>>>>>>>>>>>>>> exchange with the client is possible.
>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>> 5. Assuming that authentication succeeded (this includes the
>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>> case
>>>>>>>>>>>>>> where the request would be allowed even without
>>>>>>>>>>>>>> authentication), we
>>>>>>>>>>>>>> wrap
>>>>>>>>>>>>>> up the result in an identity delegate:
>>>>>>>>>>>>>> UserIdentity userIdentity = newUserIdentity(authResult);
>>>>>>>>>>>>>> base_request.setUserIdentity(userIdentity);
>>>>>>>>>>>>>> The UserIdentity is the delegate for run-as role
>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> actually answering auth questions from the application
>>>>>>>>>>>>>> program.
>>>>>>>>>>>>>> This
>>>>>>>>>>>>>> allows app servers to handle run-as roles however they want.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 6. Assuming authentication is mandatory, now that we know the
>>>>>>>>>>>>>> user, we
>>>>>>>>>>>>>> can find out if they are in the appropriate roles:
>>>>>>>>>>>>>> checkWebResourcePermissions(pathInContext, base_request,
>>>>>>>>>>>>>> base_response,
>>>>>>>>>>>>>> constraintInfo, userIdentity)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 7. On success, we can actually handle the request:
>>>>>>>>>>>>>> getHandler().handle(pathInContext,
>>>>>>>>>>>>>> messageInfo.getRequestMessage(),
>>>>>>>>>>>>>> messageInfo.getResponseMessage(), dispatch);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 8. Assuming no exceptions were thrown, we can now secure the
>>>>>>>>>>>>>> response
>>>>>>>>>>>>>> (normally a no-op for http):
>>>>>>>>>>>>>> serverAuthentication.secureResponse(messageInfo, authResult);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JASPI implementations
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wrote a fairly complete jaspi framework implementation for
>>>>>>>>>>>>>> geronimo
>>>>>>>>>>>>>> (rather than the bits actually needed for http which I wrote
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> jetty)
>>>>>>>>>>>>>> and have a nearly-untested openid implementation. This
>>>>>>>>>>>>>> (theoretically)
>>>>>>>>>>>>>> lets you openid-enable your app by supplying an appropriate
>>>>>>>>>>>>>> login
>>>>>>>>>>>>>> page
>>>>>>>>>>>>>> and useing the openid auth module.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Theres also a glassfish implementation that I haven't
>>>>>>>>>>>>>> looked at
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> someone wrote a SPNEGO auth module that works with it.
>>>>>>>>>>>>>> http://spnego.ocean.net.au/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How does this differ from what's there now?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SecurityHandler: AbstractSecurityHandler now just has the
>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>> workflow described about and delegates all actual work to
>>>>>>>>>>>>>> either
>>>>>>>>>>>>>> subclasses (for authorization decisions and object
>>>>>>>>>>>>>> creation) or
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> authentication delegate. This makes it easy to plug in
>>>>>>>>>>>>>> alternate
>>>>>>>>>>>>>> implementations such as a JACC implementation for an EE
>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Authentication results and run-as roles: Formerly these were
>>>>>>>>>>>>>> either
>>>>>>>>>>>>>> directly set in the request (possibly using lazy evaluation,
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> again in Request) or stuffed into a Principal implementation
>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>> UserRealm. This really overloaded the idea of a Principal
>>>>>>>>>>>>>> for no
>>>>>>>>>>>>>> apparent reason and made integration into app servers
>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>> convoluted. This is replaced with a UserIdentity interface
>>>>>>>>>>>>>> providing
>>>>>>>>>>>>>> separate access to the auth results (user principal) and role
>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>> (isUserInRole, and run-as handling). Subclasses of
>>>>>>>>>>>>>> AbstractSecurityHandler can provide their own
>>>>>>>>>>>>>> implementations of
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> interface. These typically delegate to implementations of
>>>>>>>>>>>>>> ServerAuthResult, which can handle lazy authentication if
>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> UserRealm IMO glues together a lot of unrelated functions,
>>>>>>>>>>>>>> primarily the
>>>>>>>>>>>>>> role handling code now in UserIdentity and the credential
>>>>>>>>>>>>>> validation now
>>>>>>>>>>>>>> in LoginService. Credential validation may not even be
>>>>>>>>>>>>>> needed by
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> server (e.g. openid). If needed it's called from something
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> extracts credentials from the request. Implementations are
>>>>>>>>>>>>>> going
>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>> something like look up the user in a file or table or
>>>>>>>>>>>>>> delegate to
>>>>>>>>>>>>>> JAAS.
>>>>>>>>>>>>>> On the other hand the role handling is called by jetty or by
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> application and the implementation is done by the app server
>>>>>>>>>>>>>> (jetty or
>>>>>>>>>>>>>> e.g. geronimo). Aside from being related somehow to
>>>>>>>>>>>>>> security,
>>>>>>>>>>>>>> these are
>>>>>>>>>>>>>> totally unrelated concerns.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How does ServerAuthentication and LoginService relate to
>>>>>>>>>>>>>> JASPI?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The JASPI interface similar to ServerAuthentication is
>>>>>>>>>>>>>> ServerAuthContext:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void cleanSubject(MessageInfo messageInfo, Subject subject)
>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>> AuthException;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AuthStatus secureResponse(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>> serviceSubject) throws AuthException;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AuthStatus validateRequest(MessageInfo messageInfo, Subject
>>>>>>>>>>>>>> clientSubject, Subject serviceSubject) throws AuthException;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The main difference is that ServerAuthentication packages
>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>> results into a ServerAuthResult object rather than modifying
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> clientSubject directly and hiding user principal and group
>>>>>>>>>>>>>> info in
>>>>>>>>>>>>>> some
>>>>>>>>>>>>>> callback handers. This lets ServerAuthentication support
>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>> auth.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As far as configuration goes. you get a ServerAuthContext by
>>>>>>>>>>>>>> calling a
>>>>>>>>>>>>>> whole lotta methods on some other stuff. or.... you can just
>>>>>>>>>>>>>> create one
>>>>>>>>>>>>>> and stuff it into an adapter, JaspiServerAuthentication.
>>>>>>>>>>>>>> Probably we
>>>>>>>>>>>>>> want to implement the built in auth methods as direct
>>>>>>>>>>>>>> ServerAuthentication implementations rather than the current
>>>>>>>>>>>>>> ServerAuthModule implementations (a ServerAuthContext is
>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>> delegate to one or more ServerAuthModules, which have the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> interface).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LoginService is a pretty straightforward way of asking for
>>>>>>>>>>>>>> password
>>>>>>>>>>>>>> validation and getting some info back. JASPI has a peculiar
>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>> system
>>>>>>>>>>>>>> based on Callbacks. The container (jetty) supplies the auth
>>>>>>>>>>>>>> context
>>>>>>>>>>>>>> with a CallbackHandler that enables bi-directional
>>>>>>>>>>>>>> communication.
>>>>>>>>>>>>>> Callbacks providing services to the auth module:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PasswordValidationCallback: this lets the auth module ask for
>>>>>>>>>>>>>> password
>>>>>>>>>>>>>> validation: this is the closest to LoginService.
>>>>>>>>>>>>>> CertStoreCallback, PrivateKeyCallback, SecretKeyCallback, and
>>>>>>>>>>>>>> TrustStoreCallback all let the auth module ask for
>>>>>>>>>>>>>> certificate
>>>>>>>>>>>>>> services. AFAICT these are mostly for securing response
>>>>>>>>>>>>>> messages,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> is typically not done for http.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Callbacks letting the auth module pass info to the server:
>>>>>>>>>>>>>> CallerPrincipalCallback: supplies the caller principal so
>>>>>>>>>>>>>> getCallerPrincipal can return something.
>>>>>>>>>>>>>> GroupPrincipalCallback supplies "groups" the user may be
>>>>>>>>>>>>>> in. The
>>>>>>>>>>>>>> meaning here is rather undefined but can be mapped to
>>>>>>>>>>>>>> roles in
>>>>>>>>>>>>>> some
>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>> such as by assuming the groups and roles are the same.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The use of callbacks here still seems rather weird to me but
>>>>>>>>>>>>>> may
>>>>>>>>>>>>>> make
>>>>>>>>>>>>>> more sense in the context of other messaging systems:
>>>>>>>>>>>>>> jaspi is
>>>>>>>>>>>>>> supposed
>>>>>>>>>>>>>> to be applicable to all sorts of messaging, including ejb
>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>> jms,
>>>>>>>>>>>>>> web services, etc etc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've put the caller principal and groups into the
>>>>>>>>>>>>>> ServerAuthResult
>>>>>>>>>>>>>> object where they can be accessed directly (although possibly
>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>> lazily).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Comments...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right now it looks to me as if form auth needs to be non-lazy
>>>>>>>>>>>>>> since
>>>>>>>>>>>>>> part
>>>>>>>>>>>>>> of the message exchange involves a request to
>>>>>>>>>>>>>> j_security_check
>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>> normally not a secured response. Trying to evaluate auth
>>>>>>>>>>>>>> for this
>>>>>>>>>>>>>> lazily doesn't work... you never get back to the original
>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't see how this implementation could be significantly
>>>>>>>>>>>>>> simplified or
>>>>>>>>>>>>>> sped up.... I'm certainly willing to look at problems.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've been discussing JACC with Greg for a long time now.
>>>>>>>>>>>>>> The only
>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>> I can see that is possible with constraint implementations
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>> possible with jacc is redirecting an http request to the
>>>>>>>>>>>>>> "equivalent"
>>>>>>>>>>>>>> https request if a user data constraint is violated. I'm
>>>>>>>>>>>>>> curious
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>> whether this is something people want to do or usually set
>>>>>>>>>>>>>> up.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>>>
>>>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>>>> http://www.webtide.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>>>
>>>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com |
>>>>>>>>> http://www.webtide.com
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>> --
>> Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Jan Bartel, Webtide LLC | janb@webtide.com | http://www.webtide.com
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
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
>
>
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
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
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
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
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
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).
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
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
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
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by Jan Bartel <ja...@webtide.com>.
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?
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?
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?
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.
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?
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
Re: [jetty-dev] Jetty Security refactoring for JASPI
Posted by David Jencks <da...@yahoo.com>.
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
>
>