...
- 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 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 triggered by :a user logging into JOC Cockpit interface.
- The import function automatically imports a file named
shiro.inito the Reporting database and the contents of this file will overwrite the authentication and authorization information in the Reporting database. - The backup function automatically stores the authentication and authorization information in a file named
shiro.ini.active. At the same time an existingshiro.ini.activefile will be renamedshiro.ini.backupand 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.
...
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 (in Version 1.12.1 and newer).
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 |
...
| 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.
...
| 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 faced habe had difficulties when using Starttls using Starttls with the JRE 1.8.0_151 and have overcome these by installing the respective 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:
|
...
| Anchor | ||||
|---|---|---|---|---|
|
2. LDAP 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:
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.
For the account shown in the screenshot the template setting would be (replacing the uid value with {0}):
ldapRealm.userDnTemplate = uid={0},ou=People,dc=sos
The 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:
After setting up the Basic LDAP Configuration (described in 1. above) and adding the userDnTemplate the [main] section of the shiro.ini.active file will look like this:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
[main]
ldapRealm | ||||||||
| Code Block | ||||||||
| ||||||||
[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
.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
...
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.
For this server the command to check the userDnTemplate in the ldapSearch utility would be:
...
Both options can be combined. The result is will be the union of all the assigned Roles.
Please decide:
- If Roles are to be assigned in the
shiro.inifile 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...