Another...java.lang.LinkageError:loader constraints violated
Hi, I have found a number of this error in the archive but no answer. From a standard 4.0.1 distribution I place xalan.jar in the webapps lib directory for this webapp and I get the error, however, if I move xalan.jar to %CATALINA_HOME%/lib the problem does not occur. I can't figure out why this is happening. Any ideas. Error below. Antony root cause java.lang.LinkageError: loader constraints violated when linking org/xml/sax/ErrorHandler class at com.teamware.phoenix.presentation.dispatcher.DefaultValues.(DefaultValues.java:95) at com.teamware.phoenix.presentation.dispatcher.DispatchMapper.clear(DispatchMapper.java:116) at com.teamware.phoenix.presentation.dispatcher.DispatchMapper.init(DispatchMapper.java:90) at com.teamware.phoenix.presentation.InitializePresentation.init(InitializePresentation.java:150) at org.apache.jsp.index$jsp._jspService(index$jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106) at java.lang.Thread.run(Thread.java:484) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Off topic:Old jserv source question
Daniel Rall wrote: On Mon, 3 Dec 2001, Antony Bowesman wrote: Craig R. McClanahan wrote: Apache JServ sources are still available via anonymous CVS from the Jakarta web site (see http://jakarta.apache.org/site/cvsindex.html). The CVS module name is java-jserv. Brilliant! Thanks Craig. containsHeader() was broken in jserv 1.1.2. Noticed by Michael Stack, I submitted a fix for this issue a while back (committed by Jon Stevens). JServ development is dead, but if you're in a situation where you must use JServ, I recommend using CVS HEAD. Thanks Daniel, I noticed your name in the comments, we are just trying to remove the jserv dependancy to use tomcat 4. Most of the work is done, just have to get customers to move... Antony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Off topic:Old jserv source question
Hi,
Sorry for the legacy question but it seems all the names I come across
when doing a search for this seem to be working on Tomcat...
I'm stuck fixing a problem with a servlet running in jserv/apache
environment.
I have a servlet service() method which sets a response header
public void service(HttpServletRequest req, HttpServletResponse resp)
throws ServletException
{
resp.setHeader(Pragma, no-cache);
if (resp.containsHeader(Pragma))
...
The containsHeader() ALWAYS returns false. I'm running
Apache/1.3.12 (Unix) mod_ssl/2.6.6 OpenSSL/0.9.6 ApacheJServ/1.1.2
I can't find any source for JServeConnection. Can anyone tell me if
containsHeader is supposed to work. I found some cvs commits on the web
which may have implied that it always does return false.
Many thanks
Antony
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problem with JAAS and TOMCAT 4.0.1
Ismael Blesa Part wrote: Hi have modified the sample given with JAAS 1.0. I have developed a jsp that calls the sample.java file. This file has been modificated in several ways, the main method has been changed to a method class and some other changes to adapt it to a web application. The problem is that when I try to run the jsp I get the following error: java.lang.SecurityException: unable to instantiate LoginConfiguration at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:212) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:166) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:163) at javax.security.auth.login.LoginContext.(LoginContext.java:319) at sample.Sample.run(Sample.java:47) at org.apache.jsp.Login$jsp._jspService(Login$jsp.java:64) I have tried copying the jaas.jar, the sample_jaas.config and the loginmodule classes to all the places where I think that it should work. Have a look at the tomcat-user archives for messages 'JAAS not working any more with Tomcat 4.0'. (Oct 2001) Antony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Default policy file for TC4 - excessive permissions
The catalina.policy file gives AllPermissions to the webapp shared lib/classes directories by default. Isn't this too liberal. Shouldn't the policy file explicitly name the 3 jars with the default 4.0.1 distribution in lib. Rgds Antony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Session variables in TC 4.0.1 realms
Hi,
I'm going to develop an authentication realm (based on FORM
authentication) for TC 4.0.1 which performs a kind of
challenge/response task: Put a challange into a session variable
on the login page (.jsp). The expected password would then be the
encrypted challenge. Whithin my realm the decryption of the
response and the verification against the stored session variable
has to be performed. The problem is that the HTTP request is not
accessible whithin TC 4.x realms. This was possible in TC 3.x.
Is there any possibility to access a session variable in a TC 4.x
custom realm? Thank you.
I came across the same problem in that the realm can only get the
username/password from a form page and no other parameters you may want
to use. (We have other parameters the user can select at login to
indicate post login preferences). Solution is to modify the Realm
interface o.a.c.Realm to add
public Principal authenticate(String username, String credentials,
HttpServletRequest hreq);
and modified o.a.c.realm.RealmBase
public Principal authenticate(String username, String credentials,
HttpServletRequest hreq)
{
return authenticate(username, credentials);
}
and then clone o.a.c.authenticator.FormAuthenticator so that it calls
context.getRealm().authenticate(username, password, hreq);
Craig has relied to one of my earlier messages entitled 'Getting
HttpRequest inside Realm/Tomcat 4' and the reasons behind why it was not
possible.
You can use your own FormAuthenticator class by putting your class name
in the o.a.c.startup.Authenticators.properties. You have to install
these 2 class files and properties files as classes in the
server/classes directory so they are loaded before the ones from the
catalina.jar in server/lib
Rgds
Antony
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
Hi, Interesting discussion, it's good to see some on this distribution issue, the devils always in the detail! See comments | But how would they know where the sessions ended up All session managers keep a copy of all sessions. So, it doesn't matter which server a client talks to. This idea of all SM's keeping copies of all sessions seems to go against the point of having multiple SMs. If increasing SMs is a way to provide redundancy then this approach removes scaleability. If increasing SMs is to provide scaleability then having all sessions in all managers won't work. If you hit the bottleneck then you can't just add a new SM to solve any load problem. Why do SMs need to have copies of all, why not just keep those sessions that are created in the SM there. The session ID can contain the SM service id which can be adopted by a service that takes over from any failed one. If we become more granular, such that individual session attribute changes are communicated independantly (rather than a complete copy of the session) our need for locking may diminish. However, I'm still not convinced about the need for locking to begin with. Agreed, I am not convinced locking is necessary either, I have a distributed session implementation that uses session proxies that talk to services and pass only deltas of changes to the session. Session services notify proxies that have the session of changes which get refreshed lazily when required. SMs are remote over RMI and the proxy is local to the container. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] phone: +358 9 5128 2562 fax : +358 9 5128 2705 intra / extra / Internet solutions at www.teamware.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
J2EE 1.3/Tomcat/JAAS
Hi, Is there a target for Tomcat to become a J2EE 1.3 conformant web container? If so, what are the plans for supporting section 6.13 J2EE.6.13 Java Authentication and Authorization Service (JAAS) 1.0 Requirements All EJB containers and all web containers must support the use of the JAAS APIs as specified in the Connector specification. Rgds Antony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: J2EE 1.3/Tomcat/JAAS
Craig R. McClanahan wrote: That being said, we have tried to conform to the J2EE 1.3 platform requirements where feasible (such as with the JNDI naming context), and this one (JAAS) looks like a very useful addition. In principle, it will require a Realm implementation that speaks the JAAS APIs, plus some defined mechanism for role mapping. Any volunteers working on this already? Anyone want to contribute some code? I have a JAAS Realm that supports role mapping, however, it's using an extended Realm interface so that HttpRequest parameters can be passed to the JAAS LoginModules. It still has some open issues, such as integrating JAAS logout with the container, however, what state do you need code to be in to be contributed? Rgds Antony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Getting HttpRequest inside Realm/Tomcat 4
Craig, One of the outgrowths of that realization is another JSR that you might want to keep track of (via http://www.jcp.org: JSR #115 -- Java(tm) Authorization Service Provider Contract for Containers Once this is fleshed out, Tomcat can be modified to support the new SPI contracts, and your Realm-equivalent implementation will itself be portable to different containers if it conforms. Until then, though, I'm a little gunshy about mucking around with the Realm interface. Yes, I had seen this, essentially, it looks to standardise what we are already using, i.e. a JAAS subject wrapped inside the authenticated container principal and each of the JAAS principals represents a role (or something else) with associated permissions. J2EE roles and application roles are both supported. This allows us to use principal based access control. Also with the configurable rolemapper class we can effectively delegate as many access control decisions as we like. That seems like a reasonable strategy. Well, it's done now :). Is there any likelihood of these interfaces/classes changing. I've changed Realm, RealmBase and made my own FormAuthenticator. Are there any changes planed to these realm parts? JAAS would of course tie Tomcat to JDK1.3+, is there a minimum for Tomcat 4? The current supported minimum is JDK 1.2.2. And, I thought JAAS required 1.4 -- am I mis-remembering? JAAS 1.0 was introduced as an extension to JDK1.3 but incorporated into 1.4 with some minor changes. I'm glad to see that JAAS is now adopted as a requirement in J2EE 1.3 spec, although it only mandates version 1.0 of JAAS. What is the roadmap for Tomcat to confirm to J2EE 1.3, presumably that means some kind of JAAS support required (why not start now!!) I assume you mean my BOF on container-managed security, right? Forwarded under separate cover. Received. Many thanks. Antony
Re: Getting HttpRequest inside Realm/Tomcat 4
Hi Craig, Thanks for your comments again. You're right ... there is nothing there to do this. The original design was based on the idea that Realm simply encapsulates a service that authenticates a user, given a username and some credentials. In addition, it needs to work even when HTTP sessions are not in use (for example, for BASIC authentication). One strategy for dealing with this might be to register a session event listener and registers your session in the sessionCreated() event handler. I like the realm and general design in TC4, it's much better and cleaner than 3.2. However, I think there is something missing in the realm interface authenticate methods, particulary for form login:- If you modify a login form to include a field other than j_username and j_password so the user can select some kind of 'post login preferences' it is not possible to get this extra field to the realm. We use JAAS for authentication. JAAS allows and one of the login modules authenticates against our EJB user repository and loads user preferences (groups/roles etc) and one feature the user can select is their preferred role set for the session. I don't think the event listener will work for our use, following login, so it seems the following is how I can achieve what I want. Replace the org.apache.catalina.authenticator.FormAuthenticator with my own FormAuthenticator class by modifying the Authenticators.properties and extend the realm interface to pass either a map of http request parameters, or in fact the http request itself. My realm can do what it wants. What about passing the Request object as a parameter to the Realm interface authenticate() methods for 4.1 release. And how about having only a JAAS realm in standard tomcat and just provide different login modules for jdbc/jndi/other access. JAAS would of course tie Tomcat to JDK1.3+, is there a minimum for Tomcat 4? BTW, I saw you offered your BOF slides to someone, are they available? Rgds Antony
Re: JAAS/Classloaders/Tomcat4
Hi Craig, Thanks for the reply. Craig R. McClanahan wrote: You should *not* be doing both of these things -- either put it on the classpath *or* put it in $CATALINA_HOME/lib. I agree, but that's part of the problem, where do you put the jar file if it needs to be on the system classpath, e.g. we use log4j in our login module so this has to be on the system classpath too. Should this be put in bin like bootstrap.jar. It's a bit overkill to put it in $JAVA_HOME/jre/lib/ext. Have you tried putting JAAS in the System Extensions directory instead ($JAVA_HOME/jre/lib/ext)? This directory is automatically added above the system class path. Yes, that also works for jaas but the login module classes do not go there. There is no concept in Tomcat 4.0 of a system classes directory where you can just dump the odd class as the classes directory is used by the shared classloader. In Tomcat 4.0, the directory $CATALINA_HOME/classes is added to the shared classloader if it exists at startup time. This would contain unJARed classes and resources, analogous to /WEB-INF/classes within a webapp. The problem is the 'shared' classloader is no use for JAAS. All user login modules have to be on the system classpath and there is no dynamic way to change Tomcat environment to add login modules without editing the startup script. Tomcat 3.2 used the technique of actually modifying the system class path. Unfortunately, it causes platform specific problems, especially on Windows where there are limits on the overall length of an environment variable, and lots of strange restrictions on building an environment variable dynamically in the script. In addition, editing the class path manually has historically been the source of a very high percentage of newbie user errors. The current approach that Tomcat takes (build class loaders internally based on the contents of directories) is much more reliable and less error prone. I agree, the tomcat 4 way is a much better way, we have similar problems of command line length with NT and dynamic classpath building and are looking to adopt some alternative mechanism. Rgds Antony
Getting HttpRequest inside Realm/Tomcat 4
Hi, I have a realm implementation that needs to access the HttpSession when a new successful authentication request is made. (I need to hand off the session to a third party) How can I do this from within the realm.authenticate() method? I've looked through the Container interface and can't find anything. Rgds -- Antony Bowesman Teamware Group [EMAIL PROTECTED] phone: +358 9 5128 2562 fax : +358 9 5128 2705 intra / extra / Internet solutions at www.teamware.com
JAAS/Classloaders/Tomcat4
Hi, I've been a bit confused after reading the classloader docs for Tomcat 4, the %CATALINA_HOME/lib %CATALINA_HOME/classes are accessed via the shared classloader but the startup script sets certain jars from %CATALINA_HOME/lib on the system classpath. JAAS 1.0 requires login config and login modules to be on the system classpath so to that end I have put jaas.jar to %CATALINA_HOME/lib and added it to the classpath used in catalina.(sh|bat). There is no concept in Tomcat 4.0 of a system classes directory where you can just dump the odd class as the classes directory is used by the shared classloader. I gather the shared classpath will be renamed 'shared/lib + classes' in 4.1 but wouldn't it be useful if the catalina startup script set the classpath to all the jars in %CATALINA_HOME/lib and %CATALINA_HOME/classes. At least this way no modifications need to be done to the startup scripts and JAAS login modules can just be dropped into the system classes directory as needed. Rgds -- Antony Bowesman Teamware Group [EMAIL PROTECTED] phone: +358 9 5128 2562 fax : +358 9 5128 2705 intra / extra / Internet solutions at www.teamware.com
Re: First day - RE: PROPOSAL: Tomcat docs
Glenn Nielsen wrote: Antony Bowesman wrote: 8. Security How about 8.1 Concepts - Explanation of J2EE and Java 2 security models 8.2 Authentication with Realms 8.2.1 Simple realm 8.2.2 JDBC Realm 8.2.3 Custom realms 8.3 Authorization 8.3.1 J2EE role based In particular, it should try to explain in simpler terms than the API spec how J2EE roles are designed to work, covering the mapping from developer roles to deployment roles. 8.3.2 Java 2 security policy I would break the above into two sections. Access Control (for all the Realm based access control) and Server Security (for configuring and using Tomcat with the Java SecurityManager) These really are two completely different topics. And use of Realms isn't Security, it is Access Control. Not sure I'd agree with your removal of Java Security Manager from a chapter about access control. The first line of the JavaTM 2 Platform Security Introduced: document at http://java.sun.com/j2se/1.3/docs/guide/security/index.html says * Policy-based, easily-configurable, fine-grained access control Access control is one element of securing a server, as is authentication, encryption, non repudiation, SSL etc. Access control is performed by Java 2 security manager as well as J2EE and they compliment each other. JAAS (JDK1.3 extension) which extends the Java 2 model and which is now included in JDK1.4 extends the Java 2 security model to provide principal based access control on top of code source. So access control is firmly part of Java security. There should be additional sections on 'server security' that includes configuring the server for use with SSL. Antony
Re: First day - RE: PROPOSAL: Tomcat docs
Glenn, Glenn Nielsen wrote: Antony Bowesman wrote: Glenn Nielsen wrote: Antony Bowesman wrote: 8. Security How about 8.1 Concepts - Explanation of J2EE and Java 2 security models 8.2 Authentication with Realms 8.2.1 Simple realm 8.2.2 JDBC Realm 8.2.3 Custom realms 8.3 Authorization 8.3.1 J2EE role based In particular, it should try to explain in simpler terms than the API spec how J2EE roles are designed to work, covering the mapping from developer roles to deployment roles. 8.3.2 Java 2 security policy I would break the above into two sections. Access Control (for all the Realm based access control) and Server Security (for configuring and using Tomcat with the Java SecurityManager) These really are two completely different topics. And use of Realms isn't Security, it is Access Control. Not sure I'd agree with your removal of Java Security Manager from a chapter about access control. The first line of the JavaTM 2 Platform Security Introduced: document at http://java.sun.com/j2se/1.3/docs/guide/security/index.html says * Policy-based, easily-configurable, fine-grained access control Access control is one element of securing a server, as is authentication, encryption, non repudiation, SSL etc. Access control is performed by Java 2 security manager as well as J2EE and they compliment each other. JAAS (JDK1.3 extension) which extends the Java 2 model and which is now included in JDK1.4 extends the Java 2 security model to provide principal based access control on top of code source. So access control is firmly part of Java security. There should be additional sections on 'server security' that includes configuring the server for use with SSL. I have seen the general term 'security' used instead of a more descriptive term like SSL Encryption, SecurityManager, or Access Control. My point is that these are very different things, and the documentation should be constructed so that users use those terms rather than the general term Security. Yes, I agree there are different elements of security, I don't agree that access control is different to security manager. The difference is that java 2 security, i.e. security manager, is different to J2EE role based access control. Security Overview - types of security J2EE Security Model User Access Control (Realms roles) Java SecurityManager SSL Data Encryption Yes, JAAS can be used to control access for executing code based on what role the user is in. At this point there is no support in Tomcat for JAAS. Not specifically, because the servlet API spec does not support it, however, JAAS is on the list for servlet API spec 2.4 (who knows when that might be!). However, I am currently using JAAS in Tomcat 3 and I know others have JAAS running with tomcat (e.g. Jboss/Tomcat integration) There are two ways I see JAAS being used within Tomcat sometime in the future. 1. Policy based JAAS access control to Tomcat's manager or admin servlet. 2. Some Policy configuration tool for webapps that supports normal Java SecurityManager configuration and JAAS policy based access control. I suspect that when the API spec supports JAAS there will be some kind of getUserSubject() method in the spec that gets the JAAS Subject and the getUserPrincipal() will be deprecated because JAAS supports more than a single Principal. However, as SecurityManager uses the Java 2 security Policy it effectively enable JAAS support as soon as JDK1.4 is released. Tomcat could therefore provide support for the JAAS Subject internally. However, I have seen other comments on this list that Tomcat is trying to support many early versions of JDK so requiring JDK1.4 support might be too difficult. Anyway, SUN are asking for feedback about how JAAS should be implemented in the servlet API spec, so send your comments there, I already have! Rgds Antony
Re: First day - RE: PROPOSAL: Tomcat docs
Punky Tse wrote: Rob, Please see below for rephrased version of Introduction and Administrator Guide. I combined the Introduction and Administrator's Guide to Administrator Guide. Actually this is my proposed TOC. And I believe that we need separate document for different Tomcat servers. e.g. 3.3 and 4.0. snip II. Server Administration 6. Configuring Server 7. Configuring Web Applications 8. Security How about 8.1 Concepts - Explanation of J2EE and Java 2 security models 8.2 Authentication with Realms 8.2.1 Simple realm 8.2.2 JDBC Realm 8.2.3 Custom realms 8.3 Authorization 8.3.1 J2EE role based In particular, it should try to explain in simpler terms than the API spec how J2EE roles are designed to work, covering the mapping from developer roles to deployment roles. 8.3.2 Java 2 security policy III. Advanced Topics 9. Web Servers and HTTP Connectors 9.1 Apache 9.1.1 mod_jk 9.1.2 mod_jserv 9.1.3 mod_webapp (for Tomcat 4.0) 9.2 IIS 9.3 iPlanet 9.4 Netware 9.5 Lotus Domino 10. Performance Tuning 11. Load-balancing No idea how to do load-balancing in Tomcat, what I know is that it can be done through mod_jserv and mod_jk 12. Using SSL May be under Section 6: Configuring Server? 13. Realms No idea: or should it be under Security? Don't think realms should be 'advanced'. It should be convered in security. However, maybe there should be an advanced security section covering 13. Security 13.1 Using Tomcat authentication with Webservers 13.1.1 Apache 13.1.2 IIS 13.1.3 iPlanet 13.1.4 Netware 13.1.5 Lotus Domino Antony
Re: per-context realms
Michael Jennings wrote:
Hi everyone,
Does anyone have an idea of how I could go about implementing
realms/authentication on a per-context basis?
Ideally, what I would like to do is have each context control
their users and roles. Where should I look to get a clue?
Make a simple realm implementation that simply gets the real realm
config information from the context passed with the request, e.g.
authenticate(Req)
{
Context ctx = req.getContext();
// Now you have all the context config available
..
}
I have a JAAS realm which has context specific realm config using the
context-param
param-nameName/param-name
param-valueValue/param-value
/context-param
attributes in web.xml to provide context specific control.
In the realm, just so
String ctxNameValue = ctx.getInitParameter(Name);
or similar. With JAAS this is easy, because JAAS allows for different
JAAS configurations to be used, you just specify a different config name
to the JAAS context.
Antony
Re: realms and authentication
Andy Armstrong wrote: Michael Jennings wrote: Thanks for the feedback! Does tomcat 3.2.2 currently support JAAS? Not in any explicit sense I think (anyone?), JAAS is not explicitly supported by tomcat. JAAS was only available from JDK 1.3, supplied as an extension. JAAS is now merged into JDK1.4 but there is no explicit support for JAAS in the servlet API spec 2.3 although JAAS is graudually gaining momentum. There has to be some reworking to the servlet spec (as well as EJB) to support the concept of multiple Principals and the JAAS Subject. but JAAS is usable with Tomcat -- if that isn't too much of a politicians answer! Yes, it is easy enough to write a JAAS Realm, just like SimpleRealm and JDBC Realm. Antony
Re: realms and authentication
Ignacio J. Ortega wrote:
I do like your idea , this was something i was talking some time ago,
But better than for 3.2.2 ( that is on bug fix mode only , no new
features ), But I would prefer to apply your idea to share Realms
Implementatios between 3.3 and 4.0, a much more useful objetive..
I would like to see Tomcat taking the initiative and providing core
support for JAAS given then pending inclusion of JAAS in the final
release of JDK1.4. I know this would limit tomcat to JDK1.3 and above
but this should not be a problem for v4. All the existing realm
implementations can then be re-implemented as JAAS LoginModules.
Antony
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Michael Jennings [mailto:[EMAIL PROTECTED]]
Enviado el: martes 5 de junio de 2001 1:27
Para: [EMAIL PROTECTED]
Asunto: realms and authentication
Hi everyone,
Just for my own education, I decided to write my own
authentication-stuff
for tomcat 3.2.2
To that end I wrote a Request Interceptor that takes 2 parameters
called realmProviderClass and setupString.
The realmProviderClass is the fully-qualified class name of
a class which
implements
the RealmProvider interface which looks like the following:
public interface RealmProvider
{
public boolean authenticate(String username, String
credentials) throws
Exception;
public String[] getUserRoles(String username) throws Exception;
public boolean initialize(String setupstring) throws Exception;
public void shutdown() throws Exception;
}
The setupString parameter is passed to the initialize method of the
RealmProvider class
during context initialization.
I thought that this might be an easy way to implement various
different
authentication schemes
by delegating to a RealmProvider. One could write a
SimpleRealmProvider
or a JDBCRealmProvider
etc.
Does anyone think this might be a good idea for inclusion in tomcat?
-Mike
__
Mike Jennings
Southgate Software Ltd.
250-382-6851 (ph)
250-382-6800 (fax)
[EMAIL PROTECTED]
Re: realms and authentication
Andy Armstrong wrote: Antony Bowesman wrote: Andy Armstrong wrote: Michael Jennings wrote: Thanks for the feedback! Does tomcat 3.2.2 currently support JAAS? Not in any explicit sense I think (anyone?), JAAS is not explicitly supported by tomcat. JAAS was only available from JDK 1.3, supplied as an extension. JAAS is now merged into JDK1.4 but there is no explicit support for JAAS in the servlet API spec 2.3 although JAAS is graudually gaining momentum. There has to be some reworking to the servlet spec (as well as EJB) to support the concept of multiple Principals and the JAAS Subject. I've just been having a look at this. As you say it would be easy enough to implement a JAAS realm -- the main problem being how to provide access to the JAAS Subject. The cleanest route would seem to be just to expose the Subject directly by adding Subject getUserSubject() to HttpServletRequest() leaving the question of how to change the handling of Principals to reflect the fact that there can be more than one under JAAS. Exactly, I would hope that this is how it will be exposed in Servlet and EJB specs with getUser/CallerPrincipal being deprecated in favour of getUser/CallerSubject. Another issue is how roles work. The current isUser/CallerInRole methods are rather simple. Mapping realm roles to application roles needs to be addresses, I see that Alex Roytman's mail to user group allows for a role mapping class to map from user realm roles to the J2EE roles in the servlet spec. I also have the same concept with my JAAS realm so that user realm roles can be mapped to J2EE String roles based on the web app context. It seems to make sense that roles would be incorporated as Principals inside the Subject so they could then be used inside JAAS authorization. Antony
What are 'notes' all about
Hello, I posted this to the user list but got no response... Any ideas anyone? For Tomcat 3, is there any information on 'notes', what they are and what they do. There are various references to these notes in the source but I'd like to see concrete examples of their usage as the comments are fairly abstract and don't give much clue. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Re: JSP and SecurityManager [was RE: 3.2.2. When's it shipping?]
Thanks Marc, part of my problem was that JVM tries to load all files in
${java.home}/lib/ext as possible jar files regardless of file name.
Your permission additions solve the rest!
Antony
Marc Saegesser wrote:
I added the permissions to the global list of permissions. I've attached
the most recent tomcat.policy file.
-Original Message-
From: Antony Bowesman [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 21, 2001 12:49 AM
To: [EMAIL PROTECTED]
Subject: Re: JSP and SecurityManager [was RE: 3.2.2. When's it
shipping?]
Marc Saegesser wrote:
The null check is simple enough and its already been tested in 3.3
so I feel comfortable making the change without a beta. I'll commit
the change today.
Great, thanks!
Another question regarding using the security manager and JSP. If
I use the default tomcat.policy file I can't access any JSP pages
because I get an access denied expcetion getting the line.separator
property. If I add
permission java.util.PropertyPermission line.separator, read;
permission java.util.PropertyPermission file.separator, read;
to tomcat.policy the pages are served correctly. Glenn, is there
any problem adding these two lines to the default policy? Am I
missing something else?
I've tested this but it ONLY works if you add these permissions with no
codeBase. If you add them under the specified codeBase
grant codeBase file:${tomcat.home}/-
They still cause the access exception. I have even tried the following
codeBases
grant codeBase file:c:/-
grant codeBase file:h:/-
with still the same exception. Why doesn't it work??
Rgds
Antony
-Original Message-
From: Antony Bowesman [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 1:50 AM
To: [EMAIL PROTECTED]
Subject: Re: 3.2.2. When's it shipping?
Marc Saegesser wrote:
I bloody hope so.
Here's the plan. Beta 5 was released on Friday, May 11. This beta
cycle is planned for one week. Unless someone reports a show
stopping bug, and so far I haven't seen one, on Friday, May 18th.
I'll call release vote on tomcat-dev. This vote lasts for one week
and every committer gets to vote. A public release vote is open for
one week. So, the best case right now is May 28th.
Not sure if this would be a showstopper however, there is a bug in
jasper/runtime/JspFactoryImpl.java which causes a
NullPointerException.
Fixed in 3.3 but not in 3.2.2
I'm relatively new to tomcat so am not sure of the bug
reporting process
but I sent report of a bug to this list a couple of days ago.
Just tested it with b5 - bug still exists.
tomcat run -security
gives nullPointerException in jasper/runtime/JspFactoryImpl.java
due to no check for pageContext == null in releasePageContext
This is fixed in 3.3
if (pc == null) return
Rgds
Antony
-Original Message-
From: Dave Oxley [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 12:54 PM
To: [EMAIL PROTECTED]
Subject: 3.2.2. When's it shipping?
What is the current state of 3.2.2 development? Is it going to
ship any time
soon?
Dave.
[EMAIL PROTECTED]
Re: Tomcat Interceptors - proof read, anyone?
Hi Filip, Filip Hanik wrote: Hi, I'm currently part of a project that is writing an open source Tomcat book, http://sourceforge.net/projects/tomcatbook. I have written a document that explains the Tomcat interceptor design and how to build your own interceptors. I would be happy to receive feedback on this document from the actual developers, feel free to use it as a how-to, it will be licensed by the GPL Free Documentation license. http://www.gnu.org/copyleft/fdl.html Feel free to send me feedback. thanks in advance. Having just spent a while digging into Tomcat workings to try to understand how to write a realm this would have been a really useful primer. It's a great start. I would like to see more detail on. Contexts. What is their role in Interceptors. For example, it seems that an Interceptor is a singleton but the contextInit() is called for each Context found in server.xml. The authenticate() and authorize() mechanisms need more details. For example, with Tomcat 3.2.? the authorize() mechanism must call req.getRemoteUser() to trigger the authenticate() method. authorize() is called by the contextManager which is more relevant than the isUserInRole() call as the context manager is tomcat core. isUserInRole() is only called if the application calls it. HttpServletRequest.isUserInRole() rather than getUserInRole(). Perhaps you should cover the concept of realms as these are something that people have to deal with. You briefly mention the JDBC realm, the implication being that this is always used. Also for realms _every_ request is authenticated. Some coverage of any synchronisation issues would be useful. Presumably, it is possible to get concurrent requests to an interceptor so synchronisation is necessary. Keep going! Tomcat is sorely lacking good documentation. Rgds -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Re: JSP and SecurityManager [was RE: 3.2.2. When's it shipping?]
Marc Saegesser wrote:
The null check is simple enough and its already been tested in 3.3
so I feel comfortable making the change without a beta. I'll commit
the change today.
Great, thanks!
Another question regarding using the security manager and JSP. If
I use the default tomcat.policy file I can't access any JSP pages
because I get an access denied expcetion getting the line.separator
property. If I add
permission java.util.PropertyPermission line.separator, read;
permission java.util.PropertyPermission file.separator, read;
to tomcat.policy the pages are served correctly. Glenn, is there
any problem adding these two lines to the default policy? Am I
missing something else?
I've tested this but it ONLY works if you add these permissions with no
codeBase. If you add them under the specified codeBase
grant codeBase file:${tomcat.home}/-
They still cause the access exception. I have even tried the following
codeBases
grant codeBase file:c:/-
grant codeBase file:h:/-
with still the same exception. Why doesn't it work??
Rgds
Antony
-Original Message-
From: Antony Bowesman [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 1:50 AM
To: [EMAIL PROTECTED]
Subject: Re: 3.2.2. When's it shipping?
Marc Saegesser wrote:
I bloody hope so.
Here's the plan. Beta 5 was released on Friday, May 11. This beta
cycle is planned for one week. Unless someone reports a show
stopping bug, and so far I haven't seen one, on Friday, May 18th.
I'll call release vote on tomcat-dev. This vote lasts for one week
and every committer gets to vote. A public release vote is open for
one week. So, the best case right now is May 28th.
Not sure if this would be a showstopper however, there is a bug in
jasper/runtime/JspFactoryImpl.java which causes a NullPointerException.
Fixed in 3.3 but not in 3.2.2
I'm relatively new to tomcat so am not sure of the bug reporting process
but I sent report of a bug to this list a couple of days ago.
Just tested it with b5 - bug still exists.
tomcat run -security
gives nullPointerException in jasper/runtime/JspFactoryImpl.java
due to no check for pageContext == null in releasePageContext
This is fixed in 3.3
if (pc == null) return
Rgds
Antony
-Original Message-
From: Dave Oxley [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 12:54 PM
To: [EMAIL PROTECTED]
Subject: 3.2.2. When's it shipping?
What is the current state of 3.2.2 development? Is it going to
ship any time
soon?
Dave.
[EMAIL PROTECTED]
--
Antony Bowesman
Teamware Group
[EMAIL PROTECTED]
tel: +358 9 5128 2562
fax: +358 9 5128 2705
Bug in runtime/JspFactoryImpl.java
Hi,
Excuse the cross post to User/Dev but this problem has been reported by
others in user.
Further to yesterday's message re jasper/tomcat exceptions, it seems
that there is either a bug in the coed generation or the
JspFactoryImpl. If the generated code gets an exception pageContext is
never set so in the finally clause the releasePageContext will be passed
null.
Seems to me the releasePageContext should either check for null or the
generated code should check for null. In the generated number guess
code from the examples there is
---
} catch (Exception ex) {
if (out != null out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null)
pageContext.handlePageException(ex);
} finally {
if (out != null) out.flush();
if (_jspxFactory != null)
_jspxFactory.releasePageContext(pageContext);
}
---
the exception checks for null but not the finally.
Who might be the best person to decide where the fix should go??
This causes big problems if security is turned on because any access
control failure makes this problem occur.
Rgds
--
Antony Bowesman
Teamware Group
[EMAIL PROTECTED]
tel: +358 9 5128 2562
fax: +358 9 5128 2705
Jasper Exception with security and login.jsp
Hi,
Runnong tomcat 3.2.2b4 using a slightly modified form of Hello world
example servlet I get an exception.
I am trying to access a protected resource and it is redirecting to the
login.jsp. Rather than display the login page it results in an
exception. The tomcat log shows an AccessControlException
2001-05-16 02:56:47 - ContextManager: AccessInterceptor: checking
/jsp/security/login/login.jsp
java.lang.ExceptionInInitializerError:
java.security.AccessControlException: access denied
(java.util.PropertyPermission line.separator read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1278)
at java.lang.System.getProperty(System.java:560)
at
org.apache.jasper.runtime.JspWriterImpl.clinit(JspWriterImpl.java:385)
at
org.apache.jasper.runtime.PageContextImpl._createOut(PageContextImpl.java:467)
at
org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:181)
at
org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:149)
at
org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:99)
at
jsp.security.login._0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0._jspService(_0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ej
splogin_jsp_0.java:49)
---
I can give myself access permissions, however, this then causes a
NullPointerException to be displayed in the browser. The 'Root cause'
shows a NullPointerException from
---
java.lang.NullPointerException
at
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:111)
at
jsp.security.login._0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0._jspService(_0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0.java:67)
---
The login.jsp compiled code error line is
} finally {
if (out != null) out.flush();
if (_jspxFactory != null)
_jspxFactory.releasePageContext(pageContext);
}
Is this a known problem with an access control failure during an
authentication request.
Full exception details shown below.
Rgds
Antony
--
Antony Bowesman
Teamware Group
[EMAIL PROTECTED]
tel: +358 9 5128 2562
fax: +358 9 5128 2705
Error: 500
Location: /helloweb/jsp/security/login/login.jsp
Internal Servlet Error:
org.apache.jasper.JasperException
at
org.apache.jasper.servlet.JspServlet$JspCountedServlet.service(JspServlet.java:132)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:282)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:484)
Root cause:
java.lang.NullPointerException
at
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:111)
at
jsp.security.login._0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0._jspService(_0002fjsp_0002fsecurity_0002flogin_0002flogin_0002ejsplogin_jsp_0.java:67)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspCountedServlet.service(JspServlet.java:130)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:282)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853
Re: Session per context question
Craig R. McClanahan wrote: You might want to look at how Tomcat 4.0 addresses the single sign on feature of the servlet spec, which requires user authentication to be global across the web apps in a virtual host (even though the sessions are unique). It's done by maintaining a separate cookie, and a separate collection of available authentications, that intervenes before the usual per-web-app authentication takes place. The class you want to look at is org.apache.catalina.authenticator.SingleSignOn -- plus you will want to examine the other classes in the same package to see how the interactions work. Thanks for comments again! I will take a look. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Session per context question
Hi, Is it correct behaviour for Tomcat to create a different session when a call is made to request.getSession(true) if the context is different. I ask because I have a realm implementation that caches stuff in session relating to authentication. I have two contexts in server.xml and each context defines its own JAAS authentication parameters in web.xml. My realm can then determine if a user is authenticated in a particular context. To do this I am using session in the realm and noticed that each context has a different session. Can someone please explain how Tomcat determines if a session should be created when getSession(true) is called. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Re: Realm implementations
Craig, Thanks for your comments. Craig R. McClanahan wrote: On Fri, 4 May 2001, Antony Bowesman wrote: Hi, In TC 3.x authenticate() method of a realm is called for every request. (I gather this is changed in 4.x). You are correct. Tomcat 4 caches the user Principal object returned by the authenticate() method in the user's session. If the application calls request.isUserInRole() -- or the container is enforcing security constraints -- you may or may not have to go back to the underlying security realm to look up the role information, depending on how you've implemented things. All the current Realm implementations cache the assigned roles along with the user Principal as well. Will you be adding a cachable JAAS Subject or LoginContext into TC4 at any stage, this would move it a little closer to JAAS? I am assuming the RequestImpl is a per HTTP session object. Is this correct? So, each different HTTP session will get a different RequestImpl? Actually, RequestImpl is per *request*, not per *session*. In Tomcat 4, the caching actually happens in the session implementation object (it's in the internal Tomcat part of the API). If so, when HTTP session times out the authentication for that user is lost. Is it possible to keep the HTTP session alive beyond the configured timeout through some keep alive mechanism? I have a logical session that is container independent and there may have been activity on that session that is not related to the HTTP session and so I want to prevent Tomcat from losing the authenticated context. Keeping the session alive (beyond the normal timeout mechanism) would require tweaking the way that Tomcat does session expiration. If you want to keep something alive beyond the lifetime of a session, it sounds like you might need to store the actual objects elsewhere (perhaps in a collection stored as a session context attribute), and maintain references to them as session attributes. You could use HttpSessionBindingListener events to know when session references to the underlying EJB session objects are added or subtracted. This would also let you share an EJB session across multiple HTTP sessions, if that was appropriate for your requirements. Actually, our session is an 'overlying' session. It is not specific to any container and is available in ORB, EJB, WEB or standalone Java app so I guess we will set session timeout to -1 and allow our session to invalidate the HttpSession when it times out. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Re: Realm implementations
Hi Costin, Thanks for your comments. [EMAIL PROTECTED] wrote: Hi Antony, In TC 3.x authenticate() method of a realm is called for every request. Well, yes and no. The BaseInterceptor.authenticate() callback is called on every request ( as it is on Apache and other servers ). The authenticate method of the realm ( that goes to a database or does expensive operations ) should be called once - and the result cached by the module ( either in session, or in a local cache ). We don't do this for the simple realm - but we should. When you talk about caching it in the session I would understand that I need to call req.getSession(true) to ensure a session is available. With form authentication the session is present as the j_* fields are in it but for BASIC there is no session so I will have to create one. I'd rather not cache in the realm as I then have to start worrying about cleaning out old authentications when the HttpSessio expires. A particular case is the authentication module - I expect tomcat to be integrated in different systems, and I doubly the simple realm will be used for anything but development. So there is no point in optimizing it, Agreed. I would rather spend time on specialized modules that can be used in production environment ( and JAAS is probably the most important one, since it could be integrated with PAM and give access to most auth schemes). Yes, it seems Tomcat has to move towards directly supporting JAAS as that is the way J2EE 1.3 and JDK1.4 are moving. Another big priority is a module that delegates the auth to apache - but we have to wait for ajp14 for that. I am implementing a JAAS Realm which authenticates against a back end EJB user realm. I want to avoid this authentication for every request so I have done the following in authenticate() I would cache it inside the session ( if any ) - that's the most common case ( most people use sessions and authentication ). If you want to deal with the 10% special cases you could maintain a local cache to avoid calling the JAAS for each request. In 3.2.2b4 it is changed (same as 3.3) and now returns null if there is no principal. So, it is sufficient to do this in authenticate()? I think that's the correct behavior. I am assuming the RequestImpl is a per HTTP session object. Is this correct? So, each different HTTP session will get a different RequestImpl? No, that's almost impossible. The session is detected long after the request is received ( and you could have cases where you have multiple requests on the same time in the same session - think about a page with images ). You need to use req.getSession(false). (and keep in mind that authentication doesn't require session, even if most of the time they are used togheter !) If so, when HTTP session times out the authentication for that user is lost. Is it possible to keep the HTTP session alive beyond the configured timeout through some keep alive mechanism? I have a logical session that is container independent and there may have been activity on that session that is not related to the HTTP session and so I want to prevent Tomcat from losing the authenticated context. I don't know if it would be a good idea. If you really want to keep the security context longer you should use your own cache, and let the session work as it is supposed to. ( and it shouldn't be very difficult ). Please let us know how this project evolves - I'm very interested in JAAS authentication for tomcat, as an add-on module. Costin Best regards Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Realm implementations
Hi,
In TC 3.x authenticate() method of a realm is called for every request.
(I gather this is changed in 4.x).
I am implementing a JAAS Realm which authenticates against a back end
EJB user realm. I want to avoid this authentication for every request
so I have done the following in authenticate()
authenticate()
{
...
JAASRealmPrincipal principal = new
JAASRealmPrincipal(principalName, lc.getSubject());
// Set principal into Tomcat
req.setUserPrincipal(principal);
...
}
so, now if I call getUserPrincipal() I get my JAAS realm that now sits
inside tomcat's RequestImpl.
In 3.2.2b1 the req.getUserPrincipal() method created a SimplePrincipal
if the principal was null so it never returned null.
In 3.2.2b4 it is changed (same as 3.3) and now returns null if there is
no principal. So, it is sufficient to do this in authenticate()?
if (req.setUserPrincipal(principal) == null)
{
// User not authenticated... do authentication
...
JAASRealmPrincipal principal = new
JAASRealmPrincipal(principalName, lc.getSubject());
// Set principal into Tomcat
req.setUserPrincipal(principal);
...
}
else
// User already authenticated...
return true;
I am assuming the RequestImpl is a per HTTP session object. Is this
correct? So, each different HTTP session will get a different
RequestImpl?
If so, when HTTP session times out the authentication for that user is
lost. Is it possible to keep the HTTP session alive beyond the
configured timeout through some keep alive mechanism? I have a logical
session that is container independent and there may have been activity
on that session that is not related to the HTTP session and so I want to
prevent Tomcat from losing the authenticated context.
How does this fit into TC4?
Best regards
Antony
--
Antony Bowesman
Teamware Group
[EMAIL PROTECTED]
tel: +358 9 5128 2562
fax: +358 9 5128 2705
Relase 3.3 status
Does anyone have schedules for 3.3 release. Current release plan shows 3.3 final release as at Apr 5. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Re: JNDI realm
John Holman wrote: On a different but related topic, I wonder whether it is sensible to assume that user authentication and the determination of roles always use the same mechanisms. For example one might want to use a directory service for authentication but look up roles in a database - or vice versa. Obviously supporting this would require significant refactoring to the Realm implementation in general. I agree that authentication and role population are two distinctly separate issues. It should not be necessary to have to maintain the authentication repository every time new J2EE components and roles get deloyed. Applying roles to the authentication mechanism also makes it harder to reassign roles without forcing users to reauthenticate. Finally I've looked (e.g. in the servlet spec) but can't find a clear statement about what Principal.getName() should return. The current implementation returns the username (ie same as getRemoteUser()). Might the distinguished name be more appropriate when a directory service is used? The whole are of Principals in Web/EJB container is unclear. Servlet spec and EJB spec only allow a single Principal. However, JAAS is currently being pushed into J2EE, both via J2SE, Connector arch. and J2EE 1.3 spec. In this case, it would seem getUserPrincipal is likely to disappear and JAAS Subject be supported instead. However, currently Principal.getName() can return whatever your Principal implementation wants it to return. Rgds -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Plugging realms and JAAS into Tomcat 3.2
Hi, I am trying to find out if it is possible to plug ones own proprietary user realm into Tomcat 3.2. I have JAAS login modules that authenticate against this user realm and populate the JAAS Subject with principals (user names, groups, roles). However, I need to get this JAAS created security context into the Web container's security context, so that, for example, IsUserInRole() can be used to determine Roles from the original user realm and any calls to EJB container will get the security context. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
