What future plans are for Tomcat authentication

[Mircea Butmalai <mi...@radcom.ro>]

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

Re: What future plans are for Tomcat authentication

[Mark Thomas <ma...@apache.org>]

On 20/03/2024 06:22, Mircea Butmalai wrote:

<snip/>

> Questions are:
> 
>    1.  Is Jakarta Authentication specification going to replace the authentication part of Jakarta Servlet specification?

Unlikely.

>    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?

This has been discussed in the past but there is little motivation to do 
so as there are no obvious benefits and possible negative performance 
impacts.

>    3.  Is any effort to introduce in Jakarta standards + Tomcat an authentcator of type 2FA?

No plans I am aware of.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org