Version 9.7
 —  LoginModules Guide  —

Predefined Login Modules

Security Infrastructure (SIN) provides default login modules.

You can use the default modules to do the following:

The default modules are as follows:

For more information about deprecated login modules in Security Infrastructure, see Deprecated Login Modules


SagAbstractLoginModule

SagAbstractLoginModule is the basic login module in SIN. It provides you with a commit() method that uses the global configuration parameters. See Configuration Parameters for details.

Use this login module for the following:

When setting up the JAAS configuration, keep in mind the following basics:

Top of page

InternalLoginModule

Description

You use the InternalLoginModule to authenticate against a user repository defined as a file on the file system. This is the default authentication mechanism for all webMethods suite products.

In case of successful authentication, the InternalLoginModule provides a user repository manager. It also creates a SagUserPrincipal object, and, optionally, a set of SagGroupPrincipal objects.

Parameters

The following table outlines the configuration parameters for the InternalLoginModule.

Parameter Description
domain

Optional.

String. Specifies the domain name to be used for authentication. Applicable if the domain usage is activated for the InternalLoginModule.

internalRepository

Specifies the path to the internal user repository file.

groupRepositoryPath

Optional.

Specifies the path to the internal group repository file.

create_group_principal

Optional.

The parameter is meaningful only if groupRepositoryPath is specified.

Valid values are:

  • false - Default. The login module does not create group principals

  • true. The login module creates group principals based on the information contained in groupRepositoryPath and attaches the to the subject.

Repository Files Format

The user-defined repository files must comply with the following format:

*
* Default test repository for INTERNAL based authentication
*
* Copyright (c) 2001 - 2013 Software AG, Darmstadt, Germany and/or Software AG USA,
* Inc., Reston, VA, United States of America, and/or their licensors. All rights reserved.
version:3.0
*
*
user:username:$6a$kMpE+PvDv83zjcQe6fk7rWEiK80V73qoy9OZzr0J4p4W3K1g9x1w2zEadkEjL2OLm1cozDfKJD7ZJckE3AysKw==
*

The group repository files must comply with the following format:

*
*
* Default test repository for INTERNAL based authentication
*
* Copyright (c) 2001 - 2013 Software AG, Darmstadt, Germany and/or Software AG USA,
* Inc., Reston, VA, United States of America, and/or their licensors. All rights reserved.
version:3.0
*
*
admin:1:administrator,user2
testadmin:2:user2
*

Example

The following sample excerpt outlines the INTERNAL mode of the InternalLoginModule and the corresponding configuration included in a login context of a JAAS configuration file.

LoginINTERNAL {
   com.softwareag.security.jaas.login.internal.InternalLoginModule required        
        domain=
								logCallback=true
        create_group_principal=true
        internalRepository="/tmp/myrepo/internalUserRepo"
        groupRepositoryPath="/tmp/myrepo/internalGroupRepo";
};

Top of page

LDAPLoginModule

Overview

The LDAPLoginModule enables you to use an external directory to authenticate users. For more information about using internally defined users and groups, see InternalLoginModule.

You can define your JAAS configuration to access information from an external directory if your site uses one of the following external directories for user and group information:

JAAS Configuration Properties

The following table outlines the JAAS configuration properties for all LDAP connections.

Parameter Description
alias

Optional.

Specifies the alias of the LDAP configuration entry. If not specified, it is set to match the url parameter.

A valid value is any string of characters.

url

Required.

Specifies the URL to the LDAP server. If you want to use an SSL connection to the LDAP server, the URL should start with "ldaps", and you should provide truststore and/or keystore parameters. The expected format is: "ldap://<host>:<port>" or "ldaps://<host>:<port>".

If url points to IPv6 IP (not domain name), it must be enclosed in square brackets. For example: alias=ldap://[::1]:389

domain

Optional.

String. Specifies the domain name to be used for authentication. Applicable if the domain concept is activated for the LDAPLoginModule.

noPrinIsAnonymous

Optional.

When prin is not defined, this property specifies what credentials are used for LDAP server authentication.

Valid values are:

  • true - Default value. The connection to the LDAP server is done anonymously.

  • false - The real user credentials of the user that connects to the LDAP server are also used for LDAP authentication.

prin

Required only if noPrinIsAnonymous is set to "false". Otherwise, this parameter must not be specified.

Specifies the distinguished name (DN) of the technical user that connects to the LDAP server if an anonymous access to the LDAP server is not allowed.

cred

Required only if noPrinIsAnonymous is set to "false". Otherwise, this parameter must not be specified.

Specifies the password of the technical user that connects to the LDAP server. You use it together with the prin parameter.

A valid value is any string of characters.

credHandle

Can be used instead of cred. Handles passman storage for technical user passwords. When a login is successful, cred is placed in passman.

timeout

Specifies the maximum time in milliseconds to spend for an LDAP operation.

The default value is 5000.

useaf

Optional. Boolean.

Specifies whether to use affixes (dnprefix and dnsuffix) or not. Use the affixes for an easier construction of user DNs with less errors.

Valid values are:

  • true - The login module uses affixes.

  • false - Default value. The login module does not use affixes.

dnprefix

Optional. String.

Specifies the prefix to attach in front of the username when performing operations on the LDAP server. To use this parameter, you should have useaf set to true.

A valid value is any string of characters.

dnsuffix

Optional. String.

Specifies the suffix to attach after the username when performing operations on the LDAP server.

A valid value is any string of characters.

usecaching

Optional. Boolean.

Specifies if the LDAP framework caches users and/or groups.

Valid values are:

  • true - Default value. The LDAP framework caches all users and/or groups.

  • false - The LDAP framework does not cache any users and/or groups.

poolmin

Specifies the minimum number of objects to be kept in the cache.

poolmax

Specifies the maximum number of objects to be kept in the cache.

mattr

Optional.

The login module uses this parameter when performing member-search operations. The meaning of this parameter depends on the value of memberinfoingroups. If memberinfoingroups is "true", the mattr parameter points from a group to the users that are members of this group. If memberinfoingroups is "false", the mattr parameter points from a user entry to the groups that the user is a member of.

A valid value is any string of characters.

The default value is "memberOf".

memberinfoingroups

Optional. Boolean.

Specifies whether the login module searches users in a group or groups in a user. You can use it only if the mattr parameter is applied to users or groups.

Valid values are:

  • true - The login module searches users in a group.

  • false - Default value. The login module searches groups in a user.

createGroups

Optional. Boolean.

Specifies whether to extract the groups of the logged-in user from the LDAP server.

Valid values are:

  • true - Default value. The login module extracts the groups of the logged-in user from the LDAP server.

  • false - The login module does not extract the groups of the logged-in user from the LDAP server.

