Page tree

In order to configure the authentication for Compound Registration, the following sections have to be overridden in the file. This file has to be placed in $REGISTRYCXN_HOME/config  directory.

Compound Registration supports the following authentication methods:

  • Local (through Compound Registration's login page)
    • Database
    • LDAP
    • Active Directory
  • Single Sign-On
    • SAML
    • OAuth2

Global Settings

The web client authentication mode can be configured using the following setting in the property file: 

Authentication mode configuration
#available options: local, samlsso, oauth2

The application features a solution against cross-site request forgery attacks, which can be switched on/off.

CSRF setting
#CSRF protection

LDAP and Active Directory

The different authentication modes can be simply set to enabled or disabled. Whenever an authentication fails against one of them it is retried with the next enabled one. If none of them succeed then the authentication itself fails, otherwise it is successful. RegAuthDBEnabled, RegAuthLdapEnabled and RegAuthADEnabled are controlling the enabled state of the corresponding authentication modes. The other parameters define the usual LDAP/AD settings; for further details on their expected values please consult the LDAP configuration guide. RegAuthLdapReadGroupFromDB controls whether the group membership configuration of the users exists within LDAP or not. If it does exist, the given group membership information is used, otherwise all the users have to be registered in the local database as well, and the corresponding group membership information configured. As a side effect there would exist the same users defined in local database, therefore it is highly recommended to switch off the RegAuthDBEnabled setting to be able to authenticate against LDAP in these special cases.

Local and LDAP/AD settings
#DB Authentication

#LDAP authentication
# Should read the groups from the registration db instead of LDAP?
# The LDAP user who has rights to search the tree
# What search to execute to find the user who wants to log in. The substituted parameter is the login name.
# Defines the part of the directory tree under which group searches should be performed.
# The filter which is used to search for group membership. Example: uniqueMember={0}, corresponding to the groupOfUniqueMembers LDAP class. In this case, the substituted parameter is the full distinguished name of the user. The parameter {1} can be used if you want to filter on the login name.
# The filter which is used to list eligible users for compound registration
# The attribute which contains the name of the authority defined by the group entry. Defaults to cn
# Convert LDAP group names to uppercase
# The attribute which contains the email address of the authority. Defaults to mail

#AD authentication
# The attribute which contains the email address of the authority. Defaults to mail
# Defines the common part of the directory tree as a root of all searches
# Defines the part of the directory tree under which group searches should be performed.
# Defines the part of the directory tree under which user searches should be performed.
# Defines the search user
# Defines the password of the search user


Compound Registration application can be configured as a SAML service provider.

Required settings

  1. Enable SAML authentication using the RegAuthClientMode property with value samlsso.
  2. Provide the metadata to the Compound Registration, that is configured in your IDP. This can be set using the 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)

  3. Provide an entity ID for the Compound Registration SP (RegAuthSAMLMetadataEntityId property) - this must be 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 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 to provide the necessary password and alias using the properties RegAuthSAMLKeystorePasswordRegAuthSAMLKeystoreAlias and RegAuthSAMLKeystoreAliasPassword

Attribute map settings

You can provide mappings for the user related attributes with the following properties:

RegAuthSAMLUserNameAttribute - username SAML assertion attribute, if this is not empty, it uses this attribute instead of the SAML NameID
RegAuthSAMLGroupAttribute - groups  SAML assertion attribute 
RegAuthSAMLRoleAttribute - roles  SAML assertion attribute 
RegAuthSAMLEmailAttribute - email  SAML assertion attribute 

Signature settings

You can set which SAML request/response should be signed using the following properties:

RegAuthSAMLMetadataSignMetadata - Metadata Response Signed
RegAuthSAMLMetadataWantAssertionSigned - Assertions Signed
RegAuthSAMLMetadataRequestSigned - Metadata Request Signed
RegAuthSAMLMetadataRequireArtifactResolveSigned - Artifact Response Signed
RegAuthSAMLMetadataRequireLogoutRequestSigned - Logout Request Signed
RegAuthSAMLMetadataRequireLogoutResponseSigned - Logout Response Signed

Example configuration

#SAMLSSO authentication
# Metadata settings. For more detailed documentations check the following URL: 
# RegAuthSAMLIdpMetadataFile=classpath:samlIdpMetadata.xml

# Signature settings
# supported: Artifact, POST, PAOS

# Keystore settings
# Attribute mappings

Advanced settings

Authorization priority

Using RegUserRepositoryMode property, the source of roles associated to 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). It's value is a priority list. (e.g. "auth,db” value means that roles that are collected from authentication are prioritised. If no role is collected from authentication, then roles are collected from database)

Authentication for trusted 3rd party clients

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/OAuth2 tokens:

Step 1: Adding trusted 3rd party system to Compound Registration

This is possible by executing a command in the registration install directory: 

./bin/RegistryCxn add-secret
  -client <arg>   The name of the client
  -secret <arg>   The symmetric authentication key


./bin/RegistryCxn add-secret -client inventory-service -secret Inventory123456P@ssw0rd

Step 2: Access Compound Registration
When accessing Compound Registration from a trusted 3rd party system, use Basic-Authentication by adding the following header entries to the registration webservice call:

  1.  "Grant-Type”: “client_credentials”
    This header tells the server, that this call should use the trusted 3rd party authentication method
  2.  “Reg-User” : <username>
    This header contains the delegated user name. It must be the username of a user that exists in Compound Registration. The service will be called with this user (logs, audit data, etc. will refer to this user)
  3. Basic auth token
    This header is a regular basic authentication token generated from the “client" and the “secret" of the trusted client you provided in the command line application when adding the trusted client. For testing purposes, generate the Basic-Auth header entry here.

Please note, login/logout service calls are not needed, as each service call will authenticate itself each time by using the Basic-Authentication header.

Example call:

This service call retrieves the compound registered with id CXN1:

Method: GET
"Grant-Type”: “client_credentials”
“Reg-User”: “admin”
“Authorization": "Basic Y2xpZW50OnNlY3JldA==“