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 <[email protected]> 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 <[email protected]> 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.
