Belatedly... there are already some interesting ideas in this thread, but just wanted to pick up on your original post ...
On Wednesday, 7 August 2013, David Tildesley wrote: > > We are looking at building a RBAC capability that evaluates security > entitlements for users. e.g. > ... > if ((user.jobTitle.name == "case worker")) AND (user.org.name == > "companyA") AND (user.location.code == "NY")) then > addRole(user, securityRole) > > but we don't want to have to recompile the application each time a rule > changes or a rule is added or removed. > ... > The solution would need to fit nicely with ISIS. > ... > Any ideas would be appreciated. > > N.B. do not get confused with Shiro security for the application - that's > orthogonal to the functional capability that we are wanting to build. > Even though you say you don't want to think of this in terms of security, it does feel like a security concern to me... at least insofar that "addRole(user, securityRole)" implies access to specific functionality? At any rate, I just wanted to point out that you could create your own implementation of the AuthorizationManager, passing in an Authorizor that could be chain the original ShiroAuthenticatorOrAuthorizor along with another Authorizor that would use groovy or SQL or Drools or whatever. We do this on the Irish NO project, where we have one Authorizor that integrates with Active Directory, and then another Authorizor that loops back to the system's own representation of the current user (vetoing access if that user has been blocked). I think this idea of having a domain object representing the current user has been discussed in previous threads. The starting point is a custom subclass of AuthorizationManagerStandardInstallerAbstract. Register it in isis.properties (under "isis.authorization" key) using its fully qualfied class name. HTH Dan