createUserProperties

Specifies whether user properties should be populated to SagUserPrincipal.

Valid values are:

  • true - The user properties are populated to SagUserPrincipal

  • false - Default value. The user properties are not populated to SagUserPrincipal.

createGroupProperties

Specifies whether group properties should be populated to SagGroupPrincipal.

Valid values are:

  • true - The group properties are populated to SagGroupPrincipal

  • false - Default value. The group properties are not populated to SagGroupPrincipal.

uidprop

Optional

Specifies the LDAP username attribute.

The default value is "CN".

gidprop

Optional.

Specifies the LDAP group attribute.

A valid value is any string of characters.

The default value is "CN".

userrootdn

Optional.

Specifies the location to be searched for users.

A valid value is any string of characters.

grouprootdn

Optional.

Specifies from where to start searches for groups.

A valid value is any string of characters.

groupobjclass

Optional.

Specifies that the found object is a group. The login module uses this parameter when searching for groups.

The default value is "group".

personobjclass

Optional.

Specifies that the found object is a person. The login module uses this parameter when searching for users.

The default value is "person".

truststoreUrl

Specifies the URL of the truststore to be used if an SSL connection is required.

truststorePassword

Specifies the password for the used truststore if an SSL connection is required.

truststoreType

Specifies the type of truststore to be used if an SSL connection is required.

keystoreUrl

Specifies the URL of the keystore to be used if an SSL connection is required.

keystorePassword

Specifies the password for the used keystore if an SSL connection is required.

keystoreType

Specifies the type of keystore to be used if an SSL connection is required.

Example

The following sample excerpt outlines and the corresponding configuration included in a login context of a JAAS configuration file.

ExampleRealm {
 
  com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule sufficient
    alias="name1";
 
  com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule sufficient
    alias="name2";
 
  com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule sufficient;
 
  com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule required
    alias="name3"
    url="ldap://localhost:389"
    prin="CN=sectest,OU=user,dc=example,dc=org"
    cred="******"
    useaf="true"
    dnprefix="CN="
    dnsuffix=",OU=user,dc=example,dc=org"
    usecaching="false"
    mattr="roleoccupant"
    memberinfoingroups=false
    creategroups=true
    gidprop="CN"
    grouprootdn="OU=Groups,dc=example,dc=org"
    groupobjclass="organizationalRole"
    personobjclass="organizationalPerson";
};

Top of page

SAMLAssertValidatorLoginModule

Description

You use SAMLAssertValidatorLoginModule to validate the delegation ticket issued from SAMLAssertIssuerLoginModule. You can use it for both SAML 1.1 and SAML 2 assertion validation.

Parameters

None.

Example

The following sample excerpt outlines SAMLAssertValidatorLoginModule and the corresponding configuration included in a login context of a JAAS configuration file.

The following login context is installed by default with Software AG Common Platform.

/** Login context used in Common Platform for a default authentication **/
Default {
    // SSOS login module for SAML signed assertion validation	
    com.softwareag.security.idp.saml.lm.SAMLAssertValidatorLoginModule sufficient;
	
    // Internal repository login module (java based)
	   com.softwareag.security.jaas.login.internal.InternalLoginModule required
        template_section=INTERNAL
        logCallback=true
        internalRepository="C:/softwareag/common/conf/users.txt"
		      create_group_principal=true        
        groupRepositoryPath="C:/softwareag/common/conf/groups.txt";   
};

Top of page

SAMLAssertIssuerLoginModule

Description

You use SAMLAssertIssuerLoginModule to issue a SAML1.1 or SAML 2 assertion as a delegation ticket between Software AG products.

You can only use the SAMLAssertIssuerLoginModule in a chain of login modules. Using this login module on its own, in a separate login context, is not possible, because it is the other modules in a given login context that perform the actual authentication of the user. When the authentication is successful, SAMLAssertIssuerLoginModule issues a SAML assertion where the fully qualified name of the authenticated user is part of the Subject of the AuthenticationStatement attribute of the SAML 1.1 assertion and the SubjectConfirmation attribute of the SAML 2 assertion. Optionally, the assertion contains a list of groups (where such are available) as part of the AttributeStatement attribute of the SAML assertion.

Parameters

The SAMLAssertIssuerLoginModule has a single parameter that you set in the JAAS configuration.

Parameter Description
forceSamlVersion

Optional.

Defines which SAML assertion version to use to issue the delegation token.

Valid values are:

  • 1.1 - Use this value to force SAML 1.1 assertion.

  • 2.0 - Default value. Use this value to force SAML 2 assertion.

Example

The following sample excerpt outlines SAMLAssertIssuerLoginModule and the corresponding configuration included in a login context of a JAAS configuration file.

First, InternalLoginModule authenticates the user. If the authentication is successful, SAMLAssertIssuerLoginModule issues a SAML 1.1 assertion to be used as a delegation ticket.

/** Login Configuration for	the SAMLAssertIssuerLoginModule. **/
SAMLIssuerRealm {
    // Internal repository login module (java based)
	   com.softwareag.security.jaas.login.internal.InternalLoginModule required
        template_section=INTERNAL
        logCallback=true
        internalRepository="C:/softwareag/common/conf/users.txt"
		      create_group_principal=true        
        groupRepositoryPath="C:/softwareag/common/conf/groups.txt";  
		  
    // SSOS login module for SAML 1.1 signed assertion issuance
    com.softwareag.security.idp.saml.lm.SAMLAssertIssuerLoginModule sufficient
		      forceSamlVersion="1.1";
};

Top of page

JMXDelegatedAuthLoginModule

Description

You use JMXDelegatedAuthLoginModule to validate the delegation ticket issued from SAMLAssertIssuerLoginModule or directly from the SSO service. You can use it for both SAML 1.1 and SAML 2 assertion validation. The purpose of this login module is to support the JMX delegation mechanism. The login module gets a delegation ticket from the password field of the supplied credentials.

Parameters

None.

Example

The following sample excerpt outlines JMXDelegatedAuthLoginModule and the corresponding configuration included in a login context of a JAAS configuration file.

The following login context is installed by default with Software AG Common Platform.

/*
 * Login context, used in Common Platform for management channel.
 */
PlatformManagement {
    // SSOS login module for SAML signed assertion validation
    // used for delegated authentication only for JMX
	   com.softwareag.security.idp.saml.lm.JMXDelegatedAuthLoginModule sufficient;
	 
    // Internal repository login module (java based)
	   com.softwareag.security.jaas.login.internal.InternalLoginModule required
        template_section=INTERNAL
        logCallback=true
        internalRepository="C:/softwareag/conf/users.txt"; 
};

Top of page

