...

Multi-Realm Authentication and Authorization

The behaviour in Authentication and authorization can be configured for a multi-realm environment (ini/LDAP or multiple LDAP realms) can be configured in the [main] Shiro section. For example, when a user account name exists in more than one realmmade up of one or more LDAP realms, with or without an ini realm.The mixed LDAP and Shiro Authentication example below shows a simple multi-realm configuration.

Note that an account user name can be configured for more than one realm. The behavior in this 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.

...

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.

...

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.

...

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

...

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

...