According to the JASPIC 1.1 specification (section 3.8.4) a ServerAuthModule should be able to specify the authType by returning it under the key "javax.servlet.http.authType" in the map of the messageInfo object. Tomcat ignores the map and simply sets the authType to "JASPIC". Here is the code form AuthenticatorBase: Map map = state.messageInfo.getMap(); if (map != null && map.containsKey("javax.servlet.http.registerSession")) { register(request, response, principal, "JASPIC", null, null, true, true); } else { register(request, response, principal, "JASPIC", null, null); } In my opinion the hard-coded authType "JASPIC" should be replaced by: map.getOrDefault("javax.servlet.http.authType", "JASPIC")
[Off-topic: Where can I find the text of the JASPIC spec? I don't seem to be able to find it with obvious internet searches.]
(In reply to Robert Rodewald from comment #0) > In my opinion the hard-coded authType "JASPIC" should be replaced by: > map.getOrDefault("javax.servlet.http.authType", "JASPIC") It's tough to tell what Tomcat expects to do with that value (currently "JASPIC"). It's used internally as the request-auth-type and session-auth-type but I don't see any published list of allowed values, there. What would happen if the JASPIC provider returned "SSL" as the auth-type. Is that legal and/or expected?
(In reply to Christopher Schultz from comment #1) > [Off-topic: Where can I find the text of the JASPIC spec? I don't seem to be > able to find it with obvious internet searches.] New sources: https://github.com/eclipse-ee4j/authentication Old sources: https://github.com/javaee/jaspic-spec
I would say that there can't be a list of allowed values for authType as the idea behind the JASPIC ServerAuthModule is to plug in new authTypes, e.g. Bearer-Auth or other SSO modules. Let's suppose you want to plug in two SAMs, fist does Bearer-Auth (e.g. JSON Web Tokens) and the second does BASIC auth. Each module should be able to set the authType accordingly. I suppose that's why the spec does not impose any restrictions on the authType.
(In reply to Robert Rodewald from comment #4) > I suppose that's why the spec does not impose any restrictions on the > authType. Okay. I'm largely ignorant of the details of JASPIC and I'm trying to familiarize myself with it as much as possible. I believe markt has been the primary Tomcat committer working on JASPIC so far. Hopefully I'll finally be able to change that :) If the JASPIC provider can be "trusted" to pass-back a valid/meaningful autoType to the container, then I think it's perfectly reasonable to use that authType for later stages. My only concern is that Tomcat might be looking for authType=JASPIC for certain things. If that's the case we'll need something more complicated in Tomcat to track *both* the indicator that JASPIC is in-use and also what the "effective" authType is via the JASPIC provider (which may be some kind of meta-provider, as you suggest).
As far as Tomcat is concerned, this is an opaque value that is exposed via HttpServletRequest.getAuthType(). It should be fine to use the value provided by the ServerAuthModule.
Created attachment 37427 [details] Patch for Bug 64712 - Adds evaluation of "javax.servlet.http.authType" in messageInfo.getMap() - Removes unnecessary null-Check for map (can not be null as of spec and Tomcat implementation)
Thanks for the patch. Additional comments on bug 64713. Fixed in: - master for 10.0.0-M8 onwards - 9.0.x for 9.0.38 onwards - 8.5.x for 8.5.58 onwards