Introduction

...

• All authentication and authorization information is stored in the Reporting database.
• A form based editor which users can use to configure LDAP authentication is available in the JOC Cockpit. This editor is only available for users with the necessary permissions such as the default root user with the all role. This The editor is accessed via the "Manage Accounts" menu.
• Automatic import and backup functions for the authentication and authorization information are available. Both the import and backup functions use Shiro files and are their execution is triggered by a user logging into JOC Cockpit interface.
  
  • The import function automatically imports a file named shiro.ini to the Reporting database and the contents of this file will overwrite all the authentication and authorization information stored in the Reporting database at that point.
  • The backup function automatically stores the authentication and authorization information in a file named shiro.ini.active. At the same time an existing shiro.ini.active file will be renamed shiro.ini.backup and any already existing file with that name will be overwritten.

...

1 [label="1. Set up the basicBasic LDAP config\n(URL, etc)"]
1 -> 2 [weight=5, len=0.5]
2 [label="2. Set up authenticationAuthentication\n(userDnTemplate)"]
2 -> 3
3 [label="3. Set up authorizationAuthorization"]
3 -> 4
4 [shape="diamond", label="Are roles to be assigned \nwith groups from LDAP?",fillcolor="lightblue"]
4 -> 5 [label="Yes"]
5 [label="Define GroupRoles mapping"]
4 -> 10 [label="No"]
10 [label="Use Shiro to assign roles to accounts"]
10 -> E2
E2 [shape="circle", style="filled", label="End", color="pink"]
5 -> 6
6 [shape="diamond", label="Has the account record a\nmemberOf attribute?",fillcolor="lightblue"]
6 -> 20 [label="Yes"]
20 [label="Specify User Search\l - searchBase\l - userSearchFilter"]
20 -> E3
E3 [shape="circle", style="filled", label="End", color="pink"]
6 -> 7 [label="No"]
7 [label="Specify Group Search\l - groupSearchBase\l - groupSearchFilter\l - groupNameAttribute"]
7 -> 8
8 [shape="diamond", label="Does the member attribute contain\nthe account name from the login?",fillcolor="lightblue"]
8 -> E4 [label="Yes"]
E4 [shape="circle", style="filled", label="End", color="pink"]
8 -> 9 [label="No"]
9 [label="Specify User Search\l - searchBase\l - userSearchFilter"] 
9 -> E5
E5 [shape="circle", style="filled", label="End", color="pink"]

...

(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): 

...

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

ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://myHost:389 
ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos

rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm

...

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

...

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:

Anchorauthorizationauthorization

3. Authorization

Multi-Realm Authentication

Authentication can be configured for a multi-realm environment made up of one or more LDAP realms, with or without an ini realm. A simple multi-realm configuration is shown in the mixed LDAP and Shiro Authentication example below.

Note that the a user name can be configured for accounts in more than one realm. The behavior in such a situation (for example, should the roles configured for all realms be assigned to the account or only the roles configured for the realm used for the successful login?) is briefly described in the mixed LDAP and Shiro Authentication example below and in detail in the Multi-Realm Authentication and Authorization article.

3. Authorization

Authorization is the assignment of Roles 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.

...

Both options can be combined. The default result will be the union of all the assigned Roles. Note, however, that alternative

Please decide:

1. If Roles are to be assigned in the shiro.ini file using the JOC Cockpit Account Management then 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.

...

You can specify e.g.

(uid=^s)

...

The Group/Roles mapping

Settings: 

...

• ldapRealm.searchBase = dc=example,dc=com
• ldapRealm.userSearchFilter = (sAMAcountNamesAMAccountName=%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. 

...

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:

...

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

...

If the value of the member of the groups contain contains 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 Account name from the login .

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

...

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

...

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

...

Examples and special configurations

Anchor
mixed-realms mixed-realms

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

 = $cacheManager

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

Behavior Notes:

• By default roles from the shiro ini are added to the roles of an authenticated LDAP user with the same name. This happens regardless of whether or not a password is set for the account in the shiro ini file. However, a number of options can be configured to modify this behavior. These are described in the Multi-Realm Authentication and Authorization article.

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

...

[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

...

• 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 

...

Code Block
language text title Configuration with group search linenumbers true collapse true
[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

...

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

...

Code Block
language text title Configuration with memberOf in the user record linenumbers true collapse true
[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

...

• 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
• /joc/log4j2.xml
• Enable the AuthAppender by uncommenting

<!-- logger for authentication and session management -->
<Logger name="com.sos.auth" level="trace" additivity="false">
<AppenderRef ref="AuthAppender"/>
</Logger>


Log File location

The log file is located  in:

• "${sys:jetty./sos-berlin.com/joc/logs/yyyy_mm_dd.stderrout.log

...

• base}/logs/JOCShiroLog.log