ServletHeaderLoginModule

Description

You use ServletHeaderLoginModule to extract information from an HttpServletRequest which is sent to the login module as part of the SagCredentials. The login module extracts the X.509 certificate chain or SAML artifacts, which are received as a result of an HTTPS with ClientAuthentication against a web server. The login module enters this information into the SagCredentials and makes it available to other login modules used in the login context of a JAAS configuration file. Optionally, the login module can extract more information, such as user names and passwords.

Parameters

The following table outlines the parameters of ServletHeaderLoginModule.

Parameter Description
saml_artifact_prop_name

Optional.

Defines the name of the SAML artifact property. The default value is SAMLArt.

netegrity_siteminder_prop_name

Optional.

Defines the name of the Netegrity SiteMinder property. The default value is SM_USER.

Example

The following sample excerpt outlines ServletHeaderLoginModule and the corresponding configuration which is included in a login context of a JAAS configuration file.

/** Login Configuration for the ServletHeaderLoginModule. **/
ServletHeaderLogin {
    com.softwareag.security.jaas.login.modules.ServletHeaderLoginModule optional;
};

Top of page

SimpleNameMappingLoginModule

Description

You use SimpleNameMappingLoginModule to map a user name that is in the sharedState or CallbackHandler to another user name, which is for example in a different user repository. The login module sends the result in the sharedState map. Depending on the parameters you include in the JAAS configuration file, you can provide different mapping modes with the login module. The properties mapping mode is based on a Java properties file. The regular expression mapping mode is based on the java.util.regex package. To enable a mapping mode you must use the corresponding configuration parameter in the JAAS configuration. Note that you cannot use both mapping modes at the same time.

For more sophisticated mapping method, you can sub-class SimpleNameMappingLoginModule. Using the following sample excerpt, you can rework the method as explained. You can use the context parameter to define the target context for which the mapping is performed. The SagCredentials are sent by the application which calls the login module and therefore, must not be modified. You set the values of the super class variables using the mapName method and mapPassword method, if applicable.

protected mapName(String context, SagCredentials credentials, Map options)
throws SagGeneralSecurityException

Parameters

The following table outlines the parameters of SimpleNameMappingLoginModule.

Parameter Description
user_mapping_url

Mandatory only if you use properties file mapping.

It defines the URL of the Java properties file that contains the mapping information.

user_mapping_regex

Required only if you use regular expression mapping.

It defines what regular expression to use to collect the user name from the input name.

user_mapping_matchgroup

Optional.

Defines the regular expression group which is used for the results of the regular expression. The default value is 1.

Examples

Example 1:

If you add this LoginModule to the stack:

com.softwareag.security.jaas.login.modules.SimpleNameMappingLoginModule required 
        user_mapping_url=file://path/to/mapping_user.properties

The mapping_user.properties file contains the following entries:

testclient=Test Client
testclient.password=secret1

If you login with username "testclient" the login modules after SimpleNameMappingLoginModule will receive username "Test Client" and password "secret1" as credentials.

Example 2:

If you add this LoginModule to the stack:

com.softwareag.security.jaas.login.modules.SimpleNameMappingLoginModule required 
        user_mapping_regex="CN=(\\w*),(.*)"

If you login with username “CN=Client1, OU=R&D, O=RSUBJET, C=DE” the login modules after SimpleNameMappingLoginModule will receive username "Client1" as credentials.

Example 3:

If you add this LoginModule to the stack:

com.softwareag.security.jaas.login.modules.SimpleNameMappingLoginModule required 
        user_mapping_regex="CN=(\\w*),(.*)"
        user_mapping_matchgroup="3"

If you login with username “CN=Client1, OU=R&D, O=RSUBJET, C=DE” the login modules after SimpleNameMappingLoginModules will receive username null as credentials.

Top of page

X509CertificateLoginModule

Description

You use X509CertificateLoginModule to verify one or more than one X.509 certificate. The login module builds all chains of trust and at least one chain must end at the Trust Anchor. All certificates in the chain are verified according to the Public Key Infrastructure extensions (PKIX). The module checks the statuses of the certificates against Certificate Revocation Lists (CRLs). It can import missing certificates from PKCS#7 files. To get the CRL, the validation of the login module supports CRL distribution point (CRL DP). To enable CRL DP, you can set the value of the Java system property com.sun.security.enableCRLDP to "true". The login module also provides direct trust. This means that the module checks whether the end entity certificate is part of the truststore. If it is, direct trust is created and further CRL checks are disabled.

Parameters

The following table outlines the parameters of the X509CertificateLoginModule. The parameters allow you to extend the login module functionality and plug in other certificate validation methods in it.

Parameter Description
truststore_url

Defines the URL of the keystore which contains the Trust Anchors. This is the RootCA or certificate authority (CA) certificates that are trusted.

truststore_password

Defines the password of the trust keystore.

truststore_type

Optional.

Defines the type of the trust keystore.

Valid values are:

  • "PKCS7"

  • "PKCS12"

  • " JKS" - Default value.

check_crl_status

Boolean.

The following list outlines the possible options:

  • "true"
    The status of the end entity certificate is checked against a URL. In this case, the crl_url parameter must be set.

  • "false"
    The login module is set to use direct trust.

crl_url

Mandatory if the check_crl_status is set to true.

Defines the URLs of the CRL for the end entity certificate. The URLs are separated by a space.

overwrite_username

Optional. Boolean.

Valid values are:

  • true - Default value. The user name is overwritten with the certificate subject distinguished name (DN).

  • false - The module accomplishes only validation of the certificates.

additional_certificates_container_url

Optional.

Defines the URL of the container of additional certificates.

additional_certificates_container_type

Optional.

Defines the type of the container of additional certificates.

Valid values are:

  • "PKCS7"

  • "PKCS12"

  • "JKS"

additional_certificates_container_password

Mandatory only if the additional_certificates_container_type parameter is set to "JKS" or "PKCS12".

Defines the password of the certificate container.

Example

The following sample excerpt outlines X509CertificateLoginModule and the corresponding configuration that is included in a login context of a JAAS configuration file. The example also shows how the login context reads crl_url, truststore_url, and truststore_password from the Java system parameters. Note that every Java system parameter that is included in the JAAS configuration file must have a value that differs from NULL or the empty string. Failure to do so may cause an exception on the system.

/** Login Configuration for the X509CertificateLoginModule **/
X509Login {
    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
        additional_certificates_container_url="${com.softwareag.security.certificate.container.url}"
        additional_certificates_container_type="jks"
        additional_certificates_container_password="="${com.softwareag.security.certificate.container.password}";
};

Top of page

SAMLArtifactLoginModule

Description

