Re: Valve Access to Principal
OK I think I owe Craig an apology: There is no standard way to pass JAAS
credentials between VM's. The way that JBoss does it is by using a piece
of code called the ClientLoginModule which interacts with the JBoss RMI
stubs to pass the credentials. Note that JBoss does a login on each
call.
The way I got this working for Tomcat was as follows:
1. Set up a JAAS auth.conf file with 2 login configs for authentication.
1 contains the login module actually used to authenticate and the other
contains the JBoss ClientLoginModule. Call the first login config
Tomcat.
2. Subclass JAASLoginModule and keep a cache of userid's and credentials
with a method to access them.
3. Create a valve that retrieves the principal from the request, looks
up the realm for that principal, retrieves the password from the realm
and does a JAAS login using the second login configuration above for
every HTTP request.
4. In the server.xml file put the following line before the client login
valve:
Valve
className=org.apache.catalina.authenticator.FormAuthenticator/
(Use the appropriate class if you are not doing form authentication)
5. Create an mbeans-descriptors.xml and place it in the jar file with
the realm and the valve. Reference this from a descriptors property in
the ServerLifecycleListener Listener element in server.xml.
6. Put the jar file in ${tomcat.home}/server/lib
I hope that this is of use to anyone else trying to do this.
On Mon, 2003-02-10 at 19:04, Peter Kelley wrote:
I've written a valve to do this and the code should be standard JAAS,
not specific to JBoss. There is a class already in the Tomcat 5 source
that provides utilities to do something similar. If I get this working
I'll let you know, it's something that Tomcat will probably need to do
to talk JAAS to application servers.
If this were JBoss specific I would agree with you but what I want to do
should be following the JAAS standard.
--
Peter Kelley [EMAIL PROTECTED]
Moveit Pty Ltd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Valve Access to Principal
On Mon, 2003-02-10 at 18:30, Craig R. McClanahan wrote: On Sun, 10 Feb 2003, Peter Kelley wrote: Date: 10 Feb 2003 17:22:53 +1100 From: Peter Kelley [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Valve Access to Principal OK I'm still not sure we are talking on the same page so please bear with me whilst I attempt to restate what is happening. Tomcat 4.1.18 running in JDK 1.4 JBoss 3.0.3 running in JDK 1.3 Tomcat is running standalone in a seperate JVM to JBoss. Both Tomcat and JBoss are running on the same machine (although this configuration means that they could be running on seperate machines). Tomcat is running the JAAS login module and running a web application that is making standard RMI calls to EJB's that are running on the JBoss server. You seem to be assuming that Tomcat knows how to propogate the security identity. It does not -- standalone Tomcat doesn't store Subjects or Principals on a per-thread basis at all (it only caches them in the session if there is one), and doesn't support propogation of security identity across JVMs under any circumstances. Any such features in the JBoss+Tomcat integration were implemented by JBoss folks, so you need to ask them for help in understanding what is going wrong in your scenario. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I've written a valve to do this and the code should be standard JAAS, not specific to JBoss. There is a class already in the Tomcat 5 source that provides utilities to do something similar. If I get this working I'll let you know, it's something that Tomcat will probably need to do to talk JAAS to application servers. If this were JBoss specific I would agree with you but what I want to do should be following the JAAS standard. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Valve Access to Principal
Thanks Craig, this sounds like a much cleaner solution than what I eventually tried which was to copy the session grabbing code out of AuthenticatorBase and use it to get the required principal. The problem I am having now is that JBoss still thinks that the logged on user is the last one that logged in from any browser rather than the one logged in with the current session. I have run this through the debugger and my DoAsValve is getting called with the right principals subjects but somehow the JAAS security credentials that get to JBoss belong to the user that last logged in. I'm suspecting that the code that actually processes the JSP is running on another thread but I haven't yet gone down to that level to see. Surely someone else has come up against this problem before ? Does anyone know how this problem is being solved for Tomcat 5 ? On Sat, 2003-02-08 at 18:24, Craig R. McClanahan wrote: On Fri, 8 Feb 2003, Peter Kelley wrote: Date: 08 Feb 2003 17:29:10 +1100 From: Peter Kelley [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Valve Access to Principal I'm writing a valve to associate a request with a subject using JAAS. To do this I need to get access to the userPrincipal from the request or the session. Unfortunately the method that sets this association in org.apache.catalina.authenticator.AuthenticatorBase gets called AFTER my valve meaning that I can't get access to the principal. My valve is currently defined in a context element in server.xml and I can see it on the call stack when I set a breakpoint in AuthenticatorBase in the debugger. Any suggestions as to how I could get the valve to be executed after the authenticator ? I've got an idea, but it requires a little background first. First, let's understand why the behavior you observe actually happens. As the server.xml file is parsed, each Valve element you declare is added to the valve pipeline for this webapp. Among other things, this means that you are guaranteed that valves are invoked in the order that you declare them. After server.xml is processed, but before the webapp is made available, the start() method of an instance of org.apache.catalina.startup.ContextConfig is called to perform any final setup needed before the application is enabled. One of the potential setups (see method authenticatorConfig()) is to set up an Authenticator if this webapp declared an auth-method in its web.xml file (SIDE NOTE - you don't pay any runtime overhead for container managed authentication unless you asked for it). The net effect is that, if you're using container managed authentication, the corresponding Authenticator valve is automatically added to the pipeline -- but *after* any manually configured valves. So, to meet your requirements, we need a mechanism to ensure that the Authenticator is configured into the pipeline *before* your valve is. Currently, you can do this if you manually configure it, because authenticatorConfig() checks to see if an Authenticator has been configured already. So, you would need to say something like this to configure (say) the Authenticator for form-based login ahead of your MySubjectValve valve: Context path=/foo ... !-- Configure an Authenticator implementation to be used -- Valve className=org.apache.catalina.authenticator.FormAuthenticator/ !-- Configure your Valve that wants to see the Principal -- Valve className=com.mycompany.MySubjectValve .../ /Context A downside of this approach is that you have to configure what login method to use in server.xml (the auth-method selected in web.xml essentially gets ignored). An upside of this approach is that you can easily implement and configure an Authenticator that supports a login mechanism totally different from any of the standard methods defined by the servlet spec. For example, it's feasible to define an Authenticator that interacted with a Project Liberty identity server (http://www.projectliberty.org) to enable cross-host single sign on support. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Valve Access to Principal
I think you misunderstand my question, I want to run Tomcat standalone. The problem I have is that the JAAS credentials don't seem to be being associated with the thread that is running my JSP. The fact that JBoss is on the other end is probably irrelevant, the same problem would occur no matter what was being called. I'm happy to help and contribute whatever code gets written but I need to know where would be the best place to do the security association. Putting the association in a valve doesn't seem to be working, somehow the association is being broken by the time the JSP code is called. Can you provide any guidance on where the best place to do the security association might be ? On Mon, 2003-02-10 at 14:58, Craig R. McClanahan wrote: On Sun, 10 Feb 2003, Peter Kelley wrote: Date: 10 Feb 2003 14:31:23 +1100 From: Peter Kelley [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Valve Access to Principal Thanks Craig, this sounds like a much cleaner solution than what I eventually tried which was to copy the session grabbing code out of AuthenticatorBase and use it to get the required principal. The problem I am having now is that JBoss still thinks that the logged on user is the last one that logged in from any browser rather than the one logged in with the current session. I have run this through the debugger and my DoAsValve is getting called with the right principals subjects but somehow the JAAS security credentials that get to JBoss belong to the user that last logged in. I'm suspecting that the code that actually processes the JSP is running on another thread but I haven't yet gone down to that level to see. Surely someone else has come up against this problem before ? I'm afraid that I'm a total newbie in terms of understanding how JBoss decided to integrate Tomcat. One of the benefits of the Tomcat architecture is that there are many different options for this. One of the disadvantages, though, is that those of us focused on the standalone Tomcat server don't necessarily have a clue on how it was done in any particular case :-). Maybe some questions to the JBoss mailing lists would be in order? One thing to review, though, is the order in which the valves get authenticated -- you probably want to ensure that your valve is invoked before any valves that the JBoss integration adds. Does anyone know how this problem is being solved for Tomcat 5 ? Tomcat 5 has integrated support for JSR 115, but that's for authorization, not authentication. At some future point, I'm sure Tomcat will incorporate the results of JSR 196 (Java Authentication Service Provider Interface for Containers), but not until that JSR actually has a public release of its spec -- it has only just gotten underway. Craig On Sat, 2003-02-08 at 18:24, Craig R. McClanahan wrote: On Fri, 8 Feb 2003, Peter Kelley wrote: Date: 08 Feb 2003 17:29:10 +1100 From: Peter Kelley [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Valve Access to Principal I'm writing a valve to associate a request with a subject using JAAS. To do this I need to get access to the userPrincipal from the request or the session. Unfortunately the method that sets this association in org.apache.catalina.authenticator.AuthenticatorBase gets called AFTER my valve meaning that I can't get access to the principal. My valve is currently defined in a context element in server.xml and I can see it on the call stack when I set a breakpoint in AuthenticatorBase in the debugger. Any suggestions as to how I could get the valve to be executed after the authenticator ? I've got an idea, but it requires a little background first. First, let's understand why the behavior you observe actually happens. As the server.xml file is parsed, each Valve element you declare is added to the valve pipeline for this webapp. Among other things, this means that you are guaranteed that valves are invoked in the order that you declare them. After server.xml is processed, but before the webapp is made available, the start() method of an instance of org.apache.catalina.startup.ContextConfig is called to perform any final setup needed before the application is enabled. One of the potential setups (see method authenticatorConfig()) is to set up an Authenticator if this webapp declared an auth-method in its web.xml file (SIDE NOTE - you don't pay any runtime overhead for container managed authentication unless you asked for it). The net effect is that, if you're using container managed authentication, the corresponding Authenticator valve is automatically added to the pipeline -- but *after* any manually configured valves. So, to meet your
Re: Valve Access to Principal
OK I'm still not sure we are talking on the same page so please bear with me whilst I attempt to restate what is happening. Tomcat 4.1.18 running in JDK 1.4 JBoss 3.0.3 running in JDK 1.3 Tomcat is running standalone in a seperate JVM to JBoss. Both Tomcat and JBoss are running on the same machine (although this configuration means that they could be running on seperate machines). Tomcat is running the JAAS login module and running a web application that is making standard RMI calls to EJB's that are running on the JBoss server. The way that JBoss (and other JAAS enabled servers) determine who is calling them is by looking at the JAAS Subject associated with the calling thread. If Tomcat is using a pool of threads to service requests from web clients then it stands to reason that at some point in the invocation of the JSP code that there needs to be an association made between the thread that is performing the work and the JAAS subject which tells JBoss who is calling the EJB. This is a direct parallel to the code in AuthenticatorBase that gets the Principal out of the user's session and sets the request up so that calls to getUserPrincipal() return the correct value. I have modified the realm so that it caches the JAAS security credentials when a log in is performed and indexes it by the user name. When a request comes in the valve I have written looks up the principal from the user's session, gets the name, looks up the cached subject then makes a Subject.doAs() call that calls the invoke method on the valve context so the rest of the pipeline is executed with the right JAAS security association. All of this seems to be working in the debugger correctly. The problem is that the JAAS security association that I am doing seems to be with the wrong thread or something because by the time JBoss sees it the subject is the one of the user who most recently logged in. I'm going to have to dig deeper into the Tomcat internals to figure this out but some pointers on how JSP code is invoked in Tomcat would be extremely helpful. Sorry to labour the point but I really think that if this is an issue with the way that Tomcat associates user sessions with JAAS credentials then someone will have to solve this problem before Tomcat 5 ships and since we have the problem it might as well be me. All I need is some suggestions about where the best place to put the code would be. On Mon, 2003-02-10 at 16:31, Craig R. McClanahan wrote: On Sun, 10 Feb 2003, Peter Kelley wrote: Date: 10 Feb 2003 16:12:36 +1100 From: Peter Kelley [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Valve Access to Principal I think you misunderstand my question, I want to run Tomcat standalone. The problem I have is that the JAAS credentials don't seem to be being associated with the thread that is running my JSP. The fact that JBoss is on the other end is probably irrelevant, the same problem would occur no matter what was being called. No, it is *absolutely* relevant, because your complaint is that *JBoss*, not Tomcat, is not seeing the Principal you think it should. I'm happy to help and contribute whatever code gets written but I need to know where would be the best place to do the security association. Putting the association in a valve doesn't seem to be working, somehow the association is being broken by the time the JSP code is called. Can you provide any guidance on where the best place to do the security association might be ? Show me a scenario that fails in standalone Tomcat and we can talk. If the problem shows up only in Tomcat+JBoss, go talk to whoever built that integration. Craig -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Valve Access to Principal
On Mon, 2003-02-10 at 17:22, Peter Kelley wrote: All of this seems to be working in the debugger correctly. The problem is that the JAAS security association that I am doing seems to be with the wrong thread or something because by the time JBoss sees it the subject is the one of the user who most recently logged in. I tell a lie, setting a breakpoint in the JSP code shows the valve on the method call stack. Must be a bug in the JAAS association code. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Valve Access to Principal
I'm writing a valve to associate a request with a subject using JAAS. To do this I need to get access to the userPrincipal from the request or the session. Unfortunately the method that sets this association in org.apache.catalina.authenticator.AuthenticatorBase gets called AFTER my valve meaning that I can't get access to the principal. My valve is currently defined in a context element in server.xml and I can see it on the call stack when I set a breakpoint in AuthenticatorBase in the debugger. Any suggestions as to how I could get the valve to be executed after the authenticator ? -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAAS login context propagation to JBoss
I tell a lie, you can't get access to the users session easily from a realm's authenticate method. Perhaps I could write a valve that looks at the request and looks up the realm the user belongs to. I could then cache the subjects in the realm and run the rest of the pipeline using doAs(subject, ). This seems awfully low level but I can't see another way. Can anyone suggest an alternative ? Surely this problem has been encountered before. On Thu, 2003-02-06 at 15:43, Peter Kelley wrote: I have set up form based authentication for Tomcat 4.1.18 using the JAASRealm and I am using it to connect to a remote JBoss server. Whenever a new user logs in all of the sessions of the existing users take on the identity of the new user on the EJB server. It appears as if something needs to be done to associate the JAAS subject with the current thread every time a request comes in. I can cache the subject in the session but I'm not sure how to go about doing the association. Any ideas ? -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: export exel stylesheets from jsp
Or use Jasper Reports from sourceforge. Reports can be produced as xls or PDF or a number of other formats. If you need to do this on the web you might want to use webwork (http://www.opensymphony.com) which has a Jasper Reports view. On Fri, 2003-02-07 at 02:13, Bill wrote: There is a link on jakarta home to article on how to use POI to create Excel reports. I would think that might be a starting point... On Thu, 2003-02-06 at 10:00, Power-Netz (Schwarz) wrote: Hi , does anyone know if theres a package to make exel stylesheets ? I want to dump a database and make downloadable on the fly for the user.. Ihr Support-Team POWER-NETZ® Full-Service-Provider Online-Support: Support: 0190 - 15 11 15 (EUR 0,62/Min) http://Support.Power-Netz.de (kostenlos) http://Support.Power-Netz.com (kostenlos) Vertrieb Tel: 01805 - 57 35 57 (EUR 0,12/Min.) Vertrieb Fax: 01805 - 57 45 57 (EUR 0,12/Min.) Power-Netz Am Plan 1 37581 Bad Gandersheim http://www.Power-Netz.de mailto:[EMAIL PROTECTED] +=+ --I N F O C E N T E R-- + Senden Sie eine leere e-mail an: + Providerwechsel: mailto:[EMAIL PROTECTED] + Daten/Preise Webspace: mailto:[EMAIL PROTECTED] + Reseller-Programm: mailto:[EMAIL PROTECTED] + Dedizierte Server: mailto:[EMAIL PROTECTED] + Adult/Erotikserver: mailto:[EMAIL PROTECTED] + Domainpreise: mailto:[EMAIL PROTECTED] + Domain-Nameserver: mailto:[EMAIL PROTECTED] + SSL-Zertifikate: mailto:[EMAIL PROTECTED] + Geschaeftsbedingungen: mailto:[EMAIL PROTECTED] + =+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAAS login context propagation to JBoss
I had a look at the code and I guess it could be used to do the association but what it seems to be doing is just creating a new Subject and adding the required principal (which I assume has been obtained from the servlet request) to it. If JAASRealm is used this will be a GenericPrincipal which is different to the principal obtained when doing the login (I'm using JBoss in this case). Are there any plans for Tomcat 5 to cache the subjects obtained upon login anywhere ? Also can you confirm that a valve would be the right place to do this sort of association ? On Fri, 2003-02-07 at 02:30, Jeanfrancois Arcand wrote: The feature you want has been implemented in Tomcat 5 (not in Tomcat 4.1.x). You can probably port it if you realy needs it (see http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java) or starts using Tomcat 5. -- Jeanfrancois Peter Kelley wrote: I tell a lie, you can't get access to the users session easily from a realm's authenticate method. Perhaps I could write a valve that looks at the request and looks up the realm the user belongs to. I could then cache the subjects in the realm and run the rest of the pipeline using doAs(subject, ). This seems awfully low level but I can't see another way. Can anyone suggest an alternative ? Surely this problem has been encountered before. On Thu, 2003-02-06 at 15:43, Peter Kelley wrote: I have set up form based authentication for Tomcat 4.1.18 using the JAASRealm and I am using it to connect to a remote JBoss server. Whenever a new user logs in all of the sessions of the existing users take on the identity of the new user on the EJB server. It appears as if something needs to be done to associate the JAAS subject with the current thread every time a request comes in. I can cache the subject in the session but I'm not sure how to go about doing the association. Any ideas ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAAS login context propagation to JBoss
I have set up form based authentication for Tomcat 4.1.18 using the JAASRealm and I am using it to connect to a remote JBoss server. Whenever a new user logs in all of the sessions of the existing users take on the identity of the new user on the EJB server. It appears as if something needs to be done to associate the JAAS subject with the current thread every time a request comes in. I can cache the subject in the session but I'm not sure how to go about doing the association. Any ideas ? -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
