Apparently, the current approach (per the code in authenticatorConfig() method of org.apache.catalina.startup.ContextConfig class) is to restrict only one authenticator per pipeline. While this may seem logical, practical requirements may want to add multiple authenticators and the actual authentication may be handled by either one of them or multiple of them, depending on the requirements. For example, if you allow a certificate authenticator (say custom) and a BASIC authenticator in the pipeline, the certificate authenticator may apply only for certain URIs, and the BASIC authenticator may apply for some other URIs. Another example is that - in a specific installation - both of them might apply to any given request - meaning that the request has to have a good certificate as well as a good username/password. This philosophy can be seen similar to the philosophy of having multiple valves in the pipeline.
The enhancement as described is not possible since the servlet spec only allows a single authenticator to be configured per web-app. What would be possible would be a realm that uses one method by default and falls back to a second if the first fails.
(In reply to comment #1) > The enhancement as described is not possible since the servlet spec only allows > a single authenticator to be configured per web-app. > > What would be possible would be a realm that uses one method by default and > falls back to a second if the first fails. > I am not sure if you are referring to the login-config entries in a web-app, or to the way we add valves (which at the same time can be implemntors of Authenticator). Either way, I do not see Servlet spec having any constraint. Though the actual result is implementation specific, I noticed that the Schema itself does not prevent a web-app from having multiple login-config entries. Please clarify.
SRV.13.2. states that more than one login-config is an error.
It seems that two things are discussed here in one plase: 1 multiple authenitcators (this is no comment to hereto) 2 realm chaining 2 is often quite necessary and not (yet?) done in Tomcat. configurable realm chaining would be the real answer to "What would be possible would be a realm that uses one method by default and falls back to a second if the first fails." Writing such realm is a workaround as e.g. de.a_weinert.realm.ADweRealm (l) falls in this category. It authenticates against an Active Directory using all direct and (multilevel) indirect groups as roles. If the user is not in the AD (company member) it will fall back to a simple LDAP/JNDI (for e.g. guest members). Of course, en lieu of making ADweRealm falling back to a supplementary LDAP it would be much better to have it being chained (by Tomcat config) to any next realm. URLs (javadoc, source, background): http://www.a-weinert.de/java/docs/aWeinertBib/de/a_weinert/realm/ADweRealm.htm http://www.a-weinert.de/java/docs/aWeinertBib/de/a_weinert/doc-files/ADweRealm.java http://www.a-weinert.de/weinert/pub/tomcat-win-ad.pdf (German)
(In reply to comment #3) > SRV.13.2. states that more than one login-config is an error. > Well...IMHO, we are getting hung-up on the semantics of multiple authenticators Vs multiple login-configs. I would like to think of these two as two distinct, though connected, topics. I can understand why multiple login-config entries should result in an error - as the login-config itself does not define how multiple entries can be chained and what protocol they need to use when each entry in the chain is invoked. A contrast will be the JAAS model, where the contract is defined and clear. However, we can treat the chaining of multiple authenticators differently - as authenticators are an implementation of Tomcat, and it can define the contract and expected behavior. Also, please note that multiple authenticators are configured not because of multiple login-config entries, but because of entries in the context.xml , server.xml, or both. These are configurations are defined by Tomcat and thus it has control on what can done there.
(In reply to comment #4) It is possible that Realm chaining can address the requirement - however, I feel that the current authenticate methods in the Realm interface are too restrictive. They need to mirror the support we have for the invoke method in the Valve interface (that is make the request and response objects available). The reason being that we need to be able to extend authentication beyond username/credential/certificate. Some authentication schemes may require more data than just these. Making the request object available will alleviate the problem. Also, the response behavior after a successful/failed authentication may need to be tailored. This may require that the response object also be made available. Making the request and response objects available to the realm authenticators will solve a large set of problems.
Most of the concerns here would be addressed by implementing the jaspi spec which is likely to be required for java ee 6 compliance. In particular it supports non-web-xml vendor specific configuration of authentication modules, multiple authentication modules, and supplying the request and response message objects to the authentication modules. If no one beats me to it I'm likely to look into this later this summer.
(In reply to comment #7) > Most of the concerns here would be addressed by implementing the jaspi spec > which is likely to be required for java ee 6 compliance. In particular it > supports non-web-xml vendor specific configuration of authentication modules, > multiple authentication modules, and supplying the request and response message > objects to the authentication modules. > > If no one beats me to it I'm likely to look into this later this summer. > Yes, I agree.
This was implemented for TomEE which is available from the Apache OpenEJB project.