Introduction

This article describes the configuration of the JOC Cockpit to use an LDAP Directory Service for authentication and authorization that is performed with Apache Shiro. Note that the authoritative documentation of Shiro is provided by the Shiro project and may differ from the below explanations depending on the Shiro version in use.

Release 1.12.0

FEATURE AVAILABILITY ENDING WITH RELEASE 1.12

LDAP configuration is stored out 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 with JOC Cockpit is provided with the JOC Cockpit - Authentication and Authorization article.

A rrestart of JOC Cockpit is not required after changing the shiro.ini configuration file either by using the JOC Cockpit Account Manager or a text editor.

Release 1.12.1 and Newer

LDAP configuration is stored in the reporting database along with other authentication and authorization information. A form based editor is available for users with the necessary permissions such as the default root user with the all role. This editor is accessed via the "Manage Accounts" menu and can be used for the configuration of LDAP authentication.

A shiro.ini file is still available but is overwritten each time a user with permissions to modify the authentication and authorization configuration logs out. This file is intended as a backup if system administrators are faced with all users being locked out of the system.

A restart of JOC Cockpit is not required after changing the shiro.ini configuration file either by using the JOC Cockpit Account Manager or a text editor.

Relevant Tools

• An LDAP Browser:
  • The screenshots used in this article were made with the "Softerra LDAP Browser", which was configured to use the relevant LDAP Directory Service.
• A command line utility:
  
  • The example commands used were executed with ldapSearch.

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
   • Defining the groupRolesMapping (optional)
   • Defining the Roles per account in the [users] section (optional)
   • Defining the search for groups
4. Add Shiro settings

The Setup Procedure

The following diagram provides an overview of the setup procedure:

1. Basic LDAP Configuration

After setting up the Basic LDAP Configuration your [main] section looks like this:

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://myHost: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

The following table lists the basic items used to configure an LDAP realm. These items are configured in the [main] section of the shiro.ini file and cannot be changed with the Account Management in JOC Cockpit.

(See the Authentication and Authorization - Configuration article for more information about the shiro.ini file)

ldapReam

com.sos.auth.shiro.SOSLdapAuthorizingRealm

ldapRealm.contextFactory.url

ldap://host:port

ldapRealm.useStartTls

ldapRealm.hostNameVerification   

rolePermissionResolver  

com.sos.auth.shiro.SOSPermissionResolverAdapter

ldapRealm.rolePermissionResolver 

$rolePermissionResolver

securityManager.realms 

$ldapRealm [, $ldapRealm [, $iniRealm]]

In a simple configuration these items could appear as visible with the code block below (see also the example configuration for the public LDAP server listed in the below section):

2. Authentication

Settings: 

• ldapRealm.userDnTemplate
  
  

After setting up the Basic LDAP Configuration (described in 1. above) and adding the userDnTemplate your [main] section will looks like this:

[main]
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos

ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://myHost:389 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm

The userDnTemplate Setting

With authentication you will check for a valid account/password combination. To achieve this you have to specify the userDnTemplate. The parameters for the userDnTemplate can be taken from an account's properties page as displayed in the below screenshot from an LDAP browser.

