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