You use SAMLArtifactLoginModule to verify credentials received as SAML artifacts. The module uses the opensaml library and supports SAML version 1.1. It sends a request and validates the SAML artifact against a SAML endpoint, which is the authority issuer of the artifact. The authentication is successful only if the endpoint validates the SAML artifact successfully. The result of the validation is a SAML response that contains information about the owner of the artifact. A part of this response is the user name. If configured in the JAAS configuration file, the login module can overwrite the user name in the SagUserPrincipal with the one that is received in the SAML response.

Parameters

The following table outlines the parameters of SAMLArtifactLoginModule.

Parameter Description
saml_identity_provider_url

Defines the URL of the SAML authority that validates the artifact.

overwrite_username

Optional. Boolean.

Valid values are:

  • true - Default value.

  • false - The user name is overwritten with the one that is received in the SAML artifact validation process.

Example

The following sample excerpt outlines SAMLArtifactLoginModule and the corresponding configuration that is included in a login context of a JAAS configuration file. In this example, the login context reads the saml_identity_provider_url parameter from the Java system parameters. Note that every Java system parameter that is included in the JAAS configuration file must have a value that differs from NULL or empty string. Failure to do so may cause an exception on the system.

/** Login Configuration for the SAMLArtifactLoginModule **/
SAMLArtifactLogin {
    com.softwareag.security.jaas.login.modules.SAMLArtifactLoginModule required
        saml_identity_provider_url="${com.sample.security.saml.samlendpoint}"
        overwrite_username=true;
};

Top of page

SSXLoginModule

With this login module, you can authenticate users and retrieve groups through the native SSX library.

SSXLoginModule is distributed as a template property file within the sin-ssx.jar file. It performs authentication using one of the following combination of credentials:

See SSXLoginModule Configuration Template for the content of the template file.

Note:
The template file holds the properties that will be changed rarely, while the configuration file holds the properties that will be changed frequently.

Authentication is done against LDAP, Active Directory, IAF server, or operating system.

In the case of authentication against an IAF server, you may receive an IAF token or artifact during delegated authentication that is added as a SecurityToken to the SharedMap. This IAF token authenticates you. Authentication is done in the following way:

Start of instruction setTo use SSXLoginModule

  1. Set sin-common.jar and sin-ssx.jar in the classpath.

  2. Set the <dlls> in java.library.path.

Start of instruction setTo configure SSXLoginModule

  1. Configure SSXLoginModule to use RMI

  2. Configure and start the RMI server.

There is a set of default parameters for the configuration of SSXLoginModule. These parameters are used by default and you can overwrite all of them within the JAAS configuration file.

The information about the SSXLoginModule custom parameters is organized under the following headings:

Parameters for Common Configuration

SSXLoginModule has several custom parameters for the module options.

Specify your own options, including the mandatory ones that are not included in the template. Your parameters overwrite the ones from the template file.

Security Infrastructure supports a mechanism for overwriting SSX properties which complies with the following pattern:

  1. Initially, Security Infrastructure verifies all locally configured settings.

  2. If the OPTIONS_URL parameter is configured, the functionality attempts to obtain the properties remotely.

The following table outlines the SSXLoginModule parameters for common configuration.

Parameter Description
options_url

Optional.

Defines the URL that specifies the location of the properties file. It may contain any of the listed SSX login module parameters. It allows you to manage all SSX properties centrally.

No default value.

Note:
The parameters in the JAAS configuration file overwrite any parameters in the template properties file.

UseDomainForOptionsURL

This parameter appends the domain to the value of the options_url parameter only if the options_url parameter is set, the UseDomainForOptionsURL parameter is set to "true", and the user credentials contain a non-empty and non-null domain.

Valid values are:

  • true

  • false - Default value.

template_section

The value is a section from the template authentication properties file.

Note:
Only the properties in the specified section are used in the login module.

Valid values are:

  • internal

  • os

  • adsi

  • ldap

  • iaf

No default value.

create_user_principal

Optional.

Creates SagUserPrincipals.

Valid values are:

  • true - Default value. The commit () method creates the SagUserPrincipal. In this case, all existing SagUserPrincipals in the Subject are removed and replaced by the new one.

  • false - The module does not create the SagUserPrincipal. In this case, the application is not able to access the user repository.

defaultDomainName

Optional.

Specifies the default domain name. If the defaultDomainName parameter and the domain name from the SagCredentials are not null and not equal, the login module returns "false" in the authentication phase.

No default value.

CreateGroups

Optional.

Specifies whether the login module creates user groups.

Valid values are:

  • true - Default value.

  • false - GroupPrincipals is not created.

CreateGroupProperties

Optional.

Specifies whether the login module creates user group properties.

Valid values are:

  • true - Default value. The login module creates group properties.

  • false - The login module does not create group properties.

CreateUserProperties

Optional.

Specifies whether the login module creates user properties.

Valid values are:

  • true - Default value. The login module creates user properties.

  • false - The login module does not create user properties.

propertyMapping.number

Optional.

Specifies the number of mapped properties. Use this property if you want to have property mapping.

A valid value is any positive integer value.

No default value.

propertyMapping.X.key / propertyMapping.X.value

Required only if propertyMapping.number is given.

Specifies key/value pairs for the property mapping.

Valid values: X (key and value) runs through all values from "0" to "(propertyMapping.number – 1)". For example, "propertyMapping.0.key=<string>".

No default value.

nativeLogFile

Optional.

Specifies the output file for logging.

No default value.

nativeLogLevel

Optional.

Specifies the value of the logging level.

Valid values are the Integer values from 1 to 6.

No default value.

cacheTime

Optional.

Specifies for how long the authenticated user stays in cache. The value is in seconds.

A valid value is any Integer value.

The default value is 180.

denyTime

Optional.

Specifies for how long the authenticated requests of a particular user (userID) are ignored. The value is in seconds.

A valid value is any Integer value.

The default value is 100.

denyCount

Optional.

Specifies the number of invalid login attempts.

A valid value is any Integer value.

The default value is 3.

cacheSize

Optional.

Specifies the maximum number of successfully authenticated users that are stored in the cache. When the cache overflows, the oldest entry is removed.

A valid value is any Integer value.

The default value is 300.

Parameters for Internal Repository Configuration

This section describes the INTERNAL repository type which is based on a text file. The current default repository type, OS, requires specific root privileges on UNIX. To avoid the necessity of specific privileges, it is recommended that you use the internal repository as the default user repository for new installations that use SSX on UNIX.

The internal repository text file is an alternative to the OS and LDAP repositories. It is recommended to use an internal repository only during the initial setup of all required components or until you configure a real repository.

The following table outlines the internal repository mode parameters of the SSXLoginModule.

