Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
/
JAASAuthnConfiguration
The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.
The JAAS (Java Authentication and Authorization Service) is a desktop authentication mechanism in Java that has been commonly misappropriated as a server-side technology. A variety of "login module" plugins exist for different password-based technologies. Support is provided for using JAAS as a CredentialValidator for the password authentication login flow.
In V3, JAAS was the primary mechanism for supporting chains of back-end systems in combination with each other. V4 now supports this directly, though in some cases JAAS may still be simpler to configure and certainly remains supported.
A particular advantage of the V4 alternative approach is that the native Kerberos feature is more secure than the Java-supplied JAAS alternative, so deployments combining the JAAS Kerberos module with other back-ends should seriously consider migrating away from that approach.
General Configuration
Configuring JAAS as a back-end in the simplest fashion relies on beans defined via an import in authn/password-authn-config.xml:
Import in authn/password-authn-config.xml
<import resource="jaas-authn-config.xml" />
A few beans are defined in this file to globally configure this back-end by setting some JAAS-related options. With V4, these beans are chiefly used for backward compatibility, and as default settings that can be overridden on specific instances of beans inheriting from shibboleth.JAASValidator defined in authn/password-authn-config.xml in the shibboleth.authn.Password.Validators bean.
In the simple case of JAAS used alone:
Defining use of JAAS in password-authn-config.xml
<util:list id="shibboleth.authn.Password.Validators">
<!-- Default bean uses the settings defined in jaas-authn-config.xml -->
<ref bean="shibboleth.JAASValidator" />
</util:list>
Configuring JAAS as a back-end relies on beans internally that are configured using authn/authn.properties. Generally the defaults are sufficient to rely on a single JAAS configuration named "ShibUserPassAuth".
Older releases included an authn/jaas-authn-config.xml file; this remains supported but is no longer required or provided.
Adding additional beans may be needed in very advanced cases where a higher degree of control is required, and you are welcome to place them within authn/password-authn-config.xml.
In the simple case of JAAS used alone:
Defining use of JAAS in password-authn-config.xml
<util:list id="shibboleth.authn.Password.Validators">
<!-- Default bean uses the settings defined in authn/authn.properties -->
<ref bean="shibboleth.JAASValidator" />
</util:list>
If desired, it's possible to directly configure the various settings within the validator bean instead of or in addition to relying on the defaults. Refer to the JAASCredentialValidator javadoc for a complete summary.
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 bean (V4.0) or the idp.authn.JAAS.loginConfigNames property (V4.1+), 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, but again, this is now a feature natively supported by the IdP independently of JAAS.
Advanced JAAS Usage
More advanced options exist to:
supply the JAAS configuration name(s) dynamically using a function
associate particular JAAS configuration(s) with a set of custom Principal objects to attach to the authentication result
For the former, a Function bean named shibboleth.authn.JAAS.LoginConfigStrategy is reserved. This allows the set of JAAS configurations to be supplied at runtime. The signature of this function is fairly complex:
Signature of shibboleth.authn.JAAS.LoginConfigStrategy Function
The result of the function is a collection of JAAS configuration names together with an optional collection of custom Principal objects (wrapped in a Java Subject) to inject into the 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.
If the information the function would return is static, a bean named shibboleth.authn.JAAS.LoginConfigurations can be defined.
When using either a static or dynamic approach involving custom Principals, the overall login flow generally should advertise all of the possible Principal types in its supportedPrincipals bean property (in general-authn.xml) and the automatic injection of all those Principals is turned off by defining a bean like so:
When using either a static or dynamic approach involving custom Principals, the overall login flow generally should advertise all of the possible Principal types in its idp.authn.Password.supportedPrincipals property and the automatic injection of all those Principals is turned off via the idp.authn.Password.addDefaultPrincipals property.
Reference
The beans defined in authn/jaas-authn-config.xml follow. These are defaults that can be overridden per-validator in whole or in part.
For advanced use, you can inject a function to supply at runtime the information that the previous bean would supply statically
The following are placeholders that may be defined in authn/password-authn-config.xml for advanced control over JAAS configuration use. These are alternatives to the typical cases addressed by simple properties.