Hi,

As it turned out in my particular situation it seems impossible to share
the credentials across all the threads.

Let me elaborate (I am longwinded in this mail, as usual :-)

I got an app containing servlet/JSPs and EJB's. I currently deploy them
all in one JBoss (3.0.6) instance (with integrated Tomcat (4.1.18). In
the future the servlet/JSP part might/will be deployed in a separate
Tomcat instance.

User requests come in to the JSP's. This layer performs user
authentication and authorisation based on the application's own 
set of user/password/roles/rights administration in the database (in
fact, these are all encapsulated using entity beans, but that is not
really important right now).

I want the entire web front-end (FE; JSP/servlet) layer to log in to the
appserver as one user (for EJB declarative security checking). In order
to achieve this I have programmed an AppServerLogin object that takes
care of the JAAS Login process using the "client-login" context. This
context is associated with the ClientLoginModule in the login-config.xml
of the JBoss server instance.

ClientLoginModule performs a JAAS login by storing the Subject 
(credentials, userid and password; in my case the userid and password 
of the entire front-end layer) in a SecurityAssociation object. The 
SecurityAssociation object can maintain *either* one Subject for the
entire JVM *or* a Subject per thread. If and when an EJB call is
performed by the client (the front-end), the invocation layer takes the
Subject out of the SecurityAssociation and includes that information in
the remote method call. At the server side (in my case, in the same JVM)
the information is taken out of the method invocation object and
verified. If the information is allright, it is stored in a per-thread
SecurityAssociation and the relevant EJB method is called.

The SecurityAssociation class has a global setting that specifies
whether a per JVM or per thread SecurityAssociation is maintained.
The default setting is per JVM and there exists only a call to change
this to per thread (and not back): SecurityAssociation.setServer().

The EJB environment obviously requires that each thread can have its own
SecurityAssociation since multiple clients may be executing EJB calls
simultanously with different credentials. Because of this, the
JAASSecurityManager class performs a SecurityAssociation.setServer() in
its static (class) constructor. This sets the SecurityAssociation mode
for the entire JVM to per thread!!!!!

This means that my JSP/servlets that are running in the same JVM
automatically live in a per thread security association environment as
well. If my initialisation servlet performs a JAAS Login, it basically
only creates the security association for its own thread. If subsequent
HTTP servlet/JSP requests are handled by different threads they need to
perform their own JAAS Login in order to establish the per thread
security context that their EJB calls will be executed with.

Hence, in order to ensure that each HTTP requests that gets handled and
does EJB calls gets the right SecurityAssociation I need to come up with
a mechanism to ensure that it is created. I am currently thinking about
letting a servlet filter perform that job, but that Still Needs
Research.

I hope this mail clarifies some of the issues for my co-JBoss users...

Jos Visser

And thus it came to pass that Sacha Labourey wrote:
(on Tue, Apr 01, 2003 at 11:48:11AM +0200 to be exact)

> > I still got some outstanding issues with storing the 
> > credentials (at the
> > client side) on a per thread or per instance basis, but I'm working on
> > understanding that issue too...
> 
> The question is: do you want each thread to have its own set of credentials
> or not. For example, imagine that your client is itself a server that
> receives requests and forward them to JBoss. In this case, each thread will
> have its own set of credentials as each thread represents a different
> request and potentially a different user. However, if your application is a
> simple single-user swing application, then that's fine to share your
> credentials across all threads .
> 
> Got it?
> 
> Cheers,
> 
> 
>                       Sacha
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user

-- 
I have my fears, but they don't have me...



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to