...
- 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 existingshiro.ini.active
file will be renamedshiro.ini.backup
and any already existing file with that name will be overwritten.
- The import function automatically imports a file named
...
(See the Authentication and Authorization - Configuration article for more information about the shiro.ini
file)
Key | Value | Description |
---|---|---|
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 Please note that you can have more than one LDAP realm configuration but each realm requires a unique name. |
ldapRealm.contextFactory.url | ldap://host:port | The host and the port of your LDAP server. You can check whether the server is reachable with Make sure that the firewall is open for the given port. |
ldapRealm.useStartTls | true|false | To enable Starttls set the value to Please note that the server must be prepared to serve with Starttls. To check this, you can use an LDAP browser such as the "Softerra LDAP Browser". Configure your LDAP Server there and click the "Enable Starttls Button" On client side you will need the certificate and you have to add the certificate to your truststore. The path to your truststore is defined in the
Example values:
Note: we habe had difficulties when using Starttls with the JRE 1.8.0_151 and have overcome these by installing the corresponding JDK. |
ldapRealm.hostNameVerification | on|off true|false | Enables the host name verification of the certificate. The default value is off. |
rolePermissionResolver | com.sos.auth.shiro.SOSPermissionResolverAdapter | The implementation of the permission resolver. The SOS implementation uses the org.apache.shiro.realm.text.IniRealm class to resolve the permissions. This means that the permissions a role is assigned are specified with the configuration file shiro.ini in the same way as it is done when using the iniRealm . |
ldapRealm.rolePermissionResolver | $rolePermissionResolver | Sets the role permission resolver for the LDAP realm. |
securityManager.realms | $ldapRealm [, $ldapRealm [, $iniRealm]] | Sets the list of realms that should be used for authentication. This is a comma separated list of items. Example values:
|
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):
Anchor | ||||
---|---|---|---|---|
|
...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[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 |
...
- Change the
userDnTemplate
toldapRealm.userDnTemplate = {0}
- Add the User Search
- Use
domain\account
oraccount@domain
for the login whereaccount
is the value of thesAMAcountName
sAMAccountName
attribute.
Anchor | ||||
---|---|---|---|---|
|
...
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:
Anchor
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.
Anchor | ||||
---|---|---|---|---|
|
3. Authorization
Authorization is the assignment of Roles to User Accounts. Roles, in 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:
- 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 - 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
- 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 placeholder ^s
will be substituted with the original value from the login e.g. account@domain.
...
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
...
Code Block | ||
---|---|---|
| ||
# 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
This search should return the Account with the given Account name. Identify the attribute that should be used for substitution in the Group Search base if it is not the Account name from the login.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
# 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
...
Code Block | ||
---|---|---|
| ||
[main] .... cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager securityManager.cacheManager = $cacheManager securityManager.sessionManager.globalSessionTimeout = 900000 |
...
Examples and special configurations
Anchor | ||||
---|---|---|---|---|
|
Add the iniRealm to
securityManager.realms = $ldapRealm, $iniRealm
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[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
...
securityManager.realms = $ldapRealm, $iniRealm
Add domain\account
to the [users]
section. Assign roles but omit passwords for LDAP authenticated users like this:
COMPANY\account = ,role [,role]
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[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
...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[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 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[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 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[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:
Account Name | Password | LDAP Group | Shiro Role |
---|---|---|---|
gauss | password | mathematicians | all |
newton | password | scientists | it_operator |
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:
Code Block | ||||
---|---|---|---|---|
| ||||
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 /joc/log4j2.xml
- Enable the
AuthAppender
by uncommenting
#for debugging JOC set the following logger to 'debug'
log4j.logger.com.sos = debug
<!-- 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