For the account in the screenshot the template would be (replacing the uid value 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 userDnTemplate settings.

Login with the sAMAccountName or CN

This works with a Microsoft Active Directory^® that supports domain login.

1. Change the userDnTemplate to ldapRealm.userDnTemplate = {0}
2. Add the User Search
3. Use domain\account or account@domain for the login where account is the value of the sAMAcountName attribute.

Account Names

The account name for a Microsoft Active Directory^® can have one of the following login patterns:

• sAMAccountName@domain
  • The sAMAccountName attribute is a unique identifier for an Account.
• domain\sAMAccountName
• cn
  • The Common Name attribute value of the Account is used.
  • This format requires the Common Name of an Account to be unique.

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

Configuration in the shiro.ini file

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

Examples for the userDnTemplate: 

• Example Configuration for an arbitrary hierarchy:
  
  • ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos


• Example Configuration for the public LDAP Server mentioned in this article:

• • ldapRealm.userDnTemplate = uid={0},dc=example,dc=com



• Example Configurations with a Microsoft Active Directory^®:

• • ldapRealm.userDnTemplate = {0}
  • ldapRealm.userDnTemplate = cn={0},ou=Users,dc=sos,dc=berlin,dc=com


Verification with ldapSearch

You can check the value of the userDnTemplate by using it with a command for the ldapSearch utility such as:

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

This should return a result such as:

# ur, People, sos
dn: uid=ur,ou=People,dc=sos
mail: *********
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 a public LDAP Server

For this server the command to check the userDnTemplate in the ldapSearch utility would be:

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

The server will return the following:

# 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

Note: ldapSearch Parameters

The option -x is used in all the ldapSearch examples in this article. It is possible that your LDAP Directory Service does not allow this option and you have to specify an Account and a Password. If this is the case then 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 an LDAP Browser

Search with the value from the userDnTemplate in the Search DN input field. The query should return only one entry.

Verification with the JOC Cockpit

Try to login with an LDAP Account/Password combination. Use an Account  that you have verified to be correct by executing the ldapSearch command described above. If there are no Role(s) configured for the Account but the authentication works then you will see the following screen that complains about missing authorization after successful authentication:

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. An Account has all Permissions specified by the Roles that the Account is assigned.

There are two options for assigning Roles to Accounts:

1. First Option: with an LDAP Group to Shiro Role mapping
2. Second Option: with a Shiro User Account. 

Both options can be combined. The result is the union of all assigned Roles.

Please decide:

1. If Roles are to be assigned in the shiro.ini file using the JOC Cockpit Account Management: The LDAP Groups the Account is a member of have no effect. Proceed with Assigning roles in the shiro.ini File
2. If Roles are to be assigned with the group roles mapping: The LDAP Groups the account is a member of are assigned to JOC Cockpit roles. Proceed with Assigning Roles from LDAP Groups
3. If a mix of 1. and 2. is to be used: Proceed with Assigning roles in the shiro.ini File and then with Assigning Roles from LDAP Groups

Assigning Roles in the shiro.ini File

After assigning Roles in the shiro.ini file the [users] section of the file will look like this:

[users]
user1 = ,all
user2 = ,it_operator,administrator

[main]
 ...

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

The Roles assigned to an entry are saved in the [users] section of the shiro.ini configuration file according to the following syntax:

• account = ,list_of_roles

The list_of_roles is a comma separated list such as:

• it_operator,administrator

The JOC Cockpit Account Management will add entries to the [users] section for Role assignment.

• Account names may include blank spaces if they are stored in an LDAP Directory Service. Account names stored in the shiro.ini configuration file may not contain blank spaces.
  
  • When a User Account with blank spaces in its name is configured using the JOC Cockpit's Manage Accounts view then every blank space in the name will be automatically replaced with %20 before the name is written to the shiro.ini file.
  • When a User Account with blank spaces in its name is added directly to the shiro.ini file then every blank space in the name should replaced with %20 before the name is written to the shiro.ini file.
  • Every occurrence of %20 in an User Account name saved in the shiro.ini file will be automatically converted to a blank space before this name is submitted to the LDAP server.
• Passwords may not be specified for Accounts with LDAP authentication when configuring such Accounts using the JOC Cockpit's Manage Accounts view .
• When a domain login is used then the reference has to contain the domain/account pattern e.g. domain\account or account@domain.

Assigning Roles from LDAP Groups

If the Roles are assigned with the JOC Cockpit Account Management, i.e. there is a [users] section available in the shiro.ini configuration file, then you can skip this chapter.

How substitutions will be done

In the groupSearchFilter and the userSearchFilter you can specify e.g. 

(uid=%s)

The %s will be substituted with the account from the login. If you login with domain\account oder account@domain the value for the user is account.

You can specify e.g.

(uid=^s)

The Group/Roles mapping

Settings: 

• ldapRealm.groupRolesMap
  
  

If the Roles are assigned with the JOC Cockpit Account Management, i.e. there is a [users] section available in the shiro.ini configuration file, then you can skip this chapter.

[main]
...
ldapRealm.groupRolesMap = \
  group1 : it_operator, \
  group2 : all

The groupRolesMap looks like this.

# Mapping of a LDAP group to roles. You can assign more than one role with separator character |

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

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

Note that the value of the group depends on the result of the group search. It is the value of the attribute that you have specified with the groupNameAttribute. Default for the groupNameAttribute is memberOf. This indicates that if you are retrieving group memberships by use of the memberOf attribute of an account then you have to specify the complete value of the memberOf attribute value, i.e. the distinguished names of group hits.

Example for Group Mapping with Microsoft Active Directory by memberOf Attribute

A typical mapping when using Microsoft Active Directory with the memberOf attribute for group memberships includes to specify group hts by their distinguished name like this:

ldapRealm.groupRolesMap = \
"CN=Group1,OU=SpecialGroups,OU=Groups,OU=Company,DC=sos-berlin,DC=com" : all, \
"CN=AnotherGroup,OU=SpecialGroups,OU=Groups,OU=CompanyDC=sos-berlin,DC=com" : all, \
"CN=Beginners,OU=SecurityGroups,OU=Groups,OU=Company,DC=sos-berlin,DC=com" : business_user

Example for Group Mapping by cn Attribute

A mapping that is based on group search would identify group hits by the value of their common name like this:

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

Retrieving the Groups an Account is a member of

If the Roles are assigned with the JOC Cockpit Account Management, i.e. there is a [users] section availab le in the shiro.ini configuration file, then you can skip this chapter.

There are two options to find the Group membership(s) for a User Account:

1. The Account has a memberOf attribute. Then you can retrieve the list of groups with the User Search. Then proceed with Using memberOf with User Search.
2. The Account does not have a memberOf attribute. The group contains the Accounts that are members of the group, Then proceed with Using Group Search.

These options cannot be mixed. 

a) Using memberOf with User Search

