|<< Back to previous view|
[JASPIC_SPEC-15] Define a standardized way to stack auth modules Created: 27/Mar/13 Updated: 05/Apr/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Tags:||stacking jaas pam|
|Participants:||arjan tijms and monzillo|
According to JASPIC 1.1.2 an authentication context can manage multiple auth modules:
JASPIC 220.127.116.11 gives some more details:
This gives a framework to work with, but it does not specify the exact semantics of how the handling of multiple modules (stacking) should take place. Each implementation is free to do this largely in an implementation specific way. This makes it hard to cary over a configuration of modules from one server to the other.
In order to improve portability and as a possible precursor to a standardized declarative way to configure auth modules, I would like to request to standardize a specific way of handling multiple auth modules and demanding the runtime to make an authentication context available that implements this.
Possibly the JAAS/PAM semantics of Required, Requisite, Sufficient and Optional could be formally specified for use with JASPIC. (the existing specification already hints to supporting the Sufficient semantics)
|Comment by monzillo [ 05/Apr/13 01:52 PM ]|
When the expert group discussed stacking (auth modules), we decided that stacking was a configuration specific behavior, that might only be supported by some authconfig systems/providers, and that might be done differently by any such systems; thus the existing language in the spec (for example in section 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."
that said, there are various reasons why we should make it easy for jaspic users to work with an existing and portable authconfigprovider (e.g., so that they can focus on auth module development), and a JAAS style configuration provider (that supports stacking) has been available in Glassfish for some time.
That said, I need to a better job of improving the visibility, availability, and portability of that provider; which supports stacking according to the JAAS model of REQUIRED,REQUISITE, etc. At this time it does very little in terms of "coordinating" calls to handle the CallerPrincipalCallback originating form multiple modules within the stack. It currently depends on com.sun.security.auth.login.ConfigFile, which