Difference between revisions of "SUNScholar/Researcher Authorisation/Step 2"

From Libopedia
Jump to navigation Jump to search
Line 204: Line 204:
 
'''Please note:''' The above configuration uses the insecure LDAP port '''389''', you may want to test using the insecure port of '''389''' and then move to the secure port of '''636'''.
 
'''Please note:''' The above configuration uses the insecure LDAP port '''389''', you may want to test using the insecure port of '''389''' and then move to the secure port of '''636'''.
 
----
 
----
 +
[[Category:Customisation]]

Revision as of 11:33, 28 May 2016

NEXT - STEP 3

PLEASE NOTE:

During the upgrade from DSpace 1.8.2 to 3.2, the ldap config changed and it seems a bug was introduced: https://jira.duraspace.org/browse/DS-1781.

Take special note of the "netid_email_domain = @example.com" parameter at the bottom of the file.

If you do not specify an @example.com email suffix, then you will get null suffix errors for eperson email addresses.

Step 2 - DSpace configuration

Step 2.1 - Enable LDAP

Edit the following file:

nano $HOME/source/dspace/config/modules/authentication.cfg

Add LDAP authentication, see example below.

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
	org.dspace.authenticate.LDAPAuthentication, \
	org.dspace.authenticate.PasswordAuthentication

Step 2.2 - Configure LDAP

Now modify the ldap config file as follows.

nano $HOME/source/dspace/config/modules/authentication-ldap.cfg

See example config below.

#---------------------------------------------------------------#
#------------LDAP AUTHENTICATION CONFIGURATIONS-----------------#
#---------------------------------------------------------------#
# Configuration properties used by the LDAP Authentication      #
# plugin, when it is enabled.                                   #
#---------------------------------------------------------------#
#
# In order to enable LDAP Authentication, you must first ensure the
# 'org.dspace.authenticate.LDAPAuthentication'
# class is added to the list of enabled AuthenticationMethods in 'authenticate.cfg'.  
# See 'authenticate.cfg' for more info.
#
# If LDAP is enabled, then new users will be able to register
# by entering their username and  password without being sent the
# registration token. If users do not have a username and password,
# then they  can still register and login with just their email address
# the same way they do now.
#
# For providing any special privileges to LDAP users,
# you will still need to extend the SiteAuthenticator class to
# automatically put people who have a netid into a special
# group.  You might also want to give certain email addresses
# special privileges. Refer to the DSpace documentation for more
# information about how to do this.
#
# It may be necessary to obtain the values of these settings from the
# LDAP server administrators as LDAP configuration will vary from server
# to server.

# This setting will enable or disable LDAP authentication in DSpace.
# With the setting off, users will be required to register and login with
# their email address.  With this setting on, users will be able to login
# and register with their LDAP user ids and passwords.
# This setting is only used by the JSPUI.
enable = true


##### LDAP AutoRegister Settings #####

# This will turn LDAP autoregistration on or off.  With this
# on, a new EPerson object will be created for any user who
# successfully authenticates against the LDAP server when they
# first login.  With this setting off, the user
# must first register to get an EPerson object by
# entering their ldap username and password and filling out
# the forms.
autoregister = false


# This is the url to the institution's ldap server. The /o=myu.edu
# may or may not be required depending on the LDAP server setup.
# A server may also require the ldaps:// protocol.
#provider_url = ldap://ldap.myu.edu/o=myu.edu
provider_url = ldap://stbldap01.sun.ac.za:389
provider_url = ldap://stbldap02.sun.ac.za:389

# This is the unique identifier field in the LDAP directory
# where the username is stored.
#id_field = uid
id_field = cn

# This is the object context used when authenticating the
# user.  It is appended to the id_field and username.
# For example uid=username,ou=people,o=myu.edu.  This must match
# the LDAP server configuration.
#object_context = ou=people,o=myu.edu
object_context = ou=USERS,o=SU

