Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: 'Authorization' updated

...

This article describes the configuration of the JOC Cockpit to use an LDAP Server for Authentication. This configuration is done in the JOC Cockpit's shiro.ini file whose overall configuration is described in the Authentication and Authorization - Configuration article. A general introduction to authentication and authorization in the JOC Cockpit is provided in the JOC Cockpit - Authentication and Authorization article.

Anchor
public
public
A Simple LDAP Test Configuration

A public LDAP server which can be accessed using a relatively simple configuration is available from Forum Systems. This server can be used to set up a test environment with LDAP authentication. In this article we will refer to the authentication of two user accounts on this server - gauss and newton - that are each members of a different LDAP group as shown in the following table:

Account NamePasswordLDAP GroupShiro Role
gausspasswordmathematicians

all

newtonpasswordscientistsit_operator

To configure a realm implement the authentication configuration - or realm - for accessing this public LDAP server, add the following lines to the [main] section of the shiro.ini file, either before or after the default line:

  • securityManager.sessionManager.globalSessionTimeout = 1200000900000

 

Code Block
titlePublic LDAP Server
linenumberstrue
publicLdapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm

publicLdapRealm.userDnTemplate = uid={0},dc=example,dc=com
publicLdapRealm.searchBase = dc=example,dc=com
publicLdapRealm.contextFactory.url = ldap://ldap.forumsys.com:389

publicLdapRealm.groupNameAttribute = ou
publicLdapRealm.userNameAttribute = uid

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm

publicLdapRealm.rolePermissionResolver = $rolePermissionResolver
publicLdapRealm.userSearchFilter = (uniqueMember=uid=%s,dc=example,dc=com)
publicLdapRealm.groupRolesMap = \
  scientists : it_operator, \
  mathematicians: all

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm

securityManager.realms = $publicLdapRealm, $iniRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

...

The LDAP group memberships will be mapped onto the default roles configured in the shiro.ini [roles] section as can be seen in lines 15-17 of the code listing above. This can be checked in the JOC Cockpit by looking at the Permissions section of the relevant User Profiles - the User Account gauss, for example, will have all permissions.

Verification with ldapSearch

In all ldapSearch examples the option -x is used. It is possible that your LDAP Server does not allow this and you have to specify a user and a password such as:

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

How to set up an LDAP configuration

Carry out the following steps:

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
  4. Set up the basic LDAP configuration
  5. Set up the authentication
  6. Set up the authorization

...

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 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 such as the "Softerra LDAP Browser". Configure your LDAP Server there and click the "Enable Starttls Button"

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

truststore_path = path to your truststore.

Example values:

  • C:/Program Files/Java/jdk1.8.0_131/jre/lib/security/cacerts or 
  • ../../etc/joc.jks

Note:

we have had difficulties with using starttls with the JRE1.8.0_151 and have overcome these by installing a JDK.

ldapRealm.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 realm.
securityManager.realms 
$ldapRealm

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

Example values:

  • $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 specified in the ldap2 realm.

...

Anchor
authentication
authentication

2. Authentication

The user template

With the authentication you will check for a valid username/password combination. To achieve this, you have to specify the userDnTemplate. The value parameters for the userDnTemplate can be read from the from a user's properties page of an useras shown in the screenshot from an LDAP browser below.

Anchorusernameusername

Username

The username is part of the login patterns:

  • username@domain
  • domain\username
  • username

...

For the User in the screenshot the template would be (replacing the uid with {0}):

  • ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos

Only one template can be specified per realm, separate realms have to be configured for different user templates.

Anchor
username
username

Usernames

The username can have one of the following login patterns:

  • username@domain
  • domain\username
  • username

Note that LDAP Usernames may contain blank spaces. See the Authorization section below for a description of how blank spaces are handled when LDAP authentication is used in together with Shiro authorization.

Configuration in the shiro.ini

...

file

...

