>
> Yes I read it, but what I don't like about that solution is that one
> has to reconfigure Tomcat. Now I have the application almost in the
> stage where you can just throw an EAR into the deploy directory and
> it's done. I'd like to keep this. But there are only two servlets
> which handle all the incoming requests, so I can easily do the same
> without a RequestInterceptor. The other (and more important) point is
> that the application doesn't use any JBoss classes up to now, so it
> should be possible to run it on any EJB server with JAAS security by
> only rewriting the deployment descriptors. That's the other thing I'd
> like to keep.
>
This is a valid desire, but the current state of security standardization
makes this undoable at this point. Even if an application server does
support JAAS there will be application server specific code to translate
from JAAS Subject to what the Subject state means in terms of the
caller principal and the principal roles because there is no standard for
how J2EE security can be implemented in terms of JAAS classes.
> > No, logins have to be done in the thread that is making the
> > request. Since your an EJB client that is a multi-threaded server,
> > you have to establish the client identity on each request since you
> > have no control over how thread pooling assigns threads to servlet
> > requests.
>
> As mentioned above, I'm in the happy situation that there are only two
> servlets that dispatch *everything*. So that's what I'll do now: I
> login at the beginning of the init() and service() methods and logout
> in a finally block. Will this work as expected?
>
Yes because you are establishing the user identity every time in each
request thread.
> But the principles of how JAAS works there are still very indistict to
> me: In my client (admin) application I do the login in a separate
> thread. If logins are bound to threads, my client app should not work,
> because after a successful connection, the thread that logged in
> doesn't exist anymore. That's why I though the scope of a LoginContext
> is the whole JVM. I searched the internet for information about the
> scope of a LoginContext, but I didn't find anything. It would be great
> if you could clear this up a bit...
>
JAAS does not define the lifetime of logins because it depends on how
JAAS is used. In JBoss the ClientLoginModule operates in two modes,
single-threaded and multi-threaded. In single-threaded mode(the default),
the SecurityAssociation information is a VM singleton and the login information
lifetime is the lifetime of the JAAS login. Inside the JBoss server the
SecurityAssociation information is a thread local property and so a JAAS
login only affects the credentials of the thread in which the login was performed.
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
