Skip to end of metadata
Go to start of metadata

Introduction

Shiro can use multi-realm authentication and authorization - for example, authentication and authorization against a shiro.ini account and an LDAP account or against one or more 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

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 example to allow the configuration to be implemented by 'cut and paste' and a minimum of modification.

Both the realms in the example have an account with the name newton. In the Shiro ini realm this account is assigned the administrator role and in the LDAP realm it is assigned the it_operator role by way of the realm group roles mapping  publicLdapRealm.groupRolesMap = scientists : it_operator (The newton account is configured as a member of the scientists group on the LDAP server.)

Configuration for ini and LDAP Realms  Expand source

Realm Selection

In 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. 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. 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 causes a login to be attempted for all the realms listed in the securityManager.realms parameter or, if this is not set, in all the realms listen in the shiro.ini configuration file.

Authentication and Authorization with the FirstSuccessfulStrategy configured

The FirstSuccessfulStrategy strategy is incorrectly implemented in Shiro and a login will be attempted for all the realms, even after a successful login has been noted. In addition 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.

A new (SOS) authenticator is included in Release 12.4 onwards to replace the default Shiro authenticator. This authenticator stops the authentication process once a successful login has taken place when the First Successful strategy has been configured.. The SOS authenticator is configured using the following lines of code:

The SOS authenticator can be used with all three behavior strategies but it only causes the behavior of the First Successful strategy to be modified,

Passive Authentication and Authorization

When an LDAP realm user account is authenticated and there is an iniRealm with the same user name but this ini realm is not listed in the  securityManager.realms parameter, then by default role(s) configured for the ini realm account will be merged together with those of the LDAP realm account. Note that this will occur, regardless of whether or not the same password is used for both realm accounts.

The roleAssignmentFromIni = false LDAP realm parameter (default setting is true) can be used to suppress this behavior, In the example listed above this parameter would then be configured for the publicLdapRealm as:

  • publicLdapRealm.roleAssignmentFromIni = false

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

Behavior for Accounts with Differing Passwords

The following points apply for a multi-realm environment, where one of the realms is the ini realm and when the user accounts have a common name but different passwords:

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

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   
     

 

 

  • No labels