Parameter Description
authType

Specifies the user repository type. The required value is "INTERNAL".

No default value.

internalRepository

Specifies the path of the internal text repository file.

For more information, see Creating Internal User Repository Files.

defaultDomain

Optional.

Specifies a default domain name. When calling the getAllUsers() method the defaultDomain parameter is added in front of any user ID returned.

Example

The following sample excerpt outlines the INTERNAL mode of the SSXLoginModule and the corresponding configuration which is included in a login context of a JAAS configuration file.

/** Example Login Configurations for the SSXLoginModule **/
/* This context is for logging in to the internal repository. */
SSXLoginINTERNAL {
    com.softwareag.security.jaas.login.ssx.SSXLoginModule required
        template_section=INTERNAL
        logCallback=true
        internalRepository="/tmp/myrepo/internalRepo";
};

Parameters for Operating System Configuration

The following table outlines the SSXLoginModule parameters for operating system configuration:

Parameter Description
authType

Specifies the user database type. The valid value is os.

No default value.

authDaemonPath

Specifies the explicit path of the privileged daemon process. Specify this parameter if the sagssxauthd2 executable file is not in the current directory. Valid value is the valid path to the sagssxauthd2 module.

No default value.

Note:
UNIX only.

defaultGroup

Optional.

Specify a default group name here to be returned with any of the group results that are returned by the repository manager.

A valid value is any valid group name.

No default value.

defaultDomain

Optional.

If this parameter is specified, its value is used at authentication time when domain name is not specified by the user. If a domain name is specified, the value of this parameter is not used.

A valid value is any valid domain name.

No default value.

noImpersonation

Optional. Boolean.

Specifies how to access data.

Valid values are:

  • true - Access is under the account of the running process.

  • false - Default value. The data access is under the impersonated user ID of the logged on user.

Note:
Windows only.

unixAddMachineName

Optional. Boolean.

Specifies the local machine name (on which the user is authenticated). The machine name is added before users and groups; for example, machine_name\user.

Valid values are:

  • true - If set to "true" (and there is no domain field), you are authenticated against the local machine only.

  • false - Default value. You are authenticated on the domain that you logged on.

Parameters for ADSI Configuration

The following table outlines the SSXLoginModule custom parameters for ADSI configuration.

Parameter Description
authType

Specifies the user database type. The valid value is adsi.

No default value.

defaultGroup

Optional.

Specify a default group name here to be returned with any of the group results that are returned by the repository manager.

A valid value is any valid group of users.

No default value.

defaultDomain

Optional.

If this parameter is specified, its value is used at authentication time when domain name is not specified by the user. If a domain name is specified, the value of this parameter is not used.

A valid value is any valid domain name.

No default value.

serverHost

Optional.

Specifies the name of the server.

A valid value is any valid server name and any valid IP address.

No default value.

adsiPersonBindDn

Optional.

Specifies the Personal Bind Distinguished Name (DN) for LDAP required for accessing a user. Use it only when all the users that are accessed are under the same node. Do not use it in cases of normal authentication.

Valid values: for example, "ou=users, ou=germany, dc=eur, dc=sa, dc=com".

No default value.

adsiGroupBindDn

Optional.

Specifies the Personal Bind Distinguished Name (DN) for LDAP required for accessing a group. Use it only when all the groups that are accessed are under the same node. Do not use it in cases of normal authentication.

Valid values: for example, "ou=groups, ou=germany, dc=eur, dc=sa, dc=com".

No default value.

adsiForestDn

Optional.

Specifies the name of the forest. You use this value when accessing ActiveDirectory.

Valid values: for example, "dc=myorg,dc=com".

No default value.

Parameters for LDAP Configuration

The following table outlines the SSXLoginModule custom parameters for LDAP configuration.

Parameter Description
authType

Specifies the user database type.

The valid value is ldap.

No default value.

serverHost

Specifies the name of the server.

A valid value is any valid server name and any valid IP address.

No default value.

serverPort

Optional.

Specifies the port of the server.

A valid value is any valid port number.

The default value is 389.

serverType

Optional.

Specifies the type of the server.

Valid values are:

  • OpenLdap - Default value.

  • ActiveDirectory

  • SunOneDirectory

  • Novell

  • ApacheDS

  • Tivoli

No default value.

personBindDn

Specifies the Personal Bind Distinguished Name (DN) for LDAP where the authentication information is stored. This value is prefixed with “userIdField=” when running the LDAP authentication.

Valid values: for example, "ou=users, ou=germany, dc=eur, dc=sa, dc=com".

No default value.

groupBindDn

Specifies the Group Root Distinguished Name (DN) for LDAP where the search for group names starts. This value is prefixed with “groupIdField=” when running the LDAP authentication.

Valid values: for example, "ou=groups, ou=germany, dc=eur, dc=sa, dc=com".

No default value.

personObjClass

Optional.

Specifies the object classes that are contained in the user entries.

Valid values: <String_Value1>, <String_Value2>, ..., <String_ValueN>.

The default value depends on the serverType parameter:

  • top, person (OpenLdap)

  • top, person, organizationalPerson, user (ActiveDirectory)

  • top, person, organizationalperson, inetorgperson (SunOneDirectory)

  • top, person, organizationalPerson, ndsLoginProperties (Novell)

  • top, person, organizationalPerson (Apache)

  • top, person, organizationalPerson,user (Tivoli)

groupObjClass

Optional.

Specifies the object classes that the group entries contain.

Valid values: <String_Value1>, <String_Value2>, ..., <String_ValueN>.

The default value is dependent on the serverType parameter:

  • top, groupOfUniqueNames (OpenLdap)

  • top, group (ActiveDirectory)

  • top, groupofuniquenames (SunOneDirectory)

  • top, groupOfUniqueNames (Novell)

  • top, groupOfUniqueNames (Apache)

  • top, group (Tivoli)

personGrpAttr

Optional.

Specifies the property name of a user entry. It points from a user entry to the group that the user is a member of.

Valid values: <String_Value>.

The default value depends on the serverType parameter:

  • ou (OpenLdap)

  • memberOf (ActiveDirectory)

  • NULL (SunOneDirectory)

  • NULL (Novell)

  • NULL (Apache)

  • memberOf (Tivoli)

groupPrsAttr

Optional.

Specifies the property name of a user entry that points from the group to the users.

Valid values: <String_Value>.

The default value is dependent on the serverType parameter:

  • uniqueMember (OpenLdap)

  • member(ActiveDirectory)

  • uniqueMember (SunOneDirectory)

  • uniqueMember (Novell)

  • uniqueMember (Apache)

  • member (Tivoli)

userIdField

Optional.

Specifies the property name that denotes a user entry.

