[jetty-dev] Authentication changes.

[Greg Wilkins <gregw@xxxxxxxxxxx>]

David (and others),

I've had to put some changes into the authentication stuff
again (and more are coming).

Jan has been porting our JBoss stuff over and noticed a few
missing bits:

When associating a runAs role, jboss needs information
about the user. So I'm now passing in the UserIdentity with
the associate(UserIdentity,RunAsToken)


We need an logout method on the LoginService.  This is so
that any LoginService that does cache user credentials
knows when it should flush them and get them again (eg
the logout and login again scenario to get new roles
and/or password).     Now some LoginServices will not
cache, but many will.

So I've added logout() to LoginService.  But to make it
easy to "navigate" back to the LoginService (if there is
one), I've also added logout() to the Authentication
interface and we now have the hierarchy:

 FormAuthentication
     |
     V
 DefaultAuthentication
     |
     V
 Authentication

and FormAuthentication is a HttpSessionAttributeListener,
so it can detect session invalidation etc.


I also ended up removing the templating of the IdentityService
as I couldn't see what it was doing for us other than to
create warnings where ever it was used...  I also was having
trouble explaining it etc.  So it's gone now.  If this causes
trouble for you (other than a few casts) then I can put
it back.

So I'm just checking these into jetty-7 now and will update
the jetty-8 branch with them later.


But there needs to be more changes, because there is some
more servlet-3.0 stuff on the way:

+ A logout() method which will need to be wired to the logout
  that I just provided.

+ A login(username,password) method that will result in a
  a authType of "LOGIN" and will need to be wired to the
  LoginService if there is one via a new Authenticator type.

+ A login() method (that I think should be called authenticate)
  that will trigger the container authentication mechanism (eg
  sending a challenge or a redirect or checking cookies).  This
  will need to be wired to the authenticator.   This is kind of
  like lazy authentication (but with the ability to send challenges)
  and we have to think if they should both use the same mechanism or not.

these methods are on the request - so the problem for jetty
is how to handle them at the jetty-server layer that knows
nothing of jetty-security.

So having just removed an abstract security interface and having
everything done via UserIdentity, it looks like we may need to put
one back again.

Or the other option is to add abstract login/logout/authenticate
methods to the ContextHandler.Context which will be null normally
but implemented by ServletContextHandler.Context, which does
know about jetty-security.  But this is complicated by cross
context dispatch and how login() should behave then.

So I might just bash something in as a straw-man and then we
can pick at it.   I'll put the core of it in jetty-7, but only
expose the API in jetty-8.


cheers