The [main] section of the shiro.ini file with authentication for the example ur User from the screenshot above is shown in the next code block:

Code Block
languagetext
titleuserDnTemplate configuration
linenumberstrue

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 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.

Configuration in the shiro.ini file

Main section with the user authentication. The roles are assigned in the [users] section.

code
collapsetrue
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
securityManager.sessionManager.globalSessionTimeout = 900000

Examples for the userDnTemplate

  • Example for the ur User
    • ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos

  • Configuration with for the public LDAP Server mentioned at the start of this article
    • publicLdapRealm.userDnTemplate = uid={0},dc=example,dc=com

...

    • adLdapRealm.userDnTemplate = sAMAccountName={0},dc=company,dc=com

Verification with ldapSearch

You can check you userDnTemplate with this ldapSearchCommand. the userDnTemplate by integrating it in a command for the ldapSearch utility such as:

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

This should give a result such as:

Code Block
languagetext
titleResult: ldapsearch -h localhost -p 389 -b "uid=ur,ou=People, dc=sos" -x
linenumberstrue
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

...

for the public server

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

Code Block
languagetext
titleldapsearch -h ldap.forumsys.com -p 389 -b "uid=gauss,dc=example,dc=com" -x
linenumberstrue
collapsetrue
# extended LDIF
#
# LDAPv3
# base <uid=gauss,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
 
# gauss, example.com
dn: uid=gauss,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Carl Friedrich Gauss
sn: Gauss
uid: gauss
mail: gauss@ldap.forumsys.com
 
# search result
search: 2
result: 0 Success
 
# numResponses: 2
# numEntries: 1

 

Verification with Softerra LDAP Browser

Search with Search-Dn=userDnTemplate. You should find exactly one entry.

Image Removed

Verification with JOC

Try to login with a username from LDAP and a password. Use a username for which you have verified is correct by executing the ldapSearch described above. When you see this screen, the authentication works.

Image Removed

...

3. Authorization

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

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

Assigning roles in the shiro.ini File

Roles assignment in the shiro.ini file is configured in the Manage Accounts view of the JOC Cockpit.

Image Removed

The roles assigned 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. 

username = ,list_of_roles

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

Here is a typical configuration with LDAP Authentication and shiro.ini authorization.

Code Block
titleLDAP Authentication and shiri.ini Authoriziation
collapsetrue
[users]
gauss = ,all
newton = ,it_operator,administrator

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
securityManager.sessionManager.globalSessionTimeout = 900000

 

...

Note: ldapSearch Parameters

The option -x is used in all the ldapSearch examples in this artricle. It is possible that your LDAP Server does not allow this and you have to specify a user and a password in which case the command would be:

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

 

Verification with Softerra LDAP Browser

Search with Search-Dn=userDnTemplate. You should find exactly one entry.

Image Added

Verification with the JOC Cockpit

Try to login with an LDAP username:password combination. Use a username for which you have verified is correct by executing the ldapSearch described above. If there are no role(s) configured for the user but the authentication works you will see the following:

Image Added

Anchor
authorization
authorization

3. Authorization

Authorization is the assignment of Roles to User Accounts. Roles, in turn, have permissions that are listed in the shiro.ini configuration file. A User has the sum of all the Permissions coming from the Roles they have been assigned.

There are two options for assigning Roles to Users: with an LDAP Group to Shiro Role mapping and with a Shiro User Account. Both options can be combined. The result is a combination of - i.e. the union of - all assigned Roles.

Assigning roles in the shiro.ini File

Roles assignment in the shiro.ini file is configured in the Manage Accounts view of the JOC Cockpit. Do not enter a Password for a User Account that is to be authenticated by an LDAP server. 

Image Added

The roles assigned 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. 

username = ,list_of_roles

Please refer to the "Username" section above to see how to specify the username.

The list_of_roles is a comma separated list of Roles such as:

  • it_operator,administrator

Here is a typical configuration with LDAP Authentication and Shiro authorization.