If the Account entries do not have the memberOf attribute then you can skip this section and proceed with Using Group Search.

Settings: 

• ldapRealm.searchBase
• ldapRealm.userSearchFilter

After specifying the User Search the shiro.ini configuration file will look like this:

[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

This approach looks for the Account entry and reads the memberOf attribute. This attribute is often used when, for example, configuring Microsoft Active Directory^® LDAP servers. 

Define a userSearchFilter and a searchBase that will find the account (%s will be replaced by the Account name from the login without the domain part).

Example for User Search

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

Example for User Search in Active Directory^®

• ldapRealm.searchBase = dc=example,dc=com
• ldapRealm.userSearchFilter = (sAMAcountName=%s)

An LDAP Browser can be used to get the correct values for the searchBase and the userSearchFilter. Perform a directory search with the values. You should find only one entry. 

The searchBase is the value of the base DN (or ParentDN in the screenshot above).

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

b) Using Group Search 

If the Account entries have the memberOf attribute then you can skip this section and proceed with Using memberOf with User Search. Settings: 

• ldapRealm.groupSearchBase 
• ldapRealm.groupNameAttribute
• ldapRealm.groupSearchFilter

After defining the Group Search the shiro.ini configuration file will look like this:

[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 = 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

When the memberOf attribute is not available for the Account then 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)

Getting the value for the groupSearchBase

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

Getting the value for the groupSearchFilter

Click one 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. This 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 Account is a member of. 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

# 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

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

• ldapRealm.groupNameAttribute = cn

Hint: The complete content of this attribute must be used in the groupRolesMap attribute. Typical content of the attribute could be ou=Groups,dc=sos,cn=groupname .

Substitution of the account name

If the roles are assigned with the JOC Account Manager (i.e. there is a [users] section in the shiro.ini configuration file) you can skip this chapter.

If the value of the member of the groups contain the Account name from the login then you can skip this chapter

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

To achieve this, specify a searchBase, a userSearchFilter and a userNameAttribute.

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

# 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

Perform a directory search with your LDAP client to check the User Search configuration. You should find only one Account entry with the given Account name.

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

• ldapRealm.userNameAttribute = cn

The configuration will look like this:

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

4. Add Shiro settings

Settings

• cacheManager
• securityManager.cacheManager
• securityManager.sessionManager.globalSessionTimeout

After adding Shiro settings for the cache manager and the global session timeout the shiro.ini configuration file will look like this:

[main]
....
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
securityManager.sessionManager.globalSessionTimeout = 900000

Examples and special configurations

Example LDAP Configuration with mixed LDAP and Shiro Authentication

Add the iniRealm to 

