Page History

...

Shiro can use multi-realm authentication and authorization - for example, against a shiro.ini account and an LDAP account or against one or more of LDAP accounts.

...

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.

...

Behavior for Accounts with a Common Password

Consider the case of a user account that is registered for both a shiro Shiro and an LDAP realm. Such a An example configuration is shown in the listing : below.

...

• 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)

...

:

...

[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 = $iniRealm$publicLdapRealm, $publicLdapRealm$iniRealm
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

With the configuration listed above, the login information will be tested for each account in the order listed in the securityManager.realms parameter.until a successful login occurs. In the example configuration listed above, this will be first the iniRealm and then the publicLdapRealm. 

Note the following behaviors:

• When the user logs in with the password for the iniRealm account they will be given the role for that account - here the administrator - but if they log in with the password for the  publicLdapRealm account they will be given the roles for both the  iniRealm and  publicLdapRealm accounts - here the administrator and the it_operator accounts. This is because after successfully logging into the LDAP account the roles specified for the user in the ini file will also be assigned.
• The securityManager.realms parameter.is used to provide Explicit Ordering of the realms. See 'Realm Authentication' on the Shiro Authentication web site for more information.
• An error will be noted in the shiro stderrout log file under particular circumstances when a user login attempt is unsuccessful. This will not affect the overall login procedure. See issue JOC-437 for more information.

Alternative behaviours

In this example:

• One "newton" account is configured in the [users] section of the shiro.ini file for the iniRealm and assigned the administrator role.
• A second "newton" account that accesses a publicly open LDAP server is configured in the the [main] section of the shiro.ini file and assigned the it_operator role.
• Both accounts have the same password.
• If the securityManager.realms parameter is specified:
  • 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 is not specified:
  • The authorization information provided by the user logging in will be checked against each realm account in the order in which realms are 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 Explicit and implicit realm ordering is described in more detail in the 'Realm Authentication' section of on the Shiro Authentication web site.

Alternative Authentication Behavior Strategies

Shiro allows a number of Authentication Behavior Strategies to be followed. These are configured with the authcStrategy parameter and are:

• org.apache.shiro.authc.pam.AtLeastOneSuccessfulStrategy
  
  • If one (or more) Realms authenticate successfully, the overall attempt is considered successful. If none authenticate successfully, the attempt fails.
  • Roles from all authenticated realms are merged.
• org.apache.shiro.authc.pam.FirstSuccessfulStrategy
  • Only the information returned from the first successfully authenticated Realm will be used. All further Realms will be ignored. If none authenticate successfully, the attempt fails.
  • Roles from the first authenticated realm are used.

• org.apache.shiro.authc.pam.AllSuccessfulStrategy

  • All Realms listed in the securityManager.realms parameter must authenticate successfully for the overall attempt to be considered successful. If any one does not authenticate successfully, the attempt fails.
  • Roles from all realms are merged.

By default, Shiro authentication uses the authcStrategy = org.apache.shiro.authc.pam.AtLeastOneSuccessful strategy. This strategy setting, which causes a login to be attempted for all the realms listed in the securityManager.realms parameter . In addition, the  following strategies can be specified:

• authcStrategy = org.apache.shiro.authc.pam.FirstSuccessfulStrategy

  • Login will occur for the first realm where authentication is successful

• authcStrategy = org.apache.shiro.authc.pam.AllSuccessfulStrategy

  • Login will only occur when the authentication parameters apply for all realms listed in the securityManager.realms parameter.

or, if this is not set, in all the realms listen in the shiro.ini configuration file.

Note that roles from the iniRealm for authenticated user accounts are always merged to the list of roles. This happens for all strategies (This seems to be an error in Shiro.)

Multi-Realm Authentication and Authorization up to Release 1.12.3

Note Note however that the FirstSuccessfulStrategy strategy is incorrectly implemented and that a login to will be attempted for all the realms, even after a successful login has been noted. Login attempts carried out after a successful login has been noted will be logged at the [error] level. See issue JOC-437 for more information.

Multi-Realm Authentication and Authorization from Release 1.12.4 onwards

The Shiro authenticator is replaced by one written by the SOS, which is called by default.The SOS authenticator can also be called explicitly using the following lines of code

...

The SOS authenticator replaces the Shiro authenticator and allows the use of the three Shiro strategies:

...

• If one (or more) Realms authenticate successfully, the overall attempt is considered successful. If none authenticate successfully, the attempt fails.
• Roles from all authenticated realms are merged.

...

• Only the information returned from the first successfully authenticated Realm will be used. All further Realms will be ignored. If none authenticate successfully, the attempt fails.
• Roles from the first authenticated realm are used.

org.apache.shiro.authc.pam.AllSuccessfulStrategy

...

Authentication strategies listed above without unnecessary log file entries being made.

Note: roles from the  the iniRealm for authenticated users are always merged to the list of roles regardless of the strategy specified (This seems to be an error in Shiro.)See issue JOC-437 for more information.

Behavior for Accounts with Differing Passwords