# This is the search context used when looking up a user's
# LDAP object to retrieve their data for autoregistering.
# With autoregister turned on, when a user authenticates
# without an EPerson object, a search on the LDAP directory to
# get their name and email address is initiated so that DSpace
# can create a EPerson object for them.  So after we have authenticated against
# uid=username,ou=people,o=byu.edu we now search in ou=people
# for filtering on [uid=username].  Often the
# search_context is the same as the object_context
# parameter.  But again this depends on each individual LDAP server
# configuration.
#search_context = ou=people
search_context = ou=USERS,o=SU

# This is the LDAP object field where the user's email address
# is stored.  "mail" is the default and the most common for
# LDAP servers.  If the mail field is not found the username
# will be used as the email address when creating the eperson
# object.
email_field = mail

# This is the LDAP object field where the user's last name is
# stored.  "sn" is the default and is the most common for LDAP
# servers.  If the field is not found the field will be left
# blank in the new eperson object.
surname_field = sn

# This is the LDAP object field where the user's given names
# are stored.  This may not be used or set in all LDAP instances.
# If the field is not found the field will be left blank in the
# new eperson object.
givenname_field = givenName

# This is the field where the user's phone number is stored in
# the LDAP directory.  If the field is not found the field
# will be left blank in the new eperson object.
phone_field = telephoneNumber


##### LDAP users group #####

# If required, a group name can be given here, and all users who log in
# to LDAP will automatically become members of this group. This is useful
# if you want a group made up of all internal authenticated users.
login.specialgroup = Maties


##### Hierarchical LDAP Settings #####

# If your users are spread out across a hierarchical tree on your
# LDAP server, you will need to search the tree to find the full DN of
# the user who is logging in.
#
# * If anonymous search is allowed on your LDAP server, you will need to set
#   search.anonymous = true
# * If not, you will need to specify the full DN and password of a 
#   user that is allowed to bind in order to search for the users.
# * If neither search.anonymous is true, nor search.user is specified,
#   LDAP will not do the hierarchical search for a DN and will assume
#   a flat directory structure.

# This is the optional search scope value for the LDAP search during
# autoregistering. This will depend on your LDAP server setup.
# This value must be one of the following integers corresponding
# to the following values:
# object scope : 0
# one level scope : 1
# subtree scope : 2
#search_scope = 2

# If true, the initial bind will be performed anonymously.
search.anonymous = false

# The full DN and password of a user allowed to connect to the LDAP server
# and search for the DN of the user trying to log in.
#search.user = cn=admin,ou=people,o=myu.edu
#search.password = password

# If your LDAP server does not hold an email address for a user, you can use
# the following field to specify your email domain. This value is appended
# to the netid in order to make an email address. E.g. a netid of 'user' and
# netid_email_domain as '@example.com' would set the email of the user
# to be 'user@example.com
netid_email_domain = @sun.ac.za

# Take the left part of the groupmap value (before the ":") and look it up
# in user's full DN. If it's found, assign user to the DSpace group
# specified by the right part of the groupmap value (after the ":").
# One user may belong to multiple groups.
#login.groupmap.1 = ou=ldap-dept1:dspace-group1
#login.groupmap.2 = ou=ldap-dept2:dspace-groupA
#login.groupmap.3 = ou=ldap-dept3:dspace-groupA

# If this property is uncommented, it changes the meaning of the left part of
# the groupmap value (before the ":") as follows.
# The value of login.groupmap.attribute specifies the name of an LDAP attribute.
# If user has this attribute, look up the value of this attribute in the left
# part of the groupmap value (before the ":"). If it's found, assign user to
# the DSpace group specified by the right part of the groupmap value (after
# the ":").
#login.groupmap.attribute = group
#login.groupmap.1 = ldap-dept1:dspace-group1
#login.groupmap.2 = ldap-dept2:dspace-groupA
#login.groupmap.3 = ldap-dept3:dspace-groupA

Please note: The above configuration uses the insecure LDAP port 389, you may want to test using the insecure port of 389 and then move to the secure port of 636.