Hi Sven, It works like this:
Subject.login(authenticationToken) calls the SecurityManager. The SM then delegates to the Authenticator. The Authenticator is almost always an instance of ModularRealmAuthenticator This authenticator coordinates with the Realm instances you have configured and will call any Realm that supports the incoming AuthenticationToken (see Realm#supports javadoc). If your realm supports the inbound token, it will call Realm#getAuthenticationInfo. If you have more than one Realm configured, the ModularRealmAuthenticator knows how to aggregate the return values A nearly identical process occurs during authorization (Subject#isPermitted, Subject#hasRole, etc). If you subclass AuthorizingRealm, you return valid information in the AuthorizingRealm#doGgetAuthorizationInfo method. Shiro supports dynamic changes to your security model at runtime. But it caches Authorization information for better performance. So, if you change that data, you have to invalidate the cache for that particular user that has changed. To do that, call the 'clearCachedAuthorizationInfo' method any time you change a user's roles/permissions. The very next authorization check that occurs for that user will acquire the new authorization info and cache the new data for efficient re-use later. A good approach would be to have your realm listen for some type of user application event and then call the clearCachedAuthorizationInfo method based on the user identity associated with the event. HTH, Les On Thu, Sep 23, 2010 at 6:24 AM, 0xsven <[email protected]> wrote: > > Thank you for that. > > I have another question about the realm in common. When registering a realm > in the ini section. when does it get used ? any time a user is > authenticated? I have a little bit problems with understanding the whole > thing... :-/ > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/How-to-add-a-role-to-the-subject-tp5562700p5563015.html > Sent from the Shiro User mailing list archive at Nabble.com. >
