Compound Registration supports several authentication methods:
Since these authentication methods have different characteristics, the way how they are customized are different as well:
SAML provides a Single Sign-On interface. In other words, users won't use Compound Registration's login page, they will log in through the identity provider's login page.
Authentication providers setting are stored in registry.properties
file in $
REGISTRYCXN_HOME/config
directory.
registry.properties
file.A server restart is required for SAML property changes to take effect.
As mentioned before authentication-related properties are stored in the registry.properties
file, placed at $REGISTRYCXN_HOME/config
directory.
The first thing to do is to set the "Client Authentication Mode". This refers to the fact if a user logs in through Compound Registration login page or through an external one. Use the value "local" for Database, LDAP and Active Directory authentication methods.
Authentication mode configuration
The different authentication methods can be set to be enabled or disabled. Compound Registration allows using more than one authentication method simultaneously. Whenever an authentication fails, the system tries to authenticate the user against the next available authentication mode. If none of them succeed then the authentication fails, otherwise, it is successful. The following properties are responsible for enabling authentication modes:
Authentication mode configuration
However, to have a fully functional remote authentication system, there are other options that have to be set. The sections below provide the full list of configuration properties that can be set for each authentication mode.
Local and LDAP/AD settings
Deprecated properties after version 16.07.18-795 Local and LDAP/AD settings
Local and LDAP/AD settings
Examples for 'The filter to search for the user being authenticated':
Alternate UPN suffix can be set per user in Active Directory.
In this example, testuser12 has the default system suffix, company.local, and john12 has an alternate suffix, company.com configured.
RegAuthADSearchFilter = (&(objectClass=user)(sAMAccountName={1}))
Login name | Can log in? |
---|---|
testuser12 | yes |
testuser12@company.local | no |
john12 | yes |
john12@company.com | no |
RegAuthADSearchFilter = (&(objectClass=user)(userPrincipalName={0}))
Login name | Can log in? |
---|---|
testuser12 | yes |
testuser12@company.local | yes |
john12 | no |
john12@chemaxon.com | no |
Deprecated properties after version 16.07.18-795 Local and LDAP/AD settings
Compound Registration application can be configured as a SAML service provider.
Required settings
RegAuthClientMode
property with value samlsso
.RegAuthSAMLIdpMetadataFile
property. The value can be an URL or a file that is located in the Tomcat library (in this case you have to use “classpath:” prefix. e.g.: classpath:samlIdpMetadata.xml
)RegAuthSAMLMetadataEntityId
property) - this must be a unique name in the IDP.When you start the Compound Registration application the SAML SP metadata is available on the URL: <HOST>/RegistryCxn/saml/metadata
. In most cases, you can import this in your IDP, contains all the necessary information your IDP needs.
Keystore setup
The keystore file must be located in the Tomcat library, and it can be configured using the RegAuthSAMLKeystoreFile
property. (you have to use “classpath:” prefix. e.g.: classpath:samlKeystore.jks
)
You can provide the necessary password and alias using the properties RegAuthSAMLKeystorePassword
, RegAuthSAMLKeystoreAlias
and RegAuthSAMLKeystoreAliasPassword
Attribute map settings
You can provide mappings for the user-related attributes with the following properties:
Signature settings
You can set which SAML request/response should be signed using the following properties:
Consumer settings
Since version 22.11.0 the expiration time of the SAML authentication statement is configurable with a new parameter: RegAuthSAMLMaxAuthenticationAge (default value is 7200 seconds).
Example configuration
Compound Registration application can be configured as a SAML service provider.
Required settings
RegAuthClientMode
property with value samlsso
.RegAuthSAMLIdpMetadataURL
property. The value can be an URL or a file that is located in the Tomcat library (in this case you have to use “classpath:” prefix. e.g.: classpath:samlIdpMetadata.xml
)RegAuthSAMLMetadataEntityId
property) - this must be a unique name in the IDP.<scheme>://<host>:<port>/RegistryCxn/login/saml2/sso/compreg
as the login URLWhen you start the Compound Registration application the SAML SP metadata is available on the URL: <HOST>/RegistryCxn/saml2/service-provider-metadata/{registrationId}
(registrationId
- is a fixed value, it represents the SP-IDP relation, in this case, its value is compreg
). In most cases, you can import this in your IDP, contains all the necessary information your IDP needs.
Keystore setup
The keystore file must be located in the Tomcat library, and it can be configured using the RegAuthSAMLKeystoreFile
property. (you have to use “classpath:” prefix. e.g.: classpath:samlKeystore.jks
)
You can provide the necessary password and alias using the properties RegAuthSAMLKeystorePassword
, RegAuthSAMLKeystoreAlias
and RegAuthSAMLKeystoreAliasPassword
Attribute map settings
You can provide mappings for the user-related attributes with the following properties:
Signature settings
You can set which SAML request/response should be signed using the following properties:
Example configuration
For trusted 3rd party systems the username/password authentication can be omitted by using a symmetric key authentication. This way 3rd party systems can use our REST API with basic authentication, without the need of SAML tokens:
Adding trusted 3rd party system to Compound Registration
This is possible by running a command in the registration install directory:
Example:
The application features a solution against cross-site request forgery attacks, which can be switched on/off. CSRF setting
Authorization priority is deprecated after Compound Registration version 19.7.1.
Using RegUserRepositoryMode
property, the source of roles associated with the authenticated user can be specified. (e.g. if you have a user in both SAML and local DB, upon successful SAML authentication it can keep its roles collected from SAML or it can have the roles stored in the database). Its value is a priority list. (e.g. "auth,db” value means that roles that are collected from authentication are prioritized. If no role is collected from authentication, then roles are collected from the database)