[users]
...
 
[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos

ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389
ldapRealm.groupNameAttribute = cn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager
 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver

cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

securityManager.realms = $ldapRealm, $iniRealm
 
# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

Example LDAP Configuration for Active Directory with mixed LDAP and Shiro Authentication

Login with sAMAccountName specified for domain\account or account@domain:

• ldapRealm.userDnTemplate = {0}

• Consider use of uppercase/lowercase spelling for domain and account

Add the ldapRealm and iniRealm like this: 

[users]
# Locally authenticated users (specified with a hashed password)
root = $shiro1$SHA-512$500000$W0oNBkZY9LRrRIGyc4z2Ug==$NcoU+ZFM9vsM0MeHJ3P5NJ0NdvJrK38qVnl7v7YG7p9o5ZJfMccugJsA9myJsTNx2BF5rbvA696UhTGdUtSnOg==,all


# LDAP authenticated users (specified without a password)
COMPANY\homer = ,all
COMPANY\alice = ,all
 
[main]
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm


# Realm for Domain company.local
# -------------------------------
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://company.local:389


#    users can login with COMPANY\account and account@COMPANY.local where the account maps to the sAMAccountName
ldapRealm.userDnTemplate = {0}
ldapRealm.rolePermissionResolver = $rolePermissionResolver
# -------------------------------


# Authentication via domains ite.local, domain.local and via shiro.ini [users] section
securityManager.realms = $ldapRealm, $iniRealm


passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
iniRealm.credentialsMatcher = $passwordMatcher


cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager


# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 1800000

Example LDAP Configuration with several LDAP Servers

LDAP configuration with several LDAP servers is achieved by defining more than one LDAP realm as shown in the next code block.

Define two realms and assign them like this:

• securityManager.realms = $ldapRealm1, $ldapRealm2

[main]
ldapRealm1 = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm1.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm1.groupSearchBase = ou=Groups,dc=sos
ldapRealm1.contextFactory.url = ldap://centos6_9_ldap.sos:389
ldapRealm1.groupNameAttribute = cn
ldapRealm1.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm1.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager

ldapRealm2 = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm2.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm2.groupSearchBase = ou=Groups,dc=sos
ldapRealm2.contextFactory.url = ldap://anotherHost:389
ldapRealm2.groupNameAttribute = cn
ldapRealm2.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm2.groupRolesMap = \
group1: it_operator, \
group2: administrator|application_manager
 
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm1, $ldapRealm2

cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 900000

A full shiro.ini example with Group Search 

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.groupNameAttribute = cn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: 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

A full shiro.ini example with Group Search where the member attribute does not contain the account name but the common name

[main]
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos
ldapRealm.groupSearchBase = ou=Groups,dc=sos
ldapRealm.contextFactory.url = ldap://centos6_9_ldap.sos:389 
ldapRealm.groupNameAttribute = cn
ldapRealm.groupSearchFilter = (uniqueMember=uid=%s,ou=People,dc=sos)
ldapRealm.searchBase = ou=People,dc=sos
ldapRealm.userNameAttribute = cn
ldapRealm.userSearchFilter = (uniqueMember=uid=%s,dc=example,dc=com)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: 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

A full shiro.ini example with memberOf in the account record

[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)
ldapRealm.groupRolesMap = \
group1: it_operator, \
group2: 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

A public LDAP Server for testing the connection

An online 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:

To 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:

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

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

Save the modified shiro.ini file. (It is not required to restart the Jetty web server.)

You will now be able to use JOC Cockpit to authenticate the two User Account name:password combinations listed in the table above with the LDAP server.

The Shiro authentication (using, for example, the default root:root User Account) will still be active alongside the LDAP accounts listed above.

The LDAP group memberships will be mapped to 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.

Troubleshooting

Enable logging

To enable logging:

• Open the file ./sos-berlin.com/joc/jetty_base/resources/joc/log4j.properties
• Change:
  • #for debugging JOC set the following logger to 'debug'
log4j.logger.com.sos = info
• to
  • #for debugging JOC set the following logger to 'debug'
log4j.logger.com.sos = debug

Log File location

The log file is located  in:

• ./sos-berlin.com/joc/logs/yyyy_mm_dd.stderrout.log