Valid values: <String_Value>.

The default value is dependent on the serverType parameter:

  • uid (SunOneDirectory)

  • cn (others)

groupIdField

Optional.

Specifies the property name that denotes a group entry.

Valid values: <String_Value>.

The default value is cn.

allowDomainAsBaseBindDn

Optional. Boolean.

If the domain name is not specified explicitly and the defaultDomain parameter is set, this value is interpreted as BaseBindDN.

Valid values are:

  • true - the domainname parameter is interpreted as a BaseBindDN (for example, “ou=People,dc=myorg,dc=com”).

  • false - Default value.

personPropAttr

Optional.

Specifies the property names that can be accessed for a user entry.

A valid value is a comma-separated list that contains the property names (<String_Value1>, <String_Value2>, ..., <String_ValueN>).

The list with property names for a user entry is empty in the following cases:

  • All specified properties do not exist.

  • All specified properties are binary properties.

The default value is dependent on the serverType parameter:

  • cn, sn, description, telephoneNumber, seeAlso (OpenLdap)

  • cn, displayName, description, mail,telephoneNumber, physicalDeliveryOfficeName, givenName, sn, homeDirectory, ou, cn,description (ActiveDirectory)

  • uid, cn, sn, title, description, telephoneNumber, seeAlso, postalAddress, postalCode, postOfficeBox (SunOneDirectory)

  • cn, fullName, description, eMailAddress, telephoneNumber, departmentNumber, givenName, sn (Novell)

  • cn, description, telephoneNumber (Apache)

  • top, person, organizationalPerson, user (Tivoli)

groupPropAttr

Optional.

Specifies the property names that can be accessed for a group entry.

The value is a comma-separated list that contains the property names (<String_Value1>, <String_Value2>, ..., <String_ValueN>).

The list with property names for a group entry is empty in the following cases:

  • All specified properties do not exist.

  • All specified properties are binary properties.

The default value depends on the serverType parameter:

  • uniqueMember (OpenLdap)

  • member (ActiveDirectory)

  • uniqueMember (SunOneDirectory)

  • uniqueMember (Novell)

  • uniqueMember (Apache)

  • member (Tivoli)

ldapStartTls

Optional. Boolean.

Enforces the usage of secure communication (TLS/ SSL).

Valid values are:

  • true

  • false - Default value.

resolveGroups

Optional.

Specifies the method for finding the groups of a user using the LDAP authentication type.

Valid values are:

  • "CP" - This method uses a computed property field that contains all of the groups (virtually) in the user record.

  • "RU" - Default value. The recurse up method looks for a particular field ("personGrpAttr") to find the groups of which the current entry is a direct member.

  • "RD" - The recurse down method performs an LDAP search to find all groups that have the particular user as a member. There are no more recursions performed at this time.

computedGroupProp

Optional.

Denotes the name of the LDAP property. It is activated if resolveGroups is set to "CP".

Valid values: <String_Value>.

No default value.

ldapSSLConnection

Optional. Boolean.

This parameter denotes the secure communication (with set serverHost and serverPort) through an LDAP server.

Valid values are:

  • true

  • false - Default value.

followReferrals

Optional. Boolean.

Specifies whether the SSXLoginModule must follow referrals or not.

Valid values are:

  • true - Default value.

  • false

refServerBindingType

Optional.

Specifies the kind of binding during "referral following".

Valid values are:

  • same_creds - Default value. Uses the same credentials for authentication to the next LDAP server.

  • no_creds - Uses anonymous binding to the next server.

referralHopsCnt

Optional.

Specifies the count of the referral hops. If this parameter is not specified, the count is unlimited.

A valid value is any positive integer.

The default value is unlimited.

useLdapTechUser

Optional. Boolean.

Allows you to enable the usage of a technical user.

Valid values are:

  • true

  • false - Default value.

techLdapUserCredFile

Mandatory only if you enable the usage of a technical user.

Specifies the path of the technical user credentials file.

A valid value is any valid directory and file name on the file system.

No default value.

For more information, see Creating Technical User Credential Files.

techLdapUserKeyFile

Optional.

Specifies the path of the alternative key file.

A valid value is any valid directory and file name on the file system.

No default value.

Parameters for RMI Configuration

The following table outlines the SSXLoginModule custom parameters for RMI configuration.

Parameter Description
rmiEnabled

Optional. Boolean.

Specifies whether the SSXLoginModule must access the SSX through RMI.

Valid values are:

  • true - In this case, you must set all the parameters described below.

  • false - Default value.

rmiServerAddress

Optional.

Specifies the host server for RMI. Use it only if rmiEnabled is set to “true”, and if the RMI server is not on the same physical machine, that is, “localhost”.

A valid value is any valid server address.

The default value is localhost.

rmiServerPort

Optional.

Specifies the port that the remote server listens. Use it only if rmiEnabled is set to “true”.

A valid value is any valid server port.

No default value.

Note:
remoteServerPort is the deprecated version of this parameter.

throw_exc_missing_remote

Optional. Boolean.

Valid values are:

  • true - If RMI is unreachable or missing, the login module throws an exception.

  • false - Default value. If RMI is unreachable or missing, the login module cannot authenticate successfully and does not throw an exception.

Top of page

DelegatedAuthenticationLoginModule

You use this login module to issue IAF tokens based on a previously performed authentication outside the SIN infrastructure.

You need this login module in order to use custom authentication in the application. Based on the established trust, you retrieve an IAF token for authentication.

This module establishes trust between the application using this login module and the IAF server (client SSL certificates validation).

The trust relationship is based on digital signatures. For each delegated authentication request, a signed message (SHA1/RSA) is sent from DelegatedAuthenticationModule to the IAF server. The IAF server verifies the message and searches for the signer certificate in a white list.

Parameters for Configuration

The required custom parameters are passed to an SSX function call and to a corresponding Java method.

To use this module via RMI, extend the Authenticator classes.

This login module requires the same configuration parameters as SSXLoginModule when using IAF authentication.

The following table outlines the parameters of DelegatedAuthenticationLoginModule

Parameter Description
keystore_url

Specifies the URL pointing to the Java keystore to be used for signing.

A valid value is any valid URL.

No default value.

keystore_password

Specifies the password for the keystore to be used for signing.

keystore_type

Optional.

Specifies the type of the keystore.

Valid values are:

  • "PKCS7"

  • "PKCS12"

  • " JKS" - Default value.

signkey_alias

Optional.

Specifies the key alias to use for signing.

signkey_password

Mandatory only if it is not the same as keystore_password.

Specifies the password for the signing key, if it is not the same as the keystore password.

canonical_username_prefix

Optional.

