...
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. The Note that the authoritative documentation of Shiro is provided by the Shiro project and may differ from the descriptions below explanations depending on the Shiro version in use.
Release 1.12.0
Display feature availability | ||
---|---|---|
|
LDAP configuration information is stored in the [main]
section of 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 with JOC Cockpit is provided with the JOC Cockpit - Authentication and Authorization article.
LDAP configuration can only be edited by system administrators using a text editor to update the shiro.ini
file. There is no web-based editing feature available.
A After changing the shiro.ini configuration file either by using the JOC Cockpit Account Manager or a text editor, no restart of JOC Cockpit is not required .
Relevant Tools
- An LDAP Browser:
- The screenshots used in this article are made for the "Softerra LDAP Browser" that is configured to use the relevant LDAP Directory Service.
- A command line utility:
- The example commands used are executed with ldapSearch
How to set up an LDAP Configuration
Carry out the following steps:
- Set up the basic LDAP configuration
- Set up the authentication
- Set up the authorization
- Defining the groupRolesMapping (optional)
- Defining the Roles per account in the
[users]
section (optional) - Defining the search for groups
- Add Shiro settings
The Setup Procedure
...
after changes are made to the shiro.ini
configuration file.
Release 1.12.1 and Newer
Three changes relevant to the configuration of LDAP authentication and authorization are introduced with Release 1.12.1:
- 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. 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 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
The shiro.ini.active
file provides a convenient overview of the authentication and authorization configuration and will be referred to repeatedly in the rest of this article.
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:
- Set up the Basic LDAP configuration
- Set up the authentication
- Set up the authorization
- Defining the groupRolesMapping (optional)
- Defining the Roles per account in the
[users]
section (optional) - Defining the search for groups
- Add Shiro settings
The Setup Procedure
The following diagram provides an overview of the setup procedure:
Flowchart |
---|
1 [label="1. Set up the Basic LDAP config\n(URL, etc)"]
1 -> 2 [weight=5, len=0.5]
2 [label="2. Set up Authentication\n(userDnTemplate)"]
2 -> 3
3 [label="3. Set up Authorization"]
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 |
...
The following diagram provides an overview of the setup procedure:
Flowchart |
---|
1 [label="1. Set up basic LDAP config\n(URL, etc)"] 1 -> 2 [weight=5, len=0.5] 2 [label="2. Set up authentication\n(userDnTemplate)"] 2 -> 3 3 [label="3. Set up authorization"] 3 -> 4 4 [shape="diamond", label="Are roles to be assigned \nwith groups from LDAP?",fillcolor="lightblue"] 4 -> 5 [label="Yes"] 520 [label="Define GroupRoles mapping"] 4Specify User Search\l - searchBase\l - userSearchFilter"] 20 -> E3 E3 [shape="circle", style="filled", label="End", color="pink"] 6 -> 107 [label="No"] 107 [label="Use Shiro to assign roles to accounts"] 10Specify Group Search\l - groupSearchBase\l - groupSearchFilter\l - groupNameAttribute"] 7 -> E28 E28 [shape="circlediamond", label="", color="pinkDoes the member attribute contain\nthe account name from the login?",fillcolor="lightblue"] 58 -> 6 6 E4 [label="Yes"] E4 [shape="circle", style="diamondfilled", label="Has account record a\nmemberOf attribute?End",fillcolor color="lightbluepink"] 68 -> 209 [label="YesNo"] 209 [label="Specify User Search\l - searchBase\l - userSearchFilter"] 209 -> E3E5 E3E5 [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 member attribute contain\naccount name from login?",fillcolor="lightblue"] 8 -> E4 [label="Yes"] E4 [shape="circle", style="filled", label="", color="pink"] 8 -> 9 [label="No"] 9 [label="Specify User Search\l - searchBase\l - userSearchFilter"] 9 -> E5 E5 [shape="circle", label="", color="pink"] |
1. Basic LDAP Configuration
After setting up the Basic LDAP Configuration your [main]
section looks like this:
Code Block | ||||
---|---|---|---|---|
| ||||
[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
|
...
Anchor | ||||
---|---|---|---|---|
|
1. Basic LDAP Configuration
LDAP is configured as part of the [main]
section of a Shiro configuration file. As already mentioned above this information can be added to the JOC Cockpit either by adding it to a shiro.ini
file or - in Version 1.12.1 and newer - by using the editor in the Main Section of the JOC Cockpit Manage Accounts view.
A Basic LDAP configuration in the [main]
section will contain the following elements, with the ldapRealm.contextFactory.url
being modified to suit the LDAP server being used:
Code Block | ||||
---|---|---|---|---|
| ||||
[main]
rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter
rolePermissionResolver.ini = $iniRealm
ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm
ldapRealm.contextFactory.url = ldap://myHost:389
ldapRealm.rolePermissionResolver = $rolePermissionResolver
securityManager.realms = $ldapRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager |
An Add LDAP realm function is available in the Main Section of the JOC Cockpit Manage Accounts view that adds the above Basic LDAP configuration in a single step. Both the button used to activate this function and the configuration items added can be seen in the screenshot below.
Info | ||
---|---|---|
| ||
Note that the Administrators wishing to use a local user while configuring LDAP are therefore recommended to modify the securityManager element immediately to:
|
List of Basic LDAP Realm Items
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)
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):
...
2. Authentication
Settings:
...
as visible with the code block below (see also the example configuration for the public LDAP server listed in the below section):
Anchor | ||||
---|---|---|---|---|
|
2. LDAP Authentication
Settings:
ldapRealm.userDnTemplate
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 taken from an LDAP browser.
The template setting for the account shown in the screenshot above would be (replacing the uid value with {0}
):
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos
This userDnTemplate
item can be added to the Basic LDAP configuration using the Add Entry button of the Main Section editor as shown in the next screenshot:
Note that the '+' and 'x' symbols in the screenshot can be used to increase the number of entries added at once.
After setting up the Basic LDAP Configuration (described in 1. above) and adding the userDnTemplate
your the [main]
section will looks of the shiro.ini.active
file will look like this:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
[main] ldapRealm.userDnTemplate = uid={0},ou=People, dc=sos ldapRealm = com.sos.auth.shiro.SOSLdapAuthorizingRealm ldapRealm.contextFactory.url = ldap://myHost:389 rolePermissionResolvermain] ldapRealm = 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}
):
...
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
|
Note that only Only one template can be specified per realm, separate realms have to be configured for different userDnTemplate
settings.
Login with the sAMAccountName
or CN
...
- 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 | ||||
---|---|---|---|---|
|
...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
# 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
The following example uses a publicly available LDAP server at forumsys.com. In our experience this server provides a reliable means of getting an initial LDAP configuration up and working.
The For this server the command to check the userDnTemplate
in the the forumsys ldapSearch utility would be:
...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
# 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:
...
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:
...
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:
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 | ||||
---|---|---|---|---|
|
...
Both options can be combined. The default result is 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 : The 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 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.
Anchor | ||||
---|---|---|---|---|
|
shiro.ini
File...
Role assignment in the shiro.ini
file is configured in the Manage Accounts view of the JOC Cockpit . Do not enter the Password and is described in the Authentication and Authorization - Managing User Accounts article.
Note that a Password should not be entered for a User Account that is to be authenticated by an LDAP Directory Service.
The following screenshot shows the allocation of one of the default roles:
The Roles assigned to an entry are saved in the [users]
section of the shiro.ini
configuration file according to the following syntax:
...
The JOC Cockpit Account Management will can be used to 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 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 theshiro.ini
- file
- .
- When a User Account with blank spaces in its name is configured using the JOC Cockpit's Manage Accounts view added directly to the
shiro.ini
file then every blank space in the name will be automatically should replaced with %20 before the name is written to theshiro.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 theshiro.ini
file. - Every occurrence of
%20
in an User Account name saved in theshiro.ini
file will be automatically converted to a blank space before this name is submitted to the LDAP server.
- 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
- 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
oraccount@domain
.
...
- the
shiro.ini
file. - Every occurrence of
%20
in an User Account name saved in theshiro.ini
file will be automatically converted to a blank space before this name is submitted to the LDAP server.
- the
- 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
oraccount@domain
.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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 placeholder ^s
will be substituted with the original value from the login e.g. account@domain
...
.
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.
shiro.ini
configuration file. This is done in the a [main]
section with the groupRolesMap
setting....
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
...
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. That means This indicates that if you are looking for the groups by searching retrieving group memberships by use of the memberOf Attribute values attribute of an user account then you have to specify the whole value of the memberOf
Attribute. 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 AD Microsoft Active Directory with memberOf
ist# Mapping of a LDAP group to roles. You can assign more than one role with separator sign |
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
...
After specifying the User Search the shiro.ini.active
configuration file will look like this:
...
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.
...
The searchBase
is the value of the base DN (or ParentDN in the screenshot above).
Hint: If 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.
...
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 securityManager.realms = $ldapRealm 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:
./sos-berlin.com/joc"${sys:jetty.base}/logs/yyyy_mm_dd.stderroutJOCShiroLog.log
...