LDAP - Revision history

Vmurrell at 15:06, 12 September 2024

2024-09-12T15:06:23Z

Vmurrell: /* Specifying the Connection Details */

2024-09-12T15:05:59Z

‎Specifying the Connection Details

Vmurrell: /* Overview */

2024-09-12T14:54:38Z

‎Overview

Vmurrell at 14:54, 12 September 2024

2024-09-12T14:54:24Z

Vmurrell: Created page with "Category:RegistrySecurity Coming soon."

2024-09-12T13:39:26Z

Created page with "Category:RegistrySecurity Coming soon."

New page

[[Category:RegistrySecurity]]

Coming soon.

← Older revision		Revision as of 15:06, 12 September 2024
Line 47:		Line 47:

	The next step is to set up [[Fusion_Security_Manager_(FR_V11) \|Fusion Security Manager.]]		The next step is to set up [[Fusion_Security_Manager_(FR_V11) \|Fusion Security Manager.]]
−
−	~~== 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 [[Active_Directory_-_Set_up_Role_Mappings\|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
−
−	~~<pre>~~
−	~~<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>~~
−	~~</pre>~~
−
−	~~= 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:'''
−	~~<pre>~~
−	{"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"}
−	~~</pre>~~
−
−	~~== 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

@@ Line 44: / Line 44: @@
 |}
-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
+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.
 == Role Mappings ==

@@ Line 2: / Line 2: @@
 = Overview =
-Fusion Metadata Registry can use LDAP as the authorization mechanism
+Fusion Registry can use LDAP as the authorization mechanism
 = Defining an LDAP connection =

← Older revision		Revision as of 14:54, 12 September 2024
Line 1:		Line 1:
	[[Category:RegistrySecurity]]		[[Category:RegistrySecurity]]
		+	= Overview =

−	~~Coming soon~~.	+	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.
		+
		+	{\| class="wikitable"
		+	!\| 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 [[Active_Directory_-_Set_up_Role_Mappings\|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
		+
		+	<pre>
		+	<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>
		+	</pre>
		+
		+	= 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:'''
		+	<pre>
		+	{"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"}
		+	</pre>
		+
		+	== 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