Define a standardized way to stack auth modules

[glassfishrobot]

According to JASPIC 1.1.2 an authentication context can manage multiple auth modules:

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.

JASPIC 2.1.5.1 gives some more details:

If a context encapsulates multiple authentication modules, the context must embody the control logic to determine which modules of the context are to be invoked and in what order.

Contexts which encapsulate alternative sufficient modules must ensure that the same message values are passed to each invoked alternative of the context. If a context invokes multiple authentication modules, the context must combine the AuthStatus values returned by the invoked authentication modules to establish the AuthStatus value returned by the context to the messaging runtime.

The context implementation must define the logic for combining the returned AuthStatus values.

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)

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jaspic-spec/issues/15
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[glassfishrobot]

@glassfishrobot Commented Reported by arjan_t

[glassfishrobot]

@glassfishrobot Commented monzillo said: 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 is not be available in all JVMs, and I am working to replace (that parser of the JAAS config file syntax)such that this will not detraact from the portability of the authconfigprovder; which is (currently) in the glassfish codebase at:

./security/jaspic-provider-framework/src/main/java/com/sun/jaspic/config/servlet/JAASServletAuthConfigProvider.java

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JASPIC_SPEC-15