[JASPIC_SPEC-15] Define a standardized way to stack auth modules Created: 27/Mar/13  Updated: 05/Apr/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jaas, pam, stacking

 Description   

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)



 Comments   
Comment by monzillo [ 05/Apr/13 ]

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

Generated at Wed Jul 01 02:03:57 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.