Mark Thomas-2 wrote
> As I thought about this some more, I realised that there is nothing in
> the Servlet Container profile in the JASPIC spec (that I have been able
> to find) about when AuthConfigProvider registration takes place. This
> means that AuthConfigProvider registrations and de-registrations could
> take place while the web application is running.
It's a good point indeed. In practice it always seems to be either a
ServletContainerInitializer or a ServletContextListener, or of course via a
server proprietary method (outside the application).
I'm not entirely sure what the use case was for having this flexibility.
I'll try to see if I can get a clarification from Ron about this. I wonder
how many implementations even support registrations and de-registrations at
arbitrary moments.
Mark Thomas-2 wrote
> - have authenticate() check (i.e. on every request) for a JASPIC config
> and use it if present
> - cache what I can (for speed) and use a RegistrationListener to track
> updates
That should indeed be the approach.
What the RI roughly does is from its embedded Tomcat in
AuthenticatorBase#invoke it calls an adapter:
com.sun.web.security.RealmAdapter#invokeAuthenticateDelegate
That contains code like the following (simplified):
ServerAuthConfig serverAuthConfig = null;
if (helper != null) {
serverAuthConfig = helper.getServerAuthConfig();
}
if (serverAuthConfig != null) {
// JSR 196 is enabled for this application. Call it.
result = validate(request, response, config, authenticator,
calledFromAuthenticate);
} else {
// JSR 196 is not enabled for this application. Use the current
authenticator
result = ((AuthenticatorBase) authenticator).authenticate(request,
response, config);
}
The "helper" variable is set outside the request call, so it functions as a
very quick switch.
getServerAuthConfig() essentially does the following:
AuthConfig authConfig = listener.getConfig();
if (authConfig == null) {
authConfig = factory.getConfigProvider(layer, appCtxt, listener);
listener.setConfig(authConfig);
}
return authConfig;
Where listener and the AuthConfig it holds are just instance variables. One
subtle thing to notice is that when the listener is called to track an
update the config it holds is null'ed instead of actually being updated at
that point.
The actual implementation is a bit more hairy but in broad lines it boils
down to the above, see:
com.sun.enterprise.security.jmac.config.ConfigHelper#getServerAuthConfig
Hope this helps.
Kind regards,
Arjan Tijms
--
View this message in context:
http://tomcat.10.x6.nabble.com/JASPIC-progress-tp5046266p5046307.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
