Software AG Infrasructure 10.7 | Setting Up Security | Setting Up the JAAS Configuration File | Defining the Login Modules
 
Defining the Login Modules
In the login context, list the full class names of the login modules in the order the modules should be called by the application. List one classification flag after each login module name. List any parameters after the classification flag, separating the parameters with a space or a new line. Use semi-colons (;) to separate login modules from each other.
The code sample below shows a login context that contains the predefined login modules X509CertificateLoginModule and InternalLoginModule.
SoftwareAGSampleLoginContext {
com.softwareag.security.jaas.login.modules.X509CertificateLoginModule required
check_crl_status=true crl_url="${com.softwareag.security.crl.url}"
truststore_url="${com.softwareag.security.truststore.url}"
truststore_password="${com.softwareag.security.truststore.password}"
truststore_type=jks overwrite_username=false;

// Internal repository login module (java based)
com.softwareag.security.jaas.login.internal.InternalLoginModule requisite
template_section="INTERNAL"
logCallback="true"
internalRepository="@path:sag.install.area/common/conf/users.txt"
create_group_principal="true"
groupRepositoryPath="@path:sag.install.area/common/conf/groups.txt";

// Role repository login module
com.softwareag.security.authz.store.jaas.login.RoleLoginModule optional
storage_location="@path:sag.install.area/common/conf/roles.txt";
};
You can also use the domain parameter in a login module. This parameter enables a dynamic use of login modules. When a user logs in to an application with a domain and user name, login modules that use the domain parameter verify the domain and begin the authentication process for the user only if the domain corresponds to the one defined for the login module.
The following table shows the classification flags that you can use.
Classification
Means the authentication specified in the login module
Requisite
Must succeed. If the authentication succeeds, the authentication process proceeds down the login module list defined in the login context. If it fails, control is returned to the product and authentication stops.
Required
Must succeed. If the authentication succeeds or fails, the authentication process proceeds down the login module list defined in the login context. For example, you might want to execute audit login module that logs user login attempts. However, the overall authentication succeeds only if all requisite and required login modules succeed.
Sufficient
Does not have to succeed. If the authentication succeeds, control is returned to the product and authentication stops. If the previous requisite and required login modules also succeeded, the overall authentication succeeds. If the authentication fails, the authentication proceeds down the login module list defined in the login context.
Optional
Does not have to succeed. If the authentication succeeds or fails, the authentication process proceeds down the login module list defined in the login context. If there are no requisite or required login modules in the login context, the overall authentication succeeds only if the authentication specified in at least one sufficient or optional login module succeeds.
The following table describes global parameters that apply to all types of login modules.
Parameter
Description
create_user_ principal
Optional. Used to define whether the commit () method creates a SagUserPrincipal using the SagCredentials available in the sharedState Map.
Valid values are:
true - The commit () method creates a SagUserPrincipal. If you set this parameter to true, it cannot later be changed.
false - The commit () method does not create a SagUserPrincipal. The login modules that do not create SagUserPrincipal in their own commit () method must call the super.commit () method.The SagUserPrincipal is created only once. This is the default.
store_credentials
Optional. Used to define whether to store SagCredentials in Subject.privateCredentials. The servlet context and header field of SagCredentials are not stored. Valid values are:
true - SagCredentials is stored in Subject.privateCredentials. This is the default.
false - SagCredentials is not stored in Subject.privateCredentials.
Keeping the password in clear text in the Subject.privateCredentials may constitute a security risk, depending on how the Subject is handled. However, there are use cases where the password needs to be accessible through the Subject. Store the password only if necessary.
keep_password
Optional. Used to define whether to keep the password (if present in SagCredentials) in the credentials that are stored in Subject.privateCredentials. Valid values are:
true - if present in the SagCredentials, the value is kept in the credentials that are stored in the Subject.privateCredentials. The default value is true.
false - if present in the SagCredentials, the password is not kept in the credentials that are stored in the Subject.privateCredentials.
This parameter requires the store_credentials parameter to be set to true.
You can use the above parameters in all login modules developed using the SagAbstractLoginModule.
For a complete list of parameters you can use in login modules, see Predefined Login Modules. The domain parameter is listed in the predefined InternalLoginModule and LDAPLoginModule.
You can use location tokens (@path and @url) on parameters that call for paths or URLs. For more information about path token support, see Running Web Applications.