...
A bean alias is also defined that instantiates the JAAS back-end action as the "ValidateUsernamePassword" step of the web flow. This must not be changed.
JAAS Configuration
Simple JAAS Usage
JAAS has its own configuration format (see here). By default, the named application configuration used is called "ShibUserPassAuth". This can be changed using the shibboleth.authn.JAAS.LoginConfigNames, or turned into a list of more than one configuration, with each one tried in series until a success. This is equivalent to the JAAS keyword "sufficient". Using separate configurations allows errors to be isolated per-module instead of masked by generic JAAS exceptions.
Advanced JAAS Usage
As of V3.3, an advanced option existsmore advanced options exist to:
- supply the JAAS configuration name(s) dynamically using a function
- associate particular JAAS configuration(s) with a set of custom Principals to attach to the authentication result
For the former, a Function bean called shibboleth.authn.JAAS.LoginConfigStrategy is defined. This allows the set of JAAS configurations to be supplied at runtime. The signature of this function is fairly complex:
Code Block | ||||
---|---|---|---|---|
| ||||
Function<ProfileRequestContext, Collection<Pair<String,Collection<Principal>>>>Subject>>> |
The result of the function is a collection of JAAS configuration names together with an optional collection of custom Principals (wrapped in a Java Subject) to inject into the resulting Subject produced by the login flow. This allows the result to be tailored based on which JAAS configuration actually succeeds, a common need when combining methods. Typically the function's job will be to test the acceptability of the various JAAS options against the incoming request to decide which ones should be tried.When using this approach
If the information the function would return is static, a bean called shibboleth.authn.JAAS.LoginConfigurations can be defined.
When using either a static or dynamic approach involving custom Principals, the surrounding flow generally should carry all of the possible Principal types in its supportedPrincipals
property and the automatic injection of all those Principals is turned off by defining a bean like so:
...
Bean ID | Type | Default | Function |
---|---|---|---|
JAASConfig | String | %{idp.home}/conf/authn/jaas.config | Defines a Spring Resource containing the JAAS config. Normally this just points to a file in the filesystem |
shibboleth.authn.JAAS.JAASConfigURI | java.net.URI | JAASConfig.URI | Defines the URI object containing the JAAS configuration |
shibboleth.authn.JAAS.LoginConfigNames java,util.List<String>LoginConfigNames | Collection<String> | [ "ShibUserPassAuth" ] | List Simple list of JAAS application configuration names to use |
shibboleth.authn.JAAS.LoginConfigurations3.3 | Collection<Pair<String,Subject>> | Static list of JAAS application configuation names along with mappings to custom Principals | |
shibboleth.authn.JAAS.LoginConfigStrategy3.3 | Function (see above) | For advanced use, you can inject a function to supply at runtime the collection of JAAS application configuration names to use, together with a mapping to any custom Principals to add into the result.information that the previous bean would supply statically |
V2 Compatibility
JAAS configuration is independent of the IdP and is therefore identical with the use of JAAS in the V2 UsernamePassword handler. By default this configuration is placed in authn/jaas.config and the legacy-matching "ShibUserPassAuth" login configuration name is used (though this can be changed).
...