Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Minor corrections to text

...

How to set up an LDAP configuration

...

Carry out the following steps:

  1. Set up the basic LDAP configuration
  2. Set up the authentication
  3. Set up the authorization

...

There are some configuration items that configure the ldap LDAP realm. These items can not cannot be changed with the Account Management in JOC.

KeyValueDescription
ldapReam
com.sos.auth.shiro.SOSLdapAuthorizingRealm

The key is the name of the realm. You can define any name. The name is taken as a reference to set the properties of the realm.

The value is the name of the class that implements the realm. The implementation from SOS extends org.apache.shiro.realm.ldap.JndiLdapRealm

Please note that you can have more than one ldap LDAP configuration.

ldapRealm.contextFactory.url
ldap://host:port

The host and the port of your LDAP server. You can check whether the server is reachable with telnet host port

Make sure that the firewall is open for the given port.

ldapRealm.useStartTls
true|false

To enable starttls set the value to true (Default is false)

Please note the the server must be prepared to serve with Starttls. To check this, you can use a LDAP browser like "Softerra LDAP Browser". Configure your LDAP Server there and click the "Enable Starttls Button"

On Client Site client site you will need the certificate and you have to add the certificate to your truststore. The path of your truststore is definied defined in the JOC configuration file joc.properties configuration file.

truststore_path = path to your truststore.

e.g.

  • C:/Program Files/Java/jdk1.8.0_131/jre/lib/security/cacerts or
  • ../../etc/joc.jks
ldapRealm.hostNameVerification   
on|off true|falseTo enable the host name verification of the certificate. The default is off.
rolePermissionResolver  
com.sos.auth.shiro.SOSPermissionResolverAdapter
The implementation of the permission resolver. The SOS implementation sets an  org.apache.shiro.realm.text.IniRealm to resolve the permissions. That means that the permissions a role have are specified in the configuration file shiro.ini in the same way it is done when using the iniRealm.
ldapRealm.rolePermissionResolver 
$rolePermissionResolver
Sets the role permission resolver for the ldap LDAP realm.
securityManager.realms 
$ldapRealm

Sets the list of realm that should be used for authentication. This is a comma seperated separated list of realms.

e.g.

  • $ldapRealm --> Only one realm specified
  • $ldapRealm, $iniRealm  --> You can login with a user from LDAP or with a user specified in the [users] section in the configuration file shiro.ini
  • $ldapRealm1,$ldapRealm2  --> You can login with a user coming from the LDAP server specified in the ldap1 realm or coming from the LDAP server coming from LDAP server specified in the ldap2 realm.

     

 

...

  • username@domain
  • domain\username
  • username

The username may have blanks blank spaces if they are stored in a LDAP directory. Usernames stored in the configuration file shiro.ini configuration file may not have blankscontain blank spaces.

When referring to usernames from the LDAP directory to keys in the [users] section to assign roles to the user, you have to change blanks to %20. The password must be empty. When you login with a domain the reference must contain the whole domain/username pattern e.g. user@domain

The JOC Account Manager will consider considers the handling of blanks. Please note that you have to specify the user with the domain in the JOC Account Manager and without password.

...

ldapsearch -h localhost -p 389 -b "uid=ur,ou=People, dc=sos" -x

Should This should give a result likesuch as:

Code Block
titleResult: ldapsearch -h localhost -p 389 -b "uid=ur,ou=People, dc=sos" -x
collapsetrue
# ur, People, sos
dn: uid=ur,ou=People,dc=sos
mail: uwe.risse@sos-berlin.com
uid: ur
givenName: Uwe
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Risse
cn: Uwe Risse
preferredLanguage: de
# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Example with

...

a public server

ldapsearch -h ldap.forumsys.com -p 389 -b "uid=gauss,dc=example,dc=com" -x

...

Authorization means the assignment of roles to users. A role have permissions that are listed in the shiro.ini configuration file. A user have has all permissions coming from the assigned roles.

There are two options how to assigns roles for assigning Roles to users. Both options can be mixed. The result of the mix is the union of all assigned rolesRoles.

Assigning roles in the shiro.ini File

The roles Roles assignment in the shiro.ini file is managed with configured in the Manage Accounts view of the JOC Account ManagerCockpit.

The JOC Account Manager writes the roles assigned roles to an entry are saved in the [users] section of the shiro.ini configuration file.

In the [users] section you list the users that are available in the LDAP. 

...

Please refer to the chapter "Username" to see how to specify the username.

The list_of_roles is a comma separated list of roles e.g. it_operator,administrator

...

 

The groupSearchFilter is attr=val where attr is name of the attribute and val is the content where the userid is replaced with %s. In this example

...

This search should return the group entries the user is a member. Please identify the attribute that contains containing the group name that should is to be used in the user roles mapping.

...

Hint: Please note that the whole content of this attribute must be used in the groupRolesMap attribute. Sometimes here is something like Typical contents of the attribute could be ou=Groups, dc=sos, cn=groupname . Please take the whole value for the mapping.

...

This search should return the user with the given username. Please identify the attribute that should be used for the substitution in the group search base if it is not the username from the login.

Code Block
languagetext
titleUsername Substitution
collapsetrue
# extended LDIF
#
# LDAPv3
# base <ou=People,dc=sos> with scope subtree
# filter: uid=fTester
# requesting: ALL
#

# fTester, People, sos
dn: uid=fTester,ou=People,dc=sos
mail: info@sos-berlin.com
uid: fTester
givenName: Fritz
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Tester
cn: Fritz Tester

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

 

...

Then identify the name of the attribute that contains the value for the substitution. E.g.For example:

  • ldapRealm.userNameAttribute = cn

The whole configuration looks like this

...