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 <login-config> 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
