LDAP

Overview

Fusion Metadata Registry can use LDAP as the authorization mechanism

Defining an LDAP connection

Specifying the Connection Details

On the page page Security -> Authentication Service ensure the drop-down states "LDAP". The following fields are presented.

Item	Description
Protocol and hostname	Mandatory Either select ldap or ldaps (LDAP over SSL) in the left-side drop-down. In the input field, enter the server and if necessary port number. E.g. localhost:10389
Base DN	The Base Distinguished Name identifies the entry in the directory from which searches initiated by LDAP clients occur. E.g dc=metdatatechnology,dc=com
Manager DN	The manager DN used for querying the directory server and so this user must have privileges to search the directory. E.g. cn=admin,dc=metdatatechnology,dc=com
Manager Password	The password for the manager account
User Search Base	The starting point the LDAP server uses when searching for users authentication within your directory. This works in tandem with the base DN. E.g A value of "ou=people" would search under "ou=people" under the Base DN "dc=metdatatechnology,dc=com"
User Search Filter	Used to identify the users under the User Search Base by a particular criteria. This is often likely to be: uid={0}
Group Search Base	The starting point the LDAP server uses when searching for groups within your directory. This works in tandem with the base DN. E.g A value of "ou=people" would search for groups under "ou=people" under the Base DN "dc=metdatatechnology,dc=com"
Group Search Filter	Used to identify the groups under the Group Search Base by a particular criteria. E.g. member={0}
Role Prefix	An optional prefix which will be prepended to Granted Authority values loaded from the directory.
UserID Attribute	Mandatory This is used to determine what value a user should be displayed as. It is likely this value will be uid

Once the LDAP server has been set up correctly you should find that attempts to logon as a user from your LDAP directory may be refused permission due to lack of permissions. The next step is to set up Role Mappings

Role Mappings

On the page page Security -> Role Mappings you will need to define what a group in your LDAP directory will have permission to perform. The permissions are:

• Administrator privileges - user may perform all tasks
• Agency privileges - the ability to provide structural metadata for a particular agency
• Data Provider privileges - the ability to provide data for a particular Data Provider
• Data Consumer privileges - the ability to consume data for a particular Data Consumer

As single user can be given as many privileges as necessary.

To give an example of how a mapping should be used, suppose users exist in your LDAP system which are members of the group "STRUC_MAINTAINERS". You want all of the users in this group to be able to create and modify SDMX, BIS and ECB structural metadata. On the FMR Role Mappings page, create a group with the name "STRUC_MAINTAINERS" and assign this group to Agencies SDMX, BIS and ECB. All users now should find that they have permission to modify structural metadata for those agencies.

More information on Role Mappings can be found on this page.

Troubleshooting

If you are having issues connecting to LDAP, please look at the logs of FMR. To aid in this, you may wish to increase the logging level of the LDAP connectors. Please add the following loggers to the file: logback.xml to set the logging to DEBUG for Spring classes

<logger name="org.springframework.security" level="DEBUG" additivity="false">
    <appender-ref ref="STDOUT" />
</logger>
<logger name="org.springframework.ldap" level="DEBUG" additivity="false">
    <appender-ref ref="STDOUT" />
</logger>

Example using OpenLDAP Docker Image

The following gives a concrete example of setting up FMR to communicate with an existing OpenLDAP instance.

Obtaining the OpenLdap Docker Image

A Docker OpenLdap instance is available and for more information can be found at: https://github.com/rroemhild/docker-test-openldap

The command to create and run the docker instance is:

 docker run --rm -p 10389:10389 -p 10636:10636 rroemhild/test-openldap

Docker Instance Users and Groups

Within this docker instance there are:

- 2 groups in the OpenLDAP system: "admin_staff" and "ship_crew" - 2 users in "admin_staff": "professor" and "hermes" - 3 users in "ship_crew": "fry", "bender" and "leela"

For convenience everyone's password is the same as their UID. These credentials will be used to login to the Registry.

Setting up the Registry

Specify the following connection values on the page Security -> Authentication Service

Security Service: LDAP

ldap:// localhost:10389

Base DN dc=planetexpress,dc=com

Manager DN cn=admin,dc=planetexpress,dc=com

Manager Password GoodNewsEveryone

User Search Base ou=people

User Search Filter uid={0}

Group Search Base ou=people

Group Search Filter member={0}

Role Prefix <blank>

UserID Attribute uid

Alternatively, use POSTMAN with the following values:

• POST: http://localhost:8080/FusionRegistry/ws/secure/settings/security/authservice
• Auth: root / password
• Body:

{"authType":"ldap","ldapServer":"ldap://localhost:10389","baseDn":"dc=planetexpress,dc=com","userSearchBase":"ou=people","userSearchFilter":"uid={0}","groupSearchBase":"ou=people","groupSearchFilter":"member={0}","rolePrefix":"","userID":"uid","managerDn":"cn=admin,dc=planetexpress,dc=com","managerPwd":"GoodNewsEveryone"}

Testing Using Fusion Metadata Registry

• Set up the LDAP connection as stated above
• Create a Role Mapping called "ship_crew"
• Assign the Role Mapping "ship_crew" to the Agency SDMX
• In another browser logon as "fry"
• Note how this user can only edit SDMX structures
• Edit the Role Mapping so that "ship_crew" is now an administrator
• In the other browser, log off and the log on as "fry".
• Note this user is now an administrator