Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This article describes multi-realm authentication in detail - example configurations showing multi-realm authentication and authorization have already been presented in the Authentication and Authorization - Configuration and LDAP Configuration articles.

...

A Simple Multi-Realm Example

Consider the case of a user account that is registered for both the Shiro ini realm and an LDAP realm. An simple example configuration is shown in the listing below. A publicly accessible LDAP server (hosted by forumsys.com) is used in this configuration example to allow the configuration to be implemented by 'cut and paste' and a minimum of modification. The LDAP server has

Both the realms in the example have an account with the name 'newton', password 'password' and this account belongs to the group 'scientists'. In the configuration below members of the 'scientists' LDAP group are assigned the (Shiro) 'it_operator' role. The ini realm 'newton' account has been given the same password as the LDAP realm account. . In the Shiro ini realm this account is assigned the administrator role and in the LDAP realm this user is assigned the it_operator role by way of the realm group roles mapping  publicLdapRealm.groupRolesMap =  scientists : it_operator.

Code Block
languagexml
titleConfiguration for ini and LDAP Realms
collapsetrue
[users]
newton = $shiro1$SHA-512$500000$wsJJJJ7cbBpoVi0C...JJ5U5pter6Q==,administrator

[main]
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

Realm Selection

In this the example above:

  • If the securityManager.realms parameter is specified ( Explicit realm ordering):
    • The authorization information provided by the user logging in will be only be checked against the realms listed in the securityManager.realms parameter: realms configured in the [main] section but not listed in the securityManager.realms parameter will be ignored. 
    • The authorization information provided by the user logging in will be checked against each realm account in the order in which realms are specified in a securityManager.realms parameter.(explicit ordering). In the example, this would be first the publicLdapRealm and then the iniRealm.
  • If the securityManager.realms parameter had not been specified ( implicit realm ordering):
    • The authorization information provided by the user logging in would have been checked against each realm account in the order in which realms were listed in the [main] section of the shiro.ini file. (implicit ordering). In the example, this would be first the iniRealm and then the publicLdapRealm.

...

Note that this parameter has to be defined for each realm individually.

 

Behavior for Accounts with Differing Passwords

...

When the SOS Authenticator is used with the At Least One Successful strategy:

  • ...

When the SOS Authenticator is used with the All Successful strategy:

  • ...
StrategyAuthenticator.........
First Successfulshiro   
First  SuccessfulSOS   
At Least One Successfulshiro/SOS   
All Successfulshiro/SOS