Introduction
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.
Scope
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.
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 listing: below.
- One "newton" account is configured in the
[users]
section of theshiro.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 theshiro.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)
- 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
- 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)
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 thepublicLdapRealm
account they will be given the roles for both theiniRealm
andpublicLdapRealm
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
By default, Shiro authentication uses the authcStrategy = org.apache.shiro.authc.pam.AtLeastOneSuccessful
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.
- Login will only occur when the authentication parameters apply for all realms listed in the
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
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.AtLeastOneSuccessfulStrategy
(default strategy)- 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.
- All Realms listed in the
Note: roles from 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.
Important
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 realm. The LDAP realm(s) will be ignored.
- If the authorization occurs through an LDAP 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 (first) authorizing realm.
- The user account will also be assigned the role(s) specified for the account in the ini realm.
- This behavior ensures that a login is possible in the event of problems with the LDAP realm(s).
- The order in which the realms are specified in the
securityManager.realms
parameter is not significant here. - The ldap.roleAssignmentFromIni=false setting (default true) can be used to modify the behavior of the First Successful strategy so that roles from the ini realm are not assigned.
B) When using the At Least One Successful strategy:
- ...
C) When using the All Successful strategy:
- ...