JAAS Authentication
JAAS is a Java standard authentication and authorization API. JAAS is configured via externalized plain text configuration file. Using JAAS with CAS allows modification of the authentication process without having to rebuild and redeploy CAS and allows for PAM-style multi-module “stacked” authentication.
Configuration
JAAS components are provided in the CAS core module and require no additional dependencies to use. The JAAS handler delegates to the built-in JAAS subsystem to perform authentication according to the directives in the JAAS config file.
The following settings and properties are available from the CAS configuration catalog:
cas.authn.jaas[0].password-encoder.encoding-algorithm=
The encoding algorithm to use such as
|
cas.authn.jaas[0].password-encoder.type=NONE
Define the password encoder type to use.
Type may be specified as blank or
|
cas.authn.jaas[0].realm=
JAAS realm to use.
|
cas.authn.jaas[0].password-policy.groovy.location=
The location of the resource. Resources can be URLS, or files found either on the classpath or outside somewhere in the file system. In the event the configured resource is a Groovy script, specially if the script set to reload on changes, you may need to adjust the total number ofinotify instances.
On Linux, you may need to add the following line to /etc/sysctl.conf:
fs.inotify.max_user_instances = 256.
You can check the current value via cat /proc/sys/fs/inotify/max_user_instances.
|
cas.authn.jaas[0].principal-transformation.groovy.location=
The location of the resource. Resources can be URLS, or files found either on the classpath or outside somewhere in the file system. In the event the configured resource is a Groovy script, specially if the script set to reload on changes, you may need to adjust the total number ofinotify instances.
On Linux, you may need to add the following line to /etc/sysctl.conf:
fs.inotify.max_user_instances = 256.
You can check the current value via cat /proc/sys/fs/inotify/max_user_instances.
|
cas.authn.jaas[0].principal.principal-transformation.groovy.location=
The location of the resource. Resources can be URLS, or files found either on the classpath or outside somewhere in the file system. In the event the configured resource is a Groovy script, specially if the script set to reload on changes, you may need to adjust the total number ofinotify instances.
On Linux, you may need to add the following line to /etc/sysctl.conf:
fs.inotify.max_user_instances = 256.
You can check the current value via cat /proc/sys/fs/inotify/max_user_instances.
|
cas.authn.jaas=
Collection of settings related to JAAS authentication. These settings are required to be indexed (i.e. jaas[0].xyz).
|
cas.authn.jaas[0].credential-criteria=
A number of authentication handlers are allowed to determine whether they can operate on the provided credential and as such lend themselves to be tried and tested during the authentication handler selection phase. The credential criteria may be one of the following options:
|
cas.authn.jaas[0].kerberos-kdc-system-property=
Typically, the default realm and the KDC for that realm are indicated in the Kerberos krb5.conf file is also provided from which the additional information required for cross-realm authentication
may be obtained.
If you set values for these properties, then they override the default realm and KDC values specified
in krb5.conf (if such a file is found). The krb5.conf file is still consulted if values for items
other than the default realm and KDC are needed. If no krb5.conf file is found,
then the default values used for these items are implementation-specific.
|
cas.authn.jaas[0].kerberos-realm-system-property=
Typically, the default realm and the KDC for that realm are indicated in the Kerberos krb5.conf file is also provided from which the additional information required for cross-realm authentication
may be obtained.
If you set values for these properties, then they override the default realm and KDC values specified
in krb5.conf (if such a file is found). The krb5.conf file is still consulted if values for items
other than the default realm and KDC are needed. If no krb5.conf file is found,
then the default values used for these items are implementation-specific.
|
cas.authn.jaas[0].login-config-type=
Typically set to
|
cas.authn.jaas[0].login-configuration-file=
Path to the location of configuration file (i.e. jaas.conf) that contains the realms and login modules.
|
cas.authn.jaas[0].name=
Name of the authentication handler.
|
cas.authn.jaas[0].order=MAX_VALUE
Order of the authentication handler in the chain.
|
cas.authn.jaas[0].password-encoder.character-encoding=UTF-8
The encoding algorithm to use such as 'UTF-8'.
Relevant when the type used is
|
cas.authn.jaas[0].password-encoder.hash-length=16
When used by
|
cas.authn.jaas[0].password-encoder.secret=
Secret to use with
|
cas.authn.jaas[0].password-encoder.strength=16
Strength or number of iterations to use for password hashing.
Usually relevant when dealing with
|
cas.authn.jaas[0].password-policy.account-state-handling-enabled=true
Indicates whether account state handling should be enabled to process warnings or errors reported back from the authentication response, produced by the source.
|
cas.authn.jaas[0].password-policy.display-warning-on-match=true
Indicates if warning should be displayed, when the ldap attribute value
matches the
|
cas.authn.jaas[0].password-policy.enabled=true
Whether password policy should be enabled.
|
cas.authn.jaas[0].password-policy.login-failures=5
When dealing with FreeIPA, indicates the number of allows login failures.
|
cas.authn.jaas[0].password-policy.policy-attributes=
Key-value structure (Map) that indicates a list of boolean attributes as keys.
If either attribute value is true, indicating an account state is flagged,
the corresponding error can be thrown.
Example
|
cas.authn.jaas[0].password-policy.strategy=DEFAULT
Decide how authentication should handle password policy changes. Available values are as follows:
|
cas.authn.jaas[0].password-policy.warn-all=
Always display the password expiration warning regardless.
|
cas.authn.jaas[0].password-policy.warning-attribute-name=
Used by an account state handling policy that only calculates account warnings in case the entry carries this attribute.
|
cas.authn.jaas[0].password-policy.warning-attribute-value=
Used by an account state handling policy that only calculates account warnings
in case the entry carries an attribute
|
cas.authn.jaas[0].password-policy.warning-days=30
This is used to calculate a warning period to see if account expiry is within the calculated window.
|
cas.authn.jaas[0].principal-transformation.blocking-pattern=
A regular expression that will be used against the username to match for blocking/forbidden values. If a match is found, an exception will be thrown and principal transformation will fail.
|
cas.authn.jaas[0].principal-transformation.case-conversion=NONE
Indicate whether the principal identifier should be transformed into upper-case, lower-case, etc. Available values are as follows:
|
cas.authn.jaas[0].principal-transformation.pattern=
A regular expression that will be used against the provided username for username extractions. On a successful match, the first matched group in the pattern will be used as the extracted username.
|
cas.authn.jaas[0].principal-transformation.prefix=
Prefix to add to the principal id prior to authentication.
|
cas.authn.jaas[0].principal-transformation.suffix=
Suffix to add to the principal id prior to authentication.
|
cas.authn.jaas[0].principal.active-attribute-repository-ids=
Activated attribute repository identifiers that should be used for fetching attributes if attribute resolution is enabled. The list here may include identifiers separated by comma.
|
cas.authn.jaas[0].principal.attribute-resolution-enabled=UNDEFINED
Whether attribute repositories should be contacted to fetch person attributes. Defaults to true if not set.
|
cas.authn.jaas[0].principal.principal-attribute=
Attribute name to use to indicate the identifier of the principal constructed. If the attribute is blank or has no values, the default principal id will be used determined by the underlying authentication engine. The principal id attribute usually is removed from the collection of attributes collected, though this behavior depends on the schematics of the underlying authentication strategy.
|
cas.authn.jaas[0].principal.principal-resolution-conflict-strategy=last
In the event that the principal resolution engine resolves
more than one principal, (specially if such principals in the chain
have different identifiers), this setting determines strategy by which
the principal id would be chosen from the chain.
Accepted values are:
|
cas.authn.jaas[0].principal.principal-resolution-failure-fatal=UNDEFINED
When true, throws an error back indicating that principal resolution has failed and no principal can be found based on the authentication requirements. Otherwise, logs the condition as an error without raising a catastrophic error.
|
cas.authn.jaas[0].principal.principal-transformation.blocking-pattern=
A regular expression that will be used against the username to match for blocking/forbidden values. If a match is found, an exception will be thrown and principal transformation will fail.
|
cas.authn.jaas[0].principal.principal-transformation.case-conversion=NONE
Indicate whether the principal identifier should be transformed into upper-case, lower-case, etc. Available values are as follows:
|
cas.authn.jaas[0].principal.principal-transformation.pattern=
A regular expression that will be used against the provided username for username extractions. On a successful match, the first matched group in the pattern will be used as the extracted username.
|
cas.authn.jaas[0].principal.principal-transformation.prefix=
Prefix to add to the principal id prior to authentication.
|
cas.authn.jaas[0].principal.principal-transformation.suffix=
Suffix to add to the principal id prior to authentication.
|
cas.authn.jaas[0].principal.return-null=UNDEFINED
Return a null principal object if no attributes can be found for the principal.
|
cas.authn.jaas[0].principal.use-existing-principal-id=UNDEFINED
Uses an existing principal id that may have already been established in order to run person directory queries. This is generally useful in situations where authentication is delegated to an external identity provider and a principal is first established to then query an attribute source.
|
cas.authn.jaas[0].state=ACTIVE
Define the scope and state of this authentication handler and the lifecycle in which it can be invoked or activated.
|
If you need to design your own password encoding scheme where the type is specified as a fully qualified Java class name, the structure of the class would be similar to the following:
1
2
3
4
5
6
7
8
9
10
11
package org.example.cas;
import org.springframework.security.crypto.codec.*;
import org.springframework.security.crypto.password.*;
public class MyEncoder extends AbstractPasswordEncoder {
@Override
protected byte[] encode(CharSequence rawPassword, byte[] salt) {
return ...
}
}
If you need to design your own password encoding scheme where the type is specified as a path to a Groovy script, the structure of the script would be similar to the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import java.util.*
byte[] run(final Object... args) {
def rawPassword = args[0]
def generatedSalt = args[1]
def logger = args[2]
def casApplicationContext = args[3]
logger.debug("Encoding password...")
return ...
}
Boolean matches(final Object... args) {
def rawPassword = args[0]
def encodedPassword = args[1]
def logger = args[2]
def casApplicationContext = args[3]
logger.debug("Does match or not ?");
return ...
Password Policy Strategies
If the password policy strategy is to be handed off to a Groovy script, the outline of the script may be as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import java.util.*
import org.ldaptive.auth.*
import org.apereo.cas.*
import org.apereo.cas.authentication.*
import org.apereo.cas.authentication.support.*
List<MessageDescriptor> run(final Object... args) {
def response = args[0]
def configuration = args[1];
def logger = args[2]
def applicationContext = args[3]
logger.info("Handling password policy [{}] via ${configuration.getAccountStateHandler()}", response)
def accountStateHandler = configuration.getAccountStateHandler()
return accountStateHandler.handle(response, configuration)
}
The parameters passed are as follows:
| Parameter | Description |
|---|---|
response |
The LDAP authentication response of type org.ldaptive.auth.AuthenticationResponse |
configuration |
The LDAP password policy configuration carrying the account state handler defined. |
logger |
The object responsible for issuing log messages such as logger.info(...). |
Authentication handlers that generally deal with username-password credentials can be configured to transform the user id prior to executing the authentication sequence. Each authentication strategy in CAS provides settings to properly transform the principal. Refer to the relevant settings for the authentication strategy at hand to learn more.
Authentication handlers as part of principal transformation may also be provided a path to a Groovy script to transform the provided username. The outline of the script may take on the following form:
1
2
3
4
5
String run(final Object... args) {
def providedUsername = args[0]
def logger = args[1]
return providedUsername.concat("SomethingElse")
}
Certain authentication handlers are allowed to determine whether they can operate on the provided credential and as such lend themselves to be tried and tested during the authentication handler selection phase. The credential criteria may be one of the following options:
- A regular expression pattern that is tested against the credential identifier.
- A fully qualified class name of your own design that looks similar to the below example:
1
2
3
4
5
6
7
8
9
import java.util.function.Predicate;
import org.apereo.cas.authentication.Credential;
public class PredicateExample implements Predicate<Credential> {
@Override
public boolean test(final Credential credential) {
// Examine the credential and return true/false
}
}
- Path to an external Groovy script that looks similar to the below example:
1
2
3
4
5
6
7
8
9
import org.apereo.cas.authentication.Credential
import java.util.function.Predicate
class PredicateExample implements Predicate<Credential> {
@Override
boolean test(final Credential credential) {
// test and return result
}
}
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
Password Policy
JAAS authentication components have limited support for detecting account status and password policy settings defined via CAS settings.
The following settings and properties are available from the CAS configuration catalog:
cas.authn.jaas[0].password-policy.groovy.location=
The location of the resource. Resources can be URLS, or files found either on the classpath or outside somewhere in the file system. In the event the configured resource is a Groovy script, specially if the script set to reload on changes, you may need to adjust the total number ofinotify instances.
On Linux, you may need to add the following line to /etc/sysctl.conf:
fs.inotify.max_user_instances = 256.
You can check the current value via cat /proc/sys/fs/inotify/max_user_instances.
|
cas.authn.jaas[0].password-policy.account-state-handling-enabled=true
Indicates whether account state handling should be enabled to process warnings or errors reported back from the authentication response, produced by the source.
|
cas.authn.jaas[0].password-policy.display-warning-on-match=true
Indicates if warning should be displayed, when the ldap attribute value
matches the
|
cas.authn.jaas[0].password-policy.enabled=true
Whether password policy should be enabled.
|
cas.authn.jaas[0].password-policy.login-failures=5
When dealing with FreeIPA, indicates the number of allows login failures.
|
cas.authn.jaas[0].password-policy.policy-attributes=
Key-value structure (Map) that indicates a list of boolean attributes as keys.
If either attribute value is true, indicating an account state is flagged,
the corresponding error can be thrown.
Example
|
cas.authn.jaas[0].password-policy.strategy=DEFAULT
Decide how authentication should handle password policy changes. Available values are as follows:
|
cas.authn.jaas[0].password-policy.warn-all=
Always display the password expiration warning regardless.
|
cas.authn.jaas[0].password-policy.warning-attribute-name=
Used by an account state handling policy that only calculates account warnings in case the entry carries this attribute.
|
cas.authn.jaas[0].password-policy.warning-attribute-value=
Used by an account state handling policy that only calculates account warnings
in case the entry carries an attribute
|
cas.authn.jaas[0].password-policy.warning-days=30
This is used to calculate a warning period to see if account expiry is within the calculated window.
|
Password Policy Strategies
If the password policy strategy is to be handed off to a Groovy script, the outline of the script may be as follows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import java.util.*
import org.ldaptive.auth.*
import org.apereo.cas.*
import org.apereo.cas.authentication.*
import org.apereo.cas.authentication.support.*
List<MessageDescriptor> run(final Object... args) {
def response = args[0]
def configuration = args[1];
def logger = args[2]
def applicationContext = args[3]
logger.info("Handling password policy [{}] via ${configuration.getAccountStateHandler()}", response)
def accountStateHandler = configuration.getAccountStateHandler()
return accountStateHandler.handle(response, configuration)
}
The parameters passed are as follows:
| Parameter | Description |
|---|---|
response |
The LDAP authentication response of type org.ldaptive.auth.AuthenticationResponse |
configuration |
The LDAP password policy configuration carrying the account state handler defined. |
logger |
The object responsible for issuing log messages such as logger.info(...). |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
JAAS Configuration File
The default JAAS configuration file is located at $JRE_HOME/lib/security/java.security. It’s important to note
that JAAS configuration applies to the entire JVM. The path to the JAAS configuration file in effect may be altered
by setting the java.security.auth.login.config system property to an alternate file path (i.e. file:/etc/cas/config/jaas.config).
A sample JAAS configuration file is provided for reference.
1
2
3
4
5
6
7
/**
* Login Configuration for JAAS with the realm name defined as CAS.
*/
CAS {
org.sample.jaas.login.SampleLoginModule sufficient
debug=FALSE;
};
Login Modules
The following login modules are available with CAS:
JNDI
The module prompts for a username and password and then verifies the password against the password stored in a directory service configured under JNDI.
1
2
3
4
5
6
CAS {
com.sun.security.auth.module.JndiLoginModule sufficient
user.provider.url=name_service_url
group.provider.url=name_service_url
debug=FALSE;
};
The value of name_service_url specifies the directory service and path where this module can access the relevant user and group information. Because this module only performs one-level searches to find the relevant user information, the URL must point to a directory one level above where the user and group information is stored in the directory service.
For a list of all other options and more comprehensive documentation, please see this guide for more info.
Kerberos
This module authenticates users using Kerberos protocols. The configuration entry for module has several options that control the
authentication process and additions to the Subject’s private credential set. Irrespective of these options, the Subject’s principal set and private credentials set are updated only when commit is called. When commit is called, the KerberosPrincipal is added to the Subject’s principal set and KerberosTicket is added to the Subject’s private credentials.
If the configuration entry for module has the option storeKey set to true, then KerberosKey will also be added to
the subject’s private credentials. KerberosKey, the principal’s key will be either obtained from the keytab or derived from user’s password.
This module also recognizes the doNotPrompt option. If set to true the user will not be prompted for the password.
The user can specify the location of the ticket cache by using the option ticketCache in the configuration entry. The user can specify the keytab location by using the option keyTab in the configuration entry.
The principal name can be specified in the configuration entry by using the option principal. The principal name can
either be a simple user name or a service name such as host/mission.eng.sun.com. The principal can also be set using
the system property sun.security.krb5.principal. This property is checked during login. If this property is not set,
then the principal name from the configuration is used. In the case where the principal property is not set and the principal
entry also does not exist, the user is prompted for the name. When this property of entry is set, and useTicketCache is set to
true, only TGT belonging to this principal is used.
Note that a valid krb5.conf must be supplied to the JVM for Kerberos auth via setting -Djava.security.krb5.conf=/etc/krb5.conf.
1
2
3
4
5
6
7
8
9
10
11
12
13
CAS {
com.sun.security.auth.module.Krb5LoginModule sufficient
refreshKrb5Config=TRUE/FALSE
useTicketCache=TRUE/FALSE
ticketCache=...
renewTGT=TRUE/FALSE
useKeyTab=TRUE/FALSE
doNotPrompt=TRUE/FALSE
keyTab=TRUE/FALSE
storeKey=TRUE/FALSE
principal=...
debug=FALSE;
};
For a list of all other options and more comprehensive documentation, please see this guide for more info.
UNIX
This module imports a user’s Unix Principal information (UnixPrincipal, UnixNumericUserPrincipal, and UnixNumericGroupPrincipal) and associates them with the current Subject.
1
2
3
4
CAS {
com.sun.security.auth.module.UnixLoginModule sufficient
debug=FALSE;
};
For a list of all other options and more comprehensive documentation, please see this guide for more info.
NT
This module renders a user’s NT security information as some number of Principals and associates them with a Subject.
1
2
3
4
5
CAS {
com.sun.security.auth.module.NTLoginModule sufficient
debugNative=TRUE
debug=FALSE;
};
For a list of all other options and more comprehensive documentation, please see this guide for more info.
LDAP
This module performs LDAP-based authentication. A username and password is verified against the corresponding user credentials stored in an LDAP directory. If authentication is successful then a new LdapPrincipal is created using the user’s distinguished name and a new UserPrincipal is created using the user’s username and both are associated with the current Subject.
For a list of all other options and more comprehensive documentation, please see this guide for more info.
This module operates in one of three modes. A mode is selected by specifying a particular set of options:
Search First
In search-first mode, the LDAP directory is searched to determine the user’s distinguished name and then authentication is attempted. An (anonymous) search is performed using the supplied username in conjunction with a specified search filter. If successful then authentication is attempted using the user’s distinguished name and the supplied password. To enable this mode, set the userFilter option and omit the authIdentity option. Use search-first mode when the user’s distinguished name is not known in advance.
The example below identifies the LDAP server and specifies that users’ entries be located by their uid and objectClass attributes. It also specifies that an identity based on the user’s employeeNumber attribute should be created.
1
2
3
4
5
6
7
CAS {
com.sun.security.auth.module.LdapLoginModule REQUIRED
userProvider="ldap://ldap-svr/ou=people,dc=example,dc=com"
userFilter="(&(uid={USERNAME})(objectClass=inetOrgPerson))"
authzIdentity="{EMPLOYEENUMBER}"
debug=true;
};
Authentication First
In authentication-first mode, authentication is attempted using the supplied username and password and then the LDAP directory is searched. If authentication is successful then a search is performed using the supplied username in conjunction with a specified search filter. To enable this mode, set the authIdentity and the userFilter options. Use authentication-first mode when accessing an LDAP directory that has been configured to disallow anonymous searches.
The example below requests that the LDAP server be located dynamically, that authentication be performed using the supplied username directly but without the protection of SSL and that users’ entries be located by one of three naming attributes and their objectClass attribute.
1
2
3
4
5
6
7
8
CAS {
com.sun.security.auth.module.LdapLoginModule REQUIRED
userProvider="ldap:///cn=users,dc=example,dc=com"
authIdentity="{USERNAME}"
userFilter="(&(|(samAccountName={USERNAME})(userPrincipalName={USERNAME})(cn={USERNAME}))(objectClass=user))"
useSSL=false
debug=true;
};
Authentication Only
In authentication-only mode, authentication is attempted using the supplied username and password. The LDAP directory is not searched because the user’s distinguished name is already known. To enable this mode, set the authIdentity option to a valid distinguished name and omit the userFilter option. Use authentication-only mode when the user’s distinguished name is known in advance.
The example below identifies alternative LDAP servers, it specifies the distinguished name to use for authentication and a fixed identity to use for authorization. No directory search is performed.
1
2
3
4
5
6
7
CAS {
com.sun.security.auth.module.LdapLoginModule REQUIRED
userProvider="ldap://ldap-svr1 ldap://ldap-svr2"
authIdentity="cn={USERNAME},ou=people,dc=example,dc=com"
authzIdentity="staff"
debug=true;
};
Ldaptive
Ldaptive provides several login modules for authentication and authorization against an LDAP. Each module accepts properties that correspond to the setters on objects in the ldaptive code base. If you are looking to set a specific configuration option that is available as a setter, the chances are that it will be accepted on the module. Any unknown options will be passed to the provider as a generic property.
In order to take advantage of the login modules provided by Ldaptive, the following dependency must be present and added to the overlay:
1
2
3
4
5
<dependency>
<groupId>org.apereo.cas</groupId>
<artifactId>cas-server-support-ldap-core</artifactId>
<version>${cas.version}</version>
</dependency>
1
implementation "org.apereo.cas:cas-server-support-ldap-core:${project.'cas.version'}"
1
2
3
4
5
6
7
8
9
dependencyManagement {
imports {
mavenBom "org.apereo.cas:cas-server-support-bom:${project.'cas.version'}"
}
}
dependencies {
implementation "org.apereo.cas:cas-server-support-ldap-core"
}
1
2
3
4
5
6
7
8
9
10
dependencies {
/*
The following platform references should be included automatically and are listed here for reference only.
implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom:${project.'cas.version'}")
implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
*/
implementation "org.apereo.cas:cas-server-support-ldap-core"
}
Keystore
This module prompts for a key store alias and populates the subject with the alias’s principal and credentials. Stores an X500Principal for the subject distinguished name of the first certificate in the alias’s credentials in the subject’s principals, the alias’s certificate path in the subject’s public credentials, and a X500PrivateCredential whose certificate is the first certificate in the alias’s certificate path and whose private key is the alias’s private key in the subject’s private credentials.
1
2
3
4
5
6
7
8
9
10
11
CAS {
com.sun.security.auth.module.KeyStoreLoginModule sufficient
keyStoreURL=...
keyStoreType=
keyStoreProvider=...
keyStoreAlias=...
keyStorePasswordURL=...
privateKeyPasswordURL=...
protected=...
debug=FALSE;
};
For a list of all other options and more comprehensive documentation, please see this guide for more info.
Deployments
If your deployment strategy ultimately uses an embedded container, you can pass along the location of the JAAS configuration file in form of a system property as such:
1
java -Djava.security.auth.login.config=file:/etc/cas/config/jaas.config -jar ...
Alternatively, you may activate the login configuration type to be JavaLoginConfig in the CAS settings and specify the path
to the jaas configuration file there in the settings directly.
For more information on configuration management, please review this guide.