Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Info Box added

...

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

Multi-Realm

...

Authentication and

...

Authorization up to Release 1.12.3

Consider the case of a user account that is registered for both a shiro and an LDAP realm. Such a configuration is shown in the next listing: one "newton" account is configured in the [users] section of the shiro.ini file 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. 

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

With the configuration listed above, if different passwords are used for the account on each realm then 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 behavioursbehaviors:

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

...

Note however that the FirstSuccessfulStrategy strategy is incorrectly implemented and that a login to be attempted for all the realms, even after a successful login has been noted. 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 be called explicitly using the following lines of code

Code Block
languagexml
authenticator = com.sos.auth.shiro.SOSAuthenticator
securityManager.authenticator=$authenticator

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

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

See issue JOC-437 for more information.

 

 

Info
titleImportant

The following points apply for a multi-realm environment and where one of the realms is the ini realm:

A) When the SOS Authenticator is used with the First Successful strategy:

  • If the authorization occurs through the ini realm then the user account will only be assigned the roles specified for the ini role.
  • If the authorization occurs through a realm other than the ini realm then, regardless of whether or not the same password is used in each realm:
    • the user account will be assigned the role(s) specified for the account in the authorizing realm
    • the user account will also be assigned the role(s) specified for the account in the ini realm (from our point of view this is an error in Shiro).
    • Note that the authorization can come from the ini realm because

Show If
useraa,ur
      • a) the password is incorrect or
      • b) another realm was listed before the ini realm and could allow the authentication

B) When using the At Least One Successfull strategy:

  • ...

C) When using the All Successfull strategy:

  • ...