The one thing I've noticed in other frameworks is that they treat security outside of a domain context. Static security models at service level and/or domain object levels are good but I think it paints only a part of the picture. For example, imagine a case where the user is allowed to issue a command/invoke a service; but the constraints are that he/she can do this from 9 AM to 5 PM. This doesn't even take into consideration what state the domain object in question is in (e.g. 'Active' status). In my mind the domain context in which the request is made is very important and that having a role(or permissions) is just a starting point. I've seen a lot of IF statements where the permission is checked AND then a dozen more conditions that are domain specific is checked. In my mind they're all together and is a part of the security model.
Ok, next. Let's say that the user got the authorization to issue the command successfully; the domain object (or objects) returned should also have authorization metadata associated with its properties so that the GUI (or another client) is able to figure out what can be changed and what can't be. I actually think qi4j might already be handling this with the Property interface (@Immutable also). I've read too many RBAC related articles so maybe I'm wishing for too much :) The only thing that comes to mind to me is to use some kind of rules engine in addition to the usual roles+capabilities mappings. On Tue, May 12, 2009 at 1:45 PM, Raoul Duke <[email protected]> wrote: >> I have just realized that we probably need to become more security >> concerned than we have been so far. >> >> Anyone has any thoughts on this topic? > > I don't understand your situation entirely, apologies if I'm way off > base, and I suspect you want to go with standard Java approaches to > managing security. But... I'll throw out $0.02 that most security is > based on access control lists, and those are 9 times out of 10 > fundamentally flawed. A different and often mostly better approach > that might be worth thinking about is to use 'object capabilities' for > authorization. > > sincerely. > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