String that is to be prefixed to the user name. If not present, nothing is prefixed, and just the domain and user name are passed.

create_user_principal

Optional. Boolean.

Valid values are:

  • true - Default value. The commit () method creates a SagUserPrincipal using the SSXPrincipal.

  • false

rmiEnabled

Optional. Boolean.

Specifies whether SSXLoginModule must access SSX through RMI. The login module does not use RMI by default.

Valid values are:

  • true

  • false

rmiServerAddress

Mandatory only if the rmiEnabled parameter is set to true and if the RMI server is not on the same physical machine, that is, “localhost”.

Specifies the hostname/IP address of the remote server - “user.sam.ple.com” or “10.3.137.20”.

rmiServerPort

Required only if the rmiEnabled parameter is set to true.

Specifies the port that the remote server listens to - “12345”.

Note:
remoteServerPort is the deprecated version of this parameter.

rmiSSLEnable

Mandatory only if the rmiEnabled parameter is set to true.

Specifies whether the RMI connection uses SSL or not.

rmiKeyStore

Mandatory only if the rmiSSLEnable parameter is set to true.

Specifies the keystore that must be used during the secure RMI communication.

rmiKeyStorePass

Mandatory only if the rmiSSLEnable parameter is set to true.

Specifies the keystore password.

rmiKeyStoreType

Mandatory only if the rmiSSLEnable parameter is set to true.

Specifies the keystore type.

rmiTrustStore

Mandatory only if the rmiSSLEnable parameter is set to “true”.

Specifies the truststore that must be used during the secure RMI communication.

rmiTrustStorePass

Mandatory only if the rmiTrustStore parameter is specified.

Specifies the truststore password.

rmiTrustStoreType

Mandatory only if the rmiTrustStore parameter is specified.

Specifies the truststore type.

throw_exc_missing_remote

Optional. Boolean.

Valid values are:

  • true - If RMI is unreachable or missing, the login module throws an exception.

  • false - Default value. If RMI is unreachable or missing, the login module cannot authenticate successfully and does not throw an exception.

Top of page

SSXStopLoginModule

Description

You use SSXStopLoginModule as a dummy replacement of the XmlServerLoginModule. If a preceding SSXLoginModule authenticates the subject, then the SSXStopLoginModule terminates the module chain if it is "sufficient".

The following LoginModule methods act as follows:

The following table contains some user cases:

User case login() returns... commit() returns... Whole authentication
Unauthenticated subject false false LoginModule ignored
Authenticated subject false true pass

Parameters

None. Any provided parameters are ignored.

Example

The following sample excerpt outlines SSXStopLoginModule.

/* Internal repository login module (SSX) */
    com.softwareag.security.jaas.login.ssx.SSXLoginModule requisite
      template_section="INTERNAL"
      logCallback="true"
      internalRepository="C:/SoftwareAG/common/conf/users.txt"
    /*SSXStopLoginModule*/ 
    com.centrasite.resourceaccess.junit.SSXStopLoginModule sufficient;

Top of page

SimpleSSXLoginModule

Description

You use SimpleSSXLoginModule to authenticate against the local operating system only. The module invokes a simple command line utility that sends encrypted user name and password, and returns an encrypted answer that indicates whether the authentication is successful. The module does not control any other information, such as users, groups, or user properties. Also, it does not implement IUserRepositoryManager. The module encrypts the message using a TripleDES algorithm. The command line utility authenticates the user against the local operating system using an SSX library.

Note:
If you use the SimpleSSXLoginModule on UNIX-based operating systems, you must set the authDaemonPath property in the JAAS configuration file.

Parameters

The following table outlines the parameters of SimpleSSXLoginModule.

Parameter Description
LoginUtilityPath

Defines the full location path to the command line utility that performs the login.

authDaemonPath

This parameter is mandatory only for UNIX operating systems. It defines the full location path of the privileged daemon process. You must specify a value for the property if the executable sagssxauthd2 module is not available in the current work directory.

Example

The following sample excerpt outlines the SimpleSSXLoginModule and the corresponding configuration included in a login context of a JAAS configuration file.

/** Login Configuration for the SimpleSSXLoginModule **/
SimpleSSXLogin { 
    com.softwareag.security.jaas.login.ssx.SimpleSSXLoginModule required
        LoginUtilityPath=<command_line_utility>;
}

Top of page

RemoteLoginModule

The implementation of LDAP support in Security Infrastructure allows you to access an LDAP server and browse for fully qualified users anonymously or using technical user credentials. To access a protected LDAP server that does not accept anonymous queries, you can use SSXLoginModule directly, or configure and use RemoteLoginModule to access the remote authentication service (and then SSXLoginModule) in the login context of your JAAS configuration. RemoteLoginModule allows you to enforce queries that are executed by the technical user and facilitates the discovery of fully qualified users on the LDAP server. This login module is used on the client side and allows you to protect key information about the technical user from the end user. RemoteLoginModule is explicitly part of Security Infrastructure and does not interact with the LDAP server directly.

RemoteLoginModule extends SagAbstractLoginModule and is part of the sin-common.jar package. In its initialize phase, the login module follows a standard way to obtain the available SagCredentials objects from CallbackHandler and all properties from the JAAS configuration. During the login phase, the login module prepares the communication channel with the remote service and uses the host name and port number that are specified in the properties of the login module. Additional properties ensure the communication over a secure SSL or TLS protocol. When the connection is established, the transmitted message contains the name of the system (IP address or a DNS name), all available credentials (SagCredentials), and optionally JAAS configuration properties.

After a successful authentication, the login module receives from the remote service a Subject (which has attached UserRepositoryManager) as it is created on the remote side. The subject is stored locally in the login module. If the authentication fails on the remote side, SagGeneralSecurityException is received in the login module, which on the other hand is converted to a LoginException on the client side. In the commit phase, RemoteLoginModule parses the local Subject and extracts from it information about all entries, such as principals, public and private credentials, properties and so on. At a later stage, the login module assigns these entries to the Subject on the client side that is connected with the authentication. An important stage is to attach IUserRepositoryManager instance which comes from the remote service. As part of Security Infrastructure, you can combine and use this login module with all available login modules to fulfill any custom authentication scenarios.

Parameters for Configuration

The following table outlines the parameters of RemoteLoginModule.

Parameter Description
rmiServerAddress

Defines the host name of the remote server. A valid value is any valid server name or IP address.

rmiServerPort

Defines the port number on which the remote server is running.

Example

The following sample excerpt outlines RemoteLoginModule and the corresponding configuration included in a login context of a JAAS configuration.

/** Login Configuration for the RemoteLoginModule **/
RemoteLoginModuleSSL {
    com.softwareag.security.jaas.remote.login.RemoteLoginModule required
        rmiServerAddress="server"
        rmiServerPort="32415";
};

