...
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.
Anchor | ||||
---|---|---|---|---|
|
...
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.
...
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 | ||||
---|---|---|---|---|
|
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 |
...
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
...