...
Code Block | ||
---|---|---|
| ||
authenticator = com.sos.auth.shiro.SOSAuthenticator
securityManager.authenticator=$authenticator
# Please note that you have to assign the realms to the authenticator instead to the securityManager.realms
authenticator.realms = $iniRealm, $ldapRealm
|
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,
...
- 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. See the Suppressing assignment of the ini Realm section below.
Show If | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||
When the SOS Authenticator is used with the At Least One Successful strategy:
When the SOS Authenticator is used with the All Successful strategy:
|
Suppressing assignment of the ini Realm
Display feature availability | ||
---|---|---|
|
When the First Successful strategy is used when an ini realm and one or more LDAP realms have accounts with common user names and separate passwords, the roles for the ini realm will be assigned by default when the login is carried out for one of the LDAP realms. This behavior can be suppressed by setting the roleAssignmentFromIni parameter to false for the LDAP realms in the environment. This is shown in the code example below:
Suppressing assignment of the ini Realm
Display feature availability | ||
---|---|---|
|
When the First Successful strategy is used when an ini Realm and one or more LDAP Realms have accounts with common user names and separate passwords, the roles for the ini Realm will be assigned by default when the login is carried out for one of the LDAP Realms. This behavior can be suppressed by setting the roleAssignmentFromIni property to false for the LDAP Realms in the environment. This is shown in the code example below:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[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 | ||||||
Code Block | ||||||
| ||||||
[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.searchBasegroupRolesMap = 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 publicLdapRealm.roleAssignmentFromIni = false rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter rolePermissionResolver.ini = $iniRealm securityManager.realms = $publicLdapRealm, $iniRealm cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager securityManager.cacheManager = \ scientists : it_operator, \ mathematicians: all publicLdapRealm.roleAssignmentFromIni = false rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter rolePermissionResolver.ini = $iniRealm authcStrategy = org.apache.shiro.authc.pam.SOSFirstSuccessfulGroupStrategy securityManager.authenticator.authenticationStrategy = $authcStrategy securityManager.realms = $publicLdapRealm, $iniRealm cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager securityManager.cacheManager = $cacheManager |
With the above configuration:
...
Display feature availability | ||
---|---|---|
|
Logical selection Use of realm group strategies can also be implementedconfigured. These strategies determine, for example, that an account will only be authenticated for one realm when it can also be authenticated for all the realms in that group.
Configuration
This feature is activated by inserting the following line of code in the [main]
section of the Shiro ini file:
securityManager.authenticator.authenticationStrategy = $authcStrategy
In addition a logical The group strategy has to be implemented configured - the following four strategies are available:
...
authcStrategy = com.sos.auth.shiro.SOSFirstSuccessfulGroupStrategy
Finally all group realms are to be named following the syntax:
securityManager.authenticator.authenticationStrategy = $authcStrategy
For the grouping of strategies a naming convention has to be followed that includes to separate the group form the Realm name by a hashtag, for example
A#Ldap1
group#name
Example
The following example uses two Groups "A" and "B", each with two realms. An account with a common User Name and Password is configured for all Realms
A#ldap1
roles = a1
A#ldap2
roles = a2
B#ldap1
roles = b1
B#ldap2
roles = b2
Here is an example main section for this szenario
Realms each. Roles "r1" and "r2" are configured per Realm by the groups/roles mapping instruction:
Code Block | ||||
---|---|---|---|---|
| ||||
[main] A#Ldap1 = com.sos.auth.shiro.SOSLdapAuthorizingRealm A#Ldap1.userDnTemplate = uid={0},dc=example,dc=com A#Ldap1.searchBase = dc=example,dc=com A#Ldap1.contextFactory.url = ldap://ldap.forumsys.com:389 A#Ldap1.groupNameAttribute = ou A#Ldap1.userNameAttribute = uid A#Ldap1.rolePermissionResolver = $rolePermissionResolver A#Ldap1.userSearchFilter = (uniqueMember=uid=%s,dc=example,dc=com) A#Ldap1.groupRolesMap = \ scientists : it_operatorr1, \ mathematicians: allr2 A#Ldap1.roleAssignmentFromIni = false A#Ldap2 = com.sos.auth.shiro.SOSLdapAuthorizingRealm ... B#Ldap1 = com.sos.auth.shiro.SOSLdapAuthorizingRealm ... B#Ldap2 = com.sos.auth.shiro.SOSLdapAuthorizingRealm ... rolePermissionResolver = com.sos.auth.shiro.SOSPermissionResolverAdapter rolePermissionResolver.ini = $iniRealm authcStrategy = org.apache.shiro.authc.pam.SOSFirstSuccessfulGroupStrategy securityManager.authenticator.authenticationStrategy = $authcStrategy securityManager.realms = $A#publicLdapRealm cacheManager$A#Ldap1,$A#Ldap2,$B#Ldap1,$B#Ldap2 cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager securityManager.cacheManager = $cacheManager |
Find a number of examples for the behavior with different strategies from the following chapters.
SOSFirstSuccessfulGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.authc.pam.SOSFirstSuccessfulGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
Explanation
- All Realms with the same group will be checked group-wise.
- In every group there must be one Realm that can be authenticated, otherwise authentication will fail for all groups.
- The roles from the first Realm per group will be added to the roles the user is assigned.
Authentication Matrix
A#Ldap1 | A#Ldap2 | B#Ldap1 | B#Ldap2 | Resulting Role Assignments |
---|---|---|---|---|
x | x | x | x | A#Ldap1, B#Ldap1 |
x | x | x | A#Ldap1, B#Ldap1 | |
x | x | x | A#Ldap1, B#Ldap2 | |
x | x | x | A#Ldap1, B#Ldap1 | |
x | x | x | A#Ldap2, B#Ldap1 | |
x | x | fail | ||
x | x | A#Ldap1, B#Ldap1 | ||
x | x | A#Ldap1, B#Ldap2 | ||
x | x | A#Ldap2, B#Ldap1 | ||
x | x | A#Ldap2, B#Ldap2 | ||
x | x | fail | ||
x | fail | |||
x | fail | |||
x | fail | |||
x | fail | |||
fail |
SOSAllSuccessfulGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.authc.pam.SOSAllSuccessfulGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
Explanation
- All realms with the same group will be checked group-wise.
- In at least one group all Realms must be authenticated.
- The roles from Realms in groups where all Realms can be authenticated will be merged to the roles the user is assigned.
Authentication Matrix
A#Ldap1 | A#Ldap2 | B#Ldap1 | B#Ldap2 | Resulting Role Assignments |
---|---|---|---|---|
x | x | x | x | A#Ldap1, A#Ldap2, B#Ldap1, B#Ldap2 |
x | x | x | B#Ldap1, B#Ldap2 | |
x | x | x | A#Ldap1, A#Ldap2 | |
x | x | x | A#Ldap1, A#Ldap2 | |
x | x | x | B#Ldap1, B#Ldap2 | |
x | x | A#Ldap1, A#Ldap2 | ||
x | x | fail | ||
x | x | fail | ||
x | x | fail | ||
x | x | fail | ||
x | x | B#Ldap1, B#Ldap2 | ||
x | fail | |||
x | fail | |||
x | fail | |||
x | fail | |||
fail |
SOSAllSuccessfulFirstGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.authc.pam.SOSAllSuccessfulFirstGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
Explanation
- All Realms with the same group will be checked group-wise.
- In at least one group all Realms must be authenticated.
- The roles from Realms in the first group where all Realms can be authenticated will be merged with other roles the user is assigned.
Authentication Matrix
A#Ldap1 | A#Ldap2 | B#Ldap1 | B#Ldap2 | Resulting Role Assignments |
---|---|---|---|---|
x | x | x | x | A#Ldap1, A#Ldap2 |
x | x | x | B#Ldap1, B#Ldap2 | |
x | x | x | A#Ldap1, A#Ldap2 | |
x | x | x | A#Ldap1, A#Ldap2 | |
x | x | x | B#Ldap1, B#Ldap2 | |
x | x | A#Ldap1, A#Ldap2 | ||
x | x | fail | ||
x | x | fail | ||
x | x | fail | ||
x | x | fail | ||
x | x | B#Ldap1, B#Ldap2 | ||
x | fail | |||
x | fail | |||
x | fail | |||
x | fail | |||
fail |
SOSAtLeastOneSuccessfulGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.cache.MemoryConstrainedCacheManager securityManager.cacheManager = $cacheManager |
Example Behavior with Different Strategies
SOSFirstSuccessfulGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.authc.pam.SOSFirstSuccessfulGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
All realms with the same group will be checked group-wise.
In every group there must be one realm that can be authenticated.
If none of the realms in at least one group authenticate then authentication will fail for all groups.
The roles from the first realm per group will be merged to the roles the user has.
Example:
- If A#ldap1, A#ldap2 and B#ldap2 can authenticate than the user will have the roles a1 and b2.
- If A#ldap2 and B#ldap1 can authenticate than authentication will fail.
SOSAllSuccessfulGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.authc.pam.SOSAllSuccessfulGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
All realms with the same group will be checked group-wise.
In at least one group all realms must be authenticated.
The roles from realms in groups where all realms can be authenticated will be merged to the roles the user has.
Examples:
- If A#ldap1, A#ldap2 and B#ldap1, B#ldap2 can authenticate than the user will have the roles a1,a2,b1,b2.
- If A#ldap1, A#ldap2 and B#ldap1 can authenticate than the user will have the roles a1,a2.
- If A#ldap2 and B#ldap1 can authenticate than authentication will fail.
SOSAllSuccessfulFirstGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.authc.pam.SOSAllSuccessfulFirstGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
All realms with the same group will be checked group-wise.
In at least one group all realms must be authenticated.
The roles from realms in the first group where all realms can be authenticated will be merged with other roles the user may have.
Example:
- If A#ldap1, and B#ldap1, B#ldap2 can authenticate than the user will have the roles b1,b2
- If A#ldap1, A#ldap2 and B#ldap2 can authenticate than the user will have the roles a1,a2
- If A#ldap1 and B#ldap2 can authenticate than authentication will fail.
SOSAtLeastOneSuccessfulGroupStrategy
Code Block |
---|
authcStrategy = org.apache.shiro.authc.pam.SOSAtLeastOneSuccessfulGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
All realms with the same group will be checked group-wise.
At least one realm must be authenticate in every group.
The roles from realms that have authenticated will be merged with other roles the user may have.
Example:
...
.authc.pam.SOSAtLeastOneSuccessfulGroupStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy |
Explanation
- All Realms with the same group will be checked group-wise.
- At least one Realm must be authenticated in every group.
- The roles from Realms that have been authenticated will be merged with other roles the user is assigned.
Authentication Matrix
A#Ldap1 | A#Ldap2 | B#Ldap1 | B#Ldap2 | Resulting Role Assignments |
---|---|---|---|---|
x | x | x | x | A#Ldap1, A#Ldap2, B#Ldap1, B#Ldap2 |
x | x | x | A#Ldap1, B#Ldap1, B#Ldap2 | |
x | x | x | A#Ldap1, A#Ldap2, B#Ldap2 | |
x | x | x | A#Ldap1, A#Ldap2, B#Ldap1 | |
x | x | x | A#Ldap2, B#Ldap1, B#Ldap2 | |
x | x | fail | ||
x | x | A#Ldap1, B#Ldap1 | ||
x | x | A#Ldap1, B#Ldap2 | ||
x | x | A#Ldap2, B#Ldap1 | ||
x | x | A#Ldap2, B#Ldap2 | ||
x | x | fail | ||
x | fail | |||
x | fail | |||
x | fail | |||
x | fail | |||
fail |
...