Code Block
languagetext
titleLDAP Authentication and shiri.ini Authoriziation
linenumberstrue
collapsetrue
[users]
gauss = ,all
newton = ,it_operator,administrator

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
securityManager.sessionManager.globalSessionTimeout = 900000

Note that LDAP Usernames may contain blank spaces, while Shiro User names may not. The following applies if an LDAP User is to use Shiro authorization to allocate Roles:

  • The username may have blank spaces if they are stored in a LDAP directory. Usernames stored in the shiro.ini configuration file may not contain blank spaces.
  • When referring to usernames from the LDAP directory to keys in the [users] section of the shiro.ini file 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 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.

Assigning Roles from LDAP Groups

Anchor
grouprolesmapping
grouprolesmapping

The group-roles mapping

When assigning the roles from the LDAP Groups the a user is a member of, the groups the groups will be mapped to the roles that are defined in the shiro.ini configuration file. This will be is done with the groupRolesMap

ldapRealm.groupRolesMap = \
group1 : list_of_roles, \
group2 : list_of_roles

where list_of_roles is a list of roles that are defined in of Roles that are configured in the [roles] section of the shiro.ini configuration file. Multiple Roles are separated with a bar |.

Please not Note that the value of the group depends on the result of the search. It is the value of the attribute you have specified in the groupNameAttribute.

...

ldapRealm.groupRolesMap = \
sos : it_operator, \
apl : administrator|application_manager

Example with the Public LDAP Server

ldapRealm.groupRolesMap = \
scientists : it_operator, \
mathematicians : all

Getting the

...

Groups a

...

User is a member of

There are two options how to find the membership of the userGroup membership(s) for a User Account.

a) Using memberOf with User Search

...

Especially when using an AD LDAP Server or when "memberOf" is enabled in e.g. OpenLdap (for example, in OpenLDAP) you can make use of the attribute "memberOf" attribute for the given user. 

Define an userSearchFilter and a searchBase that will find the user (%s will be replaced by the username from the login without the domain)

Example for user

...

search
  • ldapRealm.searchBase = ou=People,dc=sos
  • ldapRealm.userSearchFilter = (uid=%s)
Example for AD
  • ldapRealm.searchBase

...

  • =

...

  • dc=example,dc=com

...

  • ldapRealm.userSearchFilter

...

  • =

...

  • (sAMAcountName=%s)

...

To get the correct values for the searchBase and the userSearchFilter a LDAP client such as the "Softerra LDAP Browser" is very helpful. Perform a directory search with the values. You should find exactly one entry. 

The searchBase is the value of the base DNHint: When in your environment the attribute name is not the default "memberOf" you can specify the name of the attribute with groupNameAttribute key. Anchorgroupsearchgroupsearch

b) Using group search 

When the memberOf attribute is not available for the user, you can use the group search.

Define the groupSearchBase and the groupSearchFilter

ldapRealm.groupSearchBase = ou=Groups,dc=sos

ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

To get the correct values for these key a LDAP client like the "Softerra LDAP Browser" is helpful.

Code Block
titleConfiguration with memberOf search
collapsetrue
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos
 
ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userSearchFilter = (uid=%s)
 
# Mapping of a LDAP group to roles. You can assign more than one role with separator sign |
ldapRealm.groupRolesMap = \
sos : it_operator, \
apl : administrator|application_manager
 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

the value of the base DN

Code Block
languagetext
titleConfiguration with memberOf search
linenumberstrue
collapsetrue
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos
 
ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userSearchFilter = (uid=%s)
 
# Mapping of a LDAP group to roles. You can assign more than one role with separator sign |
ldapRealm.groupRolesMap = \
sos : it_operator, \
apl : administrator|application_manager
 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

Hint: If the attribute name in your environment is not the default "memberOf" you can specify the name of the attribute with groupNameAttribute key as described in the next section.

Anchor
groupsearch
groupsearch