Remote Service Overview

The implementation of the remote service remains in the existing RMI implementation and additionally comprises two classes that are connected to the remote authentication and repository manager RemoteLoginServer and RemoteRepositoryManagerServer respectively.

The RemoteLoginServer class facilitates the second authentication that is based on the credentials that come from the client side. The entire process includes the following stages:

  1. The remote service listens on a specified port and supports SSL/TLS server authentication. The port is configured in the RemoteSSXServer.config file. When it receives a communication request, if needed, it validates the SSL/TLS certificates.

  2. When the certificates are successfully validated, and the communication channel is enabled, the remote service receives a message which contains the name of the client system (an IP address or a remote system name) all available credentials (SagCredentials) and optional JAAS configuration entities. The service extracts the name of the client system and checks whether it is received from a secure client.

  3. If the client is secure, the service prepares a follow up authentication. The configuration name for technical user is set in the RemoteSSXServer.config file and the JAAS configuration file is set as a system property java.security.auth.login.config when the RMI server is running.

  4. In case of successful authentication, the service returns to the client a generated Subject. The server subject is saved in a cache with the contexts of the currently authenticated clients. In case of failure, SagGeneralSecurityException which contains the root cause is returned.

When the RMI server is running, one more object is created for the remote repository manager. This object is an instance of RemoteRepositoryManagerServer. The process includes the following stages:

  1. The remote repository manager listens on a specified RemoteSSXServer.configport and supports SSL/TLS server authentication.

  2. The manager extracts the subject from the cached context and then it retrieves repository manager from the principal in the Subject.

  3. The server repository manager is used for each remote repository operation and data transfer to the client.

Parameters

To configure the remote service to handle technical user requests, you must configure the following properties in the server configuration file (RemoteSSXServer.config).

Parameter Description
authPortTech

Optional.

Defines the remote technical user authentication port.

repoPortTech

Optional.

Defines the remote technical repository manager authenticator.

jaasConfigName

Optional.

Defines the JAAS configuration name for technical use.

Note:
When the RMI server is started and the jaasConfigName parameter is specified, the java.security.auth.login.config system property has to be specified with the JAAS configuration file.

accessListFile

Optional.

Defines the path to the file that contains the IP addresses or DNS names of the trusted clients.

Example

The following sample excerpt outlines the configuration settings of the remote service, which are included in the RemoteSSXServer.config file.

port = 31415
authPort = 31416
repoPort = 31417
authPortTech = 31418
repoPortTech = 31419
keyStore = Y:/java/cvs/SIN/SIN_SSX/test/com/softwareag/security/jaas/remote/ssx/localhost.p12
keyStorePass = 123456	
keyStoreType = PKCS12
rmiHostName = my_server
jaasConfigName = SSXLoginOpenLDAPTechUserSSL

Top of page

RoleLoginModule

Description

RoleLoginModule provides authorization information using the roles/permissions storage. The module is implemented according to the JAAS standards. The current user that is already successfully authenticated by other login modules from the chain, is searched in the storage by the fully qualified name. Also, if any of the previous login modules in the chain provides group membership of the user, this login module looks in the storage for the groups and concatenates permissions assigned to the group to the user's permissions. The login module updates already existing SagUserPrincipal with the permissions assigned to the current user (direclty assigned or coming from the groups on which is member). Additionally, SagRolePrincipal is created for each role on which the user is member and all of those SagPrincipal objects are attached to the Subject.

Note:
Permissions are added as properties of SagUserPrincipal with key name "permissions".

This module recognizes the following configuration options:

Parameter Description
provider_class=my.provider.class

Optional.

Full class name of the role provider that should be used.

The default is FileBasedAuthzStoreImpl.

storage_location="C:/tmp/roles.txt"

Location of the roles storage.

For FileBasedAuthzStoreImpl that is the full path to the roles file.

Example

Sample Configuration is shown below:

Default {
   // SSOS login module for SAML signed assertion validation
   com.softwareag.security.idp.saml.lm.SAMLAssertValidatorLoginModule sufficient;
   
   // Internal repository login module (java based)
   com.softwareag.security.jaas.login.internal.InternalLoginModule required
       template_section=INTERNAL
       logCallback=true
       internalRepository="C:/SoftwareAG/conf/users.txt"
       create_group_principal=true
       groupRepositoryPath="C:/SoftwareAG/conf/groups.txt";

   // Role repository login module
   com.softwareag.security.authz.store.jaas.login.RoleLoginModule optional
       storage_location="C:/SoftwareAG/conf/roles.txt";
  }; 

Top of page

Single Sign-On Service

The Single Sign-On (SSO) service issues and parses a signed SAML assertion that can be used as a single sign-on and delegation token. The default implementation uses the SAML 2 assertion issuance, however SAML 1.1 version is supported as well.

The bundles required for the SSO service are available within all Software AG Common Platform profiles. The SSO service requires a dynamic configuration properties file in order to work correctly. By default, your installation contains a com.softwareag.sso.pid.properties file located under <Software AG_install_directory>/profiles/<profile_name>/configuration/com.softwareag.platform.config.propsloader.

Dynamic Configuration Settings

The following table outlines the parameters of the SSO service dynamic configuration.

Parameter Description
com.softwareag.security.idp.keystore.location

Specifies the location of the keystore to be used.

Default value is "/common/conf/keystore.jks".

com.softwareag.security.idp.keystore.password

Optional.

Specifies the password for the keystore to be used.

com.softwareag.security.idp.keystore.type

Optional.

Specifies the type of the keystore.

Valid values are:

  • "PKCS7"

  • "PKCS12"

  • " JKS" - Default value.

com.softwareag.security.idp.keystore.keyalias

Specifies the key alias to use for signing.

Default value is "ssos".

com.softwareag.security.idp.truststore.location

Optional.

Specifies the truststore to be used.

com.softwareag.security.idp.truststore.password

Mandatory only if the com.softwareag.security.idp.truststore.location parameter is specified.

Specifies the truststore password.

com.softwareag.security.idp.truststore.type

Mandatory only if the com.softwareag.security.idp.truststore.location parameter is specified.

Specifies the truststore type.

Valid values are:

  • "PKCS7"

  • "PKCS12"

  • " JKS" - Default value.

com.softwareag.security.idp.truststore.keyalias

Specifies the truststore key alias.

Default value is "ssos".

com.softwareag.security.idp.assertion.lifeperiod

Specifies the time to live for the issued assertion (in milliseconds).

Default value is "300".

com.softwareag.security.idp.ehcache.location

Location in which to cache the configuration used for caching incoming SAML assertions.

Top of page