Security Infrastructure (SIN) provides default login modules.
You can use the default modules to do the following:
Authentication, role, user, and group management
Support additional backend authentication systems
Exchange credentials through the SharedStateMap
for internal SSO
The default modules are as follows:
For more information about deprecated login modules in Security Infrastructure, see Deprecated Login Modules
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:
Extend it to create your own login modules.
Create the SagUserPrincipals with the
information stored in the shared map through the authentication process.
When setting up the JAAS configuration, keep in mind the following basics:
The SIN-based login contexts return zero or only one
SagUserPrincipal if the authentication succeeds. When
setting up the JAAS configuration, keep in mind that some applications expect
only one SagUserPrincipal as the result of a successful
authentication. If your application expects more than one user principal, you
must configure the login context accordingly.
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, so you must
store the password only if needed.
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.
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
|
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:
|
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 *
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";
};
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:
Lightweight Directory Access Protocol (LDAP)
Active Directory acting as an LDAP server
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 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 |
domain |
Optional. String. Specifies the domain name to be used for authentication.
Applicable if the domain concept is activated for the
|
noPrinIsAnonymous |
Optional. When Valid values are:
|
prin |
Required only if 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 Specifies the password of the technical user that connects to
the LDAP server. You use it together with the A valid value is any string of characters. |
credHandle |
Can be used instead of |
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:
|
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 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:
|
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
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 Valid values are:
|
createGroups |
Optional. Boolean. Specifies whether to extract the groups of the logged-in user from the LDAP server. Valid values are:
|
createUserProperties |
Specifies whether user properties should be populated to SagUserPrincipal. Valid values are:
|
createGroupProperties |
Specifies whether group properties should be populated to SagGroupPrincipal. Valid values are:
|
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. |
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";
};
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.
None.
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";
};
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.
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:
|
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";
};
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.
None.
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";
};
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.
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 |
netegrity_siteminder_prop_name |
Optional. Defines the name of the Netegrity SiteMinder property. The
default value is |
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;
};
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
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
|
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.
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.
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:
|
check_crl_status |
Boolean. The following list outlines the possible options:
|
crl_url |
Mandatory if the 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:
|
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:
|
additional_certificates_container_password |
Mandatory only if the
Defines the password of the certificate container. |
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}";
};
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.
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:
|
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;
};
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:
User name and password
User name, password and an IAF token (or IAF artifact)
IAF token (or IAF artifact) only
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:
The module verifies the token against the IAF server.
After verification, the module confirms the token's validity and your user identity.
To use SSXLoginModule
Set sin-common.jar and sin-ssx.jar in the classpath.
Set the <dlls> in
java.library.path.
To configure SSXLoginModule
Configure SSXLoginModule to use RMI
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:
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:
Initially, Security Infrastructure verifies all locally configured settings.
If the OPTIONS_URL parameter is configured,
the functionality attempts to obtain the properties remotely.
If the URL address is configured but the respective properties
cannot be read and verified, the result is null and the login
module is disregarded.
If the remote properties are verified successfully, the functionality overwrites the respective locally set properties.
If the remote file provides properties that are not available in the local settings, then the remote properties are taken into account. However, if the remote file does not provide information about any locally set properties, then the functionality preserves the local settings.
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: |
UseDomainForOptionsURL |
This parameter appends the domain to the value of the
Valid values are:
|
template_section |
The value is a section from the template authentication properties file. Note: Valid values are:
No default value. |
create_user_principal |
Optional. Creates Valid values are:
|
defaultDomainName |
Optional. Specifies the default domain name. If the
No default value. |
CreateGroups |
Optional. Specifies whether the login module creates user groups. Valid values are:
|
CreateGroupProperties |
Optional. Specifies whether the login module creates user group properties. Valid values are:
|
CreateUserProperties |
Optional. Specifies whether the login module creates user properties. Valid values are:
|
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
Specifies key/value pairs for the property mapping. Valid values: X (key and value) runs through all values from "0"
to "( 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. |
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
|
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";
};
The following table outlines the SSXLoginModule
parameters for operating system configuration:
| Parameter | Description |
|---|---|
authType |
Specifies the user database type. The valid value is
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: |
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:
Note: |
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:
|
The following table outlines the SSXLoginModule
custom parameters for ADSI configuration.
| Parameter | Description |
|---|---|
authType |
Specifies the user database type. The valid value is
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. |
The following table outlines the SSXLoginModule
custom parameters for LDAP configuration.
| Parameter | Description |
|---|---|
authType |
Specifies the user database type. The valid value is 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:
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
|
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
|
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
|
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
|
userIdField |
Optional. Specifies the property name that denotes a user entry. Valid values: <String_Value>. The default value is dependent on the
|
groupIdField |
Optional. Specifies the property name that denotes a group entry. Valid values: <String_Value>. The default value is |
allowDomainAsBaseBindDn |
Optional. Boolean. If the domain name is not specified explicitly and the
Valid values are:
|
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:
The default value is dependent on the
|
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:
The default value depends on the
|
ldapStartTls |
Optional. Boolean. Enforces the usage of secure communication (TLS/ SSL). Valid values are:
|
resolveGroups |
Optional. Specifies the method for finding the groups of a user using the LDAP authentication type. Valid values are:
|
computedGroupProp |
Optional. Denotes the name of the LDAP property. It is activated if
Valid values: <String_Value>. No default value. |
ldapSSLConnection |
Optional. Boolean. This parameter denotes the secure communication (with set
Valid values are:
|
followReferrals |
Optional. Boolean. Specifies whether the Valid values are:
|
refServerBindingType |
Optional. Specifies the kind of binding during "referral following". Valid values are:
|
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:
|
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. |
The following table outlines the SSXLoginModule
custom parameters for RMI configuration.
| Parameter | Description |
|---|---|
rmiEnabled |
Optional. Boolean. Specifies whether the Valid values are:
|
rmiServerAddress |
Optional. Specifies the host server for RMI. Use it only if
A valid value is any valid server address. The default value is |
rmiServerPort |
Optional. Specifies the port that the remote server listens. Use it only
if A valid value is any valid server port. No default value. Note: |
throw_exc_missing_remote |
Optional. Boolean. Valid values are:
|
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.
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:
|
signkey_alias |
Optional. Specifies the key alias to use for signing. |
signkey_password |
Mandatory only if it is not the same as
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:
|
rmiEnabled |
Optional. Boolean. Specifies whether Valid values are:
|
rmiServerAddress |
Mandatory only if the Specifies the hostname/IP address of the remote server - “user.sam.ple.com” or “10.3.137.20”. |
rmiServerPort |
Required only if the Specifies the port that the remote server listens to - “12345”. Note: |
rmiSSLEnable |
Mandatory only if the Specifies whether the RMI connection uses SSL or not. |
rmiKeyStore |
Mandatory only if the Specifies the keystore that must be used during the secure RMI communication. |
rmiKeyStorePass |
Mandatory only if the Specifies the keystore password. |
rmiKeyStoreType |
Mandatory only if the Specifies the keystore type. |
rmiTrustStore |
Mandatory only if the Specifies the truststore that must be used during the secure RMI communication. |
rmiTrustStorePass |
Mandatory only if the Specifies the truststore password. |
rmiTrustStoreType |
Mandatory only if the Specifies the truststore type. |
throw_exc_missing_remote |
Optional. Boolean. Valid values are:
|
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:
login() method - always returns
"false".
commit() method - if a previous
SSXLoginModule authenticates the subject, returns
"true". Otherwise, returns "false".
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 |
None. Any provided parameters are ignored.
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;
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.
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. |
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>;
}
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.
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. |
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";
};
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:
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.
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.
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.
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:
The remote repository manager listens on a specified RemoteSSXServer.configport and supports SSL/TLS server authentication.
The manager extracts the subject from the cached context and then it retrieves repository manager from the principal in the Subject.
The server repository manager is used for each remote repository operation and data transfer to the client.
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: |
accessListFile |
Optional. Defines the path to the file that contains the IP addresses or DNS names of the trusted clients. |
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
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. |
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";
};
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.
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:
|
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
Specifies the truststore password. |
com.softwareag.security.idp.truststore.type |
Mandatory only if the
Specifies the truststore type. Valid values are:
|
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. |