Page 2 of 2
Posted: Thu Sep 02, 2004 6:38 pm
by timvw
Posted: Fri Sep 03, 2004 4:09 pm
by Christopher
I have read Marston's amd others on Role-Based Access Controls systems. They are why I don't think database solutions are very good for this problem. Ultimately they just return a static list of pairs or triplets of access info. That's why I don't think a query based solution is the best way to go. Database solutions to this problem end up with 3,4,5 tables that contain more relations than data. Fetching and updating are complex and do not map onto HTML selects very well. The best reason to implement a system like Marston's is if you have to generate lots of reports on the access controls. If you don't need the reporting, you can effectiively "cache" the pairs or triplets in each user's record.
Posted: Fri Sep 03, 2004 7:03 pm
by timvw
arborint wrote:I have read Marston's amd others on Role-Based Access Controls systems. They are why I don't think database solutions are very good for this problem. Ultimately they just return a static list of pairs or triplets of access info. That's why I don't think a query based solution is the best way to go.
If the data is _really_ static it should not be a problem to cache the outcome of the queries. IMHO it would be a step back to use hardcoded values in a file instead of a database.
arborint wrote:
Database solutions to this problem end up with 3,4,5 tables that contain more relations than data.
There is no difference in complexity between storing the data in a database than in a file (which you can see as a row in the filesystem database)
arborint wrote:
Fetching and updating are complex and do not map onto HTML selects very well.
I don't see a relation between sql select and update and html select tag?
arborint wrote:
The best reason to implement a system like Marston's is if you have to generate lots of reports on the access controls. If you don't need the reporting, you can effectiively "cache" the pairs or triplets in each user's record.
I wouldn't use a RBAC system to log the usage of my scripts.
I'd log the data a user reads-inserts-updates-deletes. And as they do that through my database abstraction classes, i think the best place for this code belongs in those classes and not in my RBAC system.
Posted: Sat Sep 04, 2004 4:42 pm
by Christopher
1. By "cache" I didn't mean in a file, I meant in a field in the user data record instead of in 3,4,5 tables with relations.
2. Maintaining RBAC relations is complex and and in my experience does not map easily onto the human selections made to describe them. Stll not talking about files.
3. By "reporting" I meant generating reports such as: show all users with a specified role, or all user in company X with group Y. Not logging. As I said, I have seen little need for this type of reporting.
Posted: Sat Sep 04, 2004 6:12 pm
by McGruff
arborint wrote:3. By "reporting" I meant generating reports such as: show all users with a specified role, or all user in company X with group Y. Not logging. As I said, I have seen little need for this type of reporting.
Just thought I'd expand on this a bit since it highlights the reasons why and why not to denormalise a database.
Storing a whole bunch of information in a single field, as arborint has suggested, is more "brittle" than a fully normalised db because it makes it harder to gather certain types of information.
However, if you know exactly what you want and know that requirements are not going to change, that brittleness won't matter and this could be a valid solution. That's a difficult decision to make though - clients might well request new features in the future.
I tend to follow a general rule of always start off with a fully normalised db and only allow myself to be dragged, kicking and screaming, into denormalising if there really is a compelling reason to do so.
Posted: Sun Sep 05, 2004 4:45 pm
by Christopher
I think that is a good summary of the issue. Perhaps ones background and outlook determines what is brittle or not. I have often found that for permissions it is often easier to parse and rebuild a permission string when requirements change than to add/remove/rebuild tables and relations.
I tend to start with the simplest solution and add compexity and refactor as necessary. Ultimately if you can define the interface (e.g. $user->hasPermission() ) then you can refactor the code beneath to use either method. I have switched permission systems in this way when the requirements have become simpler or more complex.
One final note - companies often want complexity in areas like permissions but do not forsee the maintainence and problems of such systems. It is easier to define and implement fine grained systems than to live with them.
Posted: Thu Sep 09, 2004 7:32 pm
by lazy_yogi
Wow, nice link. Seems a little complex on first pass, but on reading it over, it's a pretty elegant solution