What future plans are for Tomcat authentication
Hello, I am asking this questions on Tomcat Users mail list in order to find answers about how users and developers of Tomcat see the topic I am discribing. In jakarta EE there is work for Jakarta Authentication (that reached 3.1 in development) formely JASPIC which Tomcat has implementation for it and Jakarta Authorization that I don's see Tomcat has implementation for it (maybe future plans). Tomcat does at this point authentication / authorization as stated by Jakarta Servlet specification and Jakarta Authentication with custom mechanism provided by packages org.apache.catalina.authentication and org.apache.catalina.realm. The standards Jakarta Authentication + Jakarta Authorization seems a different approach than Jakarta Servlet. I found in Jakarta Authentication standart the following statement in Chapter 1.1.2 Authentication Contexts: An authentication context is responsible for constructing, initializing, and coordinating the invocation of one or more encapsulated authentication modules. If the context implementation supports the configuration of multiple authentication modules within a context (for example, as sufficient alternatives), the context coordinates the invocation of the authentication modules on behalf of both the message processing runtime and the authentication modules but later I found this statement in Chapter 1.1.7 Authentication Exchanges and State This version of this specification does not define the interfaces by which runtimes present correlation facilities to authentication modules in other words somebody is thinking about correlating multiple authentication modules on the same user request but standardisation effort did not reach detail phase on this problem. I was forced on a project I am working to combine SPNEGO authenticator (from Tomcat) with FORM authenticator. I found that it is not easy to to. There were a lot of scenarios to be taken into consideration if one is willing to implement this combination. I belive that other combinations are interesting like HTTP DIGEST + SPNEGO + FORM SSL + SPNEGO + HTTP DIGEST + FORM ETC. These combinations are not easy to implement since they involve a HTTP CHALLENGE that the browser + user may not be able to fullfill and you may be forced running into a final backup solution with FORM authenticator without any challange. As I see in Tomcat if you have a Jakarta Authentication provider configured then that provider becomes the first option for authentication and any web.xml element becomes ignored (any traditional Jakarta Servlet method). I see here a conflict that has been introduced by Jakarta Authentication and jakarta Servlet specifications. Questions are: 1. Is Jakarta Authentication specification going to replace the authentication part of Jakarta Servlet specification? 2. Are current authenticatiors from Tomcat (FORM, SPNEGO, SSL, HTTP DIGEST, HTTP BASIC, SSO) going to be implemented as Jakarta Authentication providers in future versions of Tomcat? 3. Is any effort to introduce in Jakarta standards + Tomcat an authentcator of type 2FA? Thanks, Marian Mircea Butmalai
I can't find how to stop TOMCAT during INITIALIZATION phase
Hello, I have searched inside TOMCAT (for the moment version 10.1.x but seems to be present in all versions) how to stop TOMCAT during INITIALIZATION phase and I can't find any method how to do it. Tomcat seems to have 3 ways to stop it: 1. Sending SHUTDOWN command over the control port socket (the most traditional one) 2. Sending SIGTERM signal to java process because I see that org/apache/catalina/startup/Catalina.java registers a java shutdown hook that basically stop's the server container 3. calling manager jmxproxy via HTTP and invoke stop on server container The problem of solution 1 and 2 is that these ways are available only after initialization of toncat is complete (the second one I never been able to use it but seems to me from code that is available only after initialization when is logged the message that says " INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [26102] milliseconds"). Solution 3 is also available after initialization because manager web application is scheduled to startup after our web application and tomcat seems to pause http requests until initialization is complete. So I am not able to send any signal to shutdown tomcat during this initialization phase or I can't figure out how to do it. The reason we want this is as follows: Our application consists of a TOMCAT instantance that run's inside our WAR web application together with manager, host manager and default ROOT tomcat delivered web applications (the root application is modified to redirect to our web application). Our war application takes aprox 20 - 30 seconds to startup and the majority of time is spent inside few servlet context listeners and stops quickly in gracefull manner. We also have some custom made wrapper bash scripts that start / stop tomcat like this: - the start script delegates the start procedure to bin/catalina.sh tomcat script with run parameter (after setting environment and other things) - the stop script delegates the stop procedure to bin/shutdown.sh tomcat script (after setting environment and other things) Due to the fact that initialization takes a visible long time, it is possible to need to stop tomcat in this phase for the following reasons: 1. the administrator wishes to interrupt this initialization 2. the operating system is shutdown gracefully during initialization of tomcat and tomcat, like any process, need to start a shutdown during any phase Our question is: 1. It is possible to stop tomcat during initialization phase? 2. If yes how and if not are any plans to implement it in future versions? It seems to me that my solutions for now are: 1. sending SIGKILL signal to tomcat (this is very risky to me because stopping like this in the middle of something may corrupt data - but this situation is any way possible so I have to handle it) 2. wait for tomcat initilization procedure to finish and then trigger the shutdown since we can do something in our wrapper scripts Do you see any other possible solutions? Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
