Re: [jetty-dev] Jetty Security refactoring for JASPI

[David Jencks]

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 @#*($)#@&^) 
[EMAIL PROTECTED]&*$@

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 | [EMAIL PROTECTED] |
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 | [EMAIL PROTECTED] |
http://www.webtide.com


---------------------------------------------------------------------


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email





--
Jan Bartel, Webtide LLC | [EMAIL PROTECTED] |
http://www.webtide.com


---------------------------------------------------------------------

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email





--
Jan Bartel, Webtide LLC | [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | http://www.webtide.com