arborint wrote:Can you explain these ideas with the standard RBAC terms like User/Subject, Role, Permissions, and Session? I am assuming that any system would be DataSource independent.
When I say data gateway, I mean an object that represents each of my models properties. I'm saying there seems to be opportunity for a pattern, that sits between the model and it's properties and fires off event triggers. It doesn't necessarily have to implement RBAC. I'm saying I'd write an abstract data access object that defines an interface for preAccess() and postAccess(), etc.. methods. RBAC would then be implemented and "hooked"* into the data access. The "property access gateway" ( the pattern I'm proposing, which I'm not sure if its an existing pattern so I'm using made up words, if you have a better term let me know ) would have no direct knowledge of which fields were allowed disallowed, and certainly would not be limited to allowing / disallowing access, it could be extended to modify the data, return a different property than what was asked for, etc.. depending on which plugins were loaded for the given property. An infastructure like this could prove useful as a central place to implement your RBAC on a field per field basis, without hard-coding anything in your models / controllers or limiting you to the concept of RBAC.
This "data access pattern" could just be called thru magic methods so you could access your properties with pure semantics, and separate out the "law and methods of access" ( Cross cutting concerns, or actual delegation ), from the "logic of access" ( core concerns, or actual business based logic )
For instance if a model should show a user one property if he is a guest, and another if he is "super admin type A", should a model necessarily know "super admin type A" exists? If not then should it even know the privilege exists? Why should it know about the privilege rule itself, it should only define business logic. A controller would be better then putting it in the model but still not perfect, as a controller tends to end up acting as a procedural transaction script. Its a fine line, and I'm not proposing separating the actual business logic from the model, just certain rules of property access that wouldn't make sense to put in the model. The pattern just like any other pattern would have the ability to be misused, but used semantically I think it has value
* I'm using the term "hooked" to describe any event that gets triggered, I'm using the term from svn hook scripts that can run post-commit and pre-commit, etc.. For instance on my development servers I have hook scripts to update my working copy, which happens to be the htdocs folder for apache ( so when I run a commit from my workstation the code gets pushed to a staging area on my network.. since apache cant directly serve files from a repository, and since there's no reason to keep running "svn update" to stage my code ), similarly a developer might want to run some procedure(s) before / after data access that allowed or disallowed access, redirected program flow, modified the data being passed thru, mapped data to other objects, etc.. ( possibilities would be unlimited )
Edit: I guess what I'm thinking of is basically a mix AOP and the decorator pattern? I don't know..
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.
http://en.wikipedia.org/wiki/Aspect-ori ... rogramming
Another good example of where a decorator can be desired is when there is a need to restrict access to an object's properties or methods according to some set of rules or perhaps several parallel sets of rules (different user credentials, etc). In this case instead of implementing the access control in the original object it is left unchanged and unaware of any restrictions on its use, and it is wrapped in an access control decorator object, which can then serve only the permitted subset of the original object's interface.
(taken from
http://en.wikipedia.org/wiki/Decorator_pattern)