Define 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.

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.

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.

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.