b) Using group search 

When the memberOf attribute is not available for the user, you can use the group search.

Define the groupSearchBase and the groupSearchFilter. For example:

  • ldapRealm.groupSearchBase = ou=Groups,dc=sos
  • ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

It is helpful to use an LDAP client like the "Softerra LDAP Browser" to get the correct values for these keys. This is describved in the next two subsections. 

 

Anchor
groupsearchbase
groupsearchbase

...

Identify the place where the groups are stored. This is your groupSearchBase.

 

 

 

Getting the value for the groupSearchFilter

Click one groupEntry group Entry (in the screenshot, cn=apl) and see how the members are stored there.

 

 

The groupSearchFilter is configured with attr=val where attr is name of the attribute and val is the content. In this example, the attr is uniqueMember and the val uid=%s,ou=People,dc=sos, where the userid is replaced with %s. In this exampleThis results in:

  • ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

...

Verifing the groupSearchFilter with the ldapSearch command

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

This search should return the group entries the user User is a member of. Please identify Identify the attribute containing the group name that is to be used in the user roles mapping. This can be seen in the next listing

 

Code Block
collapsetrue
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=sos> with scope subtree
# filter: uniqueMember=uid=ur,ou=People,dc=sos
# requesting: ALL
#
 
# sos, Groups, sos
dn: cn=sos,ou=Groups,dc=sos
description: Employees of SOS GmbH
objectClass: top
objectClass: groupofuniquenames
cn: sos
uniqueMember: uid=ur,ou=People,dc=sos
uniqueMember: uid=fTester,ou=People,dc=sos

# apl, Groups, sos
dn: cn=apl,ou=Groups,dc=sos
objectClass: top
objectClass: groupofuniquenames
cn: apl
uniqueMember: uid=ur,ou=People,dc=sos
uniqueMember: uid=fTester,ou=People,dc=sos
 
# search result
search: 2
result: 0 Success
 
# numResponses: 3
# numEntries: 2

 

...

Verifing the groupSearchBase and groupSearchFilter with an LDAP Browser
To verify this you can You can verify your groupSearchBase and groupSearchFilter values by using them to perform a directory search with you groupSearchBase and your groupSearchFilter. The result should show all groups the user is a member of.

...

Now set the groupNameAttribute to the name of the attribute that contains the group name.

  • ldapRealm.groupNameAttribute = cn

Hint: Please note that the whole The complete content of this attribute must be used in the groupRolesMap attribute. Typical contents content of the attribute could be ou=Groups, dc=sos, cn=groupname . Please take the whole value for the mappinggroupname .

The whole configuration looks will now look like this:

Code Block
titleGroup Search
collapsetrue
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos

ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.groupNameAttribute = cnldapRealmcn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

# Mapping of a LDAP group to roles. You can assign more than one role with separator sign |
ldapRealm.groupRolesMap = \
sos : it_operator, \
apl : administrator|application_manager

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

...

Sometimes the values of the member do not contain the username from the login but e.g. , for example, the cn of the user. In that case you have to search for the user first and then specify the name of the attribute that should be used instead of the username from the login .

...

ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userSearchFilter = (uid=%s)

Verification with the ldapSearch command

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

This search should return the user with the given username. Please identify 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

 

Verification with an LDAP Browser

To check the user search perform Perform a directory search with your LDAP client to check the User search configuration. You should find exactly only the one user User entry of with the given username.

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

...

The whole configuration looks like this:

Code Block
languagetext
titleConfiguration with Username Substitution
linenumberstrue
collapsetrue
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos

ldapRealm.userNameAttribute = cn
ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userNameAttribute = cn
ldapRealm.userSearchFilter = (uid=%s)

ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.groupNameAttribute = cn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)

# Mapping of a LDAP group to roles. You can assign more than one role with separator sign |
ldapRealm.groupRolesMap = \
sos : it_operator, \
apl : administrator|application_manager

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000