Hello Les,
Thank you for the information. It turns out the reason why the correct
realm was not being used was because I was configuring a single realm each
time as opposed to a collection of realms. The PortalRealm was being
overwritten with the BaselinePortalRealm. We were configuring single realms
when we were using more that one security manager. That being said, I have
to configure a collection of realms that contain the 2 realms that I want to
utilize.
I did in fact take a look a the source code for the ModularRealmAuthorizer
shortly before you posted. The functionality we need now is to ALWAYS check
both realms (as opposed to having it short circuit if one realm is true via
the documentation). I have created a custom class that extends
ModularRealmAuthorizer. I see that there is not a strategy that I can pass
it similar to the authentication "AllSuccessfulStrategy". Would my only
option to be to go into the code and modify it so that it checks both
realms? I have modified the two main methods below, however, it seems that
I may need to modify some other methods.
The easier way would be to inspect the Principals and have the realm return
null if it should not participate in the authorization. That way we don't
have to call both realms, but just the correct one. However, I don't know
if I have the information I need in the Principals object. I will check.
/**
* Returns <code>true</code> if ALL of the configured realms'
* {@link #isPermitted(org.apache.shiro.subject.PrincipalCollection,
String)} returns <code>true</code>,
* <code>false</code> otherwise.
*/
@Override
public boolean isPermitted(PrincipalCollection principals, String
permission) {
assertRealmsConfigured();
for (Realm realm : getRealms()) {
if (!(realm instanceof Authorizer)) continue;
if (!((Authorizer) realm).isPermitted(principals, permission)) {
return false;
}
}
return true;
}
/**
* Returns <code>true</code> if ALL of the configured realms'
* {@link #isPermitted(org.apache.shiro.subject.PrincipalCollection,
Permission)} call returns <code>true</code>,
* <code>false</code> otherwise.
*/
@Override
public boolean isPermitted(PrincipalCollection principals, Permission
permission) {
assertRealmsConfigured();
for (Realm realm : getRealms()) {
if (!(realm instanceof Authorizer)) continue;
if (!((Authorizer)
realm).isPermitted(principals, permission)) {
return false;
}
}
return true;
}
Les Hazlewood-2 wrote
> P.S. The SecurityManager defaults to using an instance of
> ModularRealmAuthorizer [1] to coordinate how Realms are consulted
> during an authorization check.
>
> You can look at that and see how it works, or you could always just
> implement a custom Authorizer that coordinates with your Realms
> however you see fit.
>
> [1]
> https://github.com/apache/shiro/blob/trunk/core/src/main/java/org/apache/shiro/authz/ModularRealmAuthorizer.java
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>
>
> On Thu, May 16, 2013 at 9:43 AM, Les Hazlewood <
> lhazlewood@
> > wrote:
>> It is expected that all available realms are configured on the
>> SecurityManager at application startup. The SecurityManager will
>> coordinate the Realms (often through an Authenticator or Authorizer)
>> instance during authentication and authorization.
>>
>> A Realm can choose to participate in an authentication attempt by
>> implementing the supports(AuthenticationToken) method.
>>
>> A Realm can choose to participate in an authorization check by
>> returning null or false (depending on the method being called). Also,
>> for AuthorizingRealm implementations (as most Realms are), you can, in
>> the doGetAuthorizationInfo method implementation, inspect the
>> PrincipalCollection argument. If your realm recognizes the
>> PrincipalCollection, it can return an AuthorizationInfo instance. If
>> it doesn't recognize it, it can return null.
>>
>> The sequence for Realm authorization is covered here:
>> http://shiro.apache.org/authorization.html#Authorization-AuthorizationSequence
>>
>> Also, I highly recommend seeing the AuthorizingRealm source code so
>> you can get a feel for how it works and what features there are that
>> you can leverage (e.g. authorization caching):
>> https://github.com/apache/shiro/blob/trunk/core/src/main/java/org/apache/shiro/realm/AuthorizingRealm.java
>>
>> HTH,
>> --
>> Les Hazlewood | @lhazlewood
>> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>>
>>
>> On Wed, May 15, 2013 at 3:51 PM, ApacheNinja <
> dpryce7@
> > wrote:
>>> Hello,
>>>
>>> After further investigation I see the problem but I do not know why it
>>> is
>>> doing this. I see the DefaultSecurityManager has an Authorizer object
>>> that
>>> has a list of realms. We have 2 types of realm objects: A PortalRealm
>>> and a
>>> PortalBaselineRealm. When the isPermitted() is called for a user, it
>>> should use the PortalRealm object. However, running the debugger I see
>>> that
>>> there is 1 object in the realms list and it is a PortalBaseRealm. It
>>> should
>>> be the PortalRealm. This only started happening when changed the code
>>> to
>>> use one Security Manager. This does not happen when I create a new
>>> Security
>>> Manager object each time I authenticate (the old way). We are setting
>>> the
>>> realm on the Security Manager object via
>>> securityManager.setRealm(realm).
>>> Thank you for your help in advance.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://shiro-user.582556.n2.nabble.com/Too-many-threads-created-when-calling-isPermitted-tp7578725p7578741.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Too-many-threads-created-when-calling-isPermitted-tp7578725p7578747.html
Sent from the Shiro User mailing list archive at Nabble.com.
