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
Craig R. McClanahan wrote: Tomcat 5 has integrated support for JSR 115, but that's for authorization, not authentication. Oh no, there's a difference? Is there an explanatory document somewhere that I missed? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Valve Access to Principal
Howdy, http://www.itsecurity.com/asktecs/oct1801.htm Yoav Shapira Millennium ChemInformatics -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 11:18 AM To: Tomcat Users List Subject: Re: Valve Access to Principal Craig R. McClanahan wrote: Tomcat 5 has integrated support for JSR 115, but that's for authorization, not authentication. Oh no, there's a difference? Is there an explanatory document somewhere that I missed? Erik - 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]
Re: Valve Access to Principal
On Mon, 10 Feb 2003, Erik Price wrote: Date: Mon, 10 Feb 2003 11:17:31 -0500 From: Erik Price [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Valve Access to Principal Craig R. McClanahan wrote: Tomcat 5 has integrated support for JSR 115, but that's for authorization, not authentication. Oh no, there's a difference? Is there an explanatory document somewhere that I missed? Authentication == who are you? In servlet API terms: getRemoteUser() and getUserPrincipal(), and login methods. Authorization == what can you do? In servlet API terms: isUserInRole() and role-based security constraints. Erik Craig - 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
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 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
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
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 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
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]
Re: Valve Access to Principal
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]
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: Valve Access to Principal
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]
Re: Valve Access to Principal
And here I was going to do a boring response like: defer the check to a Filter. :-) I'm actually using a slight variation on Craig's suggestion on one of my internal sites (simply meaning that I can't give you a working URL), and it works very well. Craig R. McClanahan [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... 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]
