Patterns Tutorial Series (part 1): RBAC Domain Model

[lastcraft]

Hi...

Once we get it working in its current state we can iterate and refactor. What do you think about this approach?

It is actually my prefered approach (tracer bullet). I just didn't want to end up feeling guilty if the chosen refactoring ended up nuking all your code...

yours, Marcus

p.s. This reminds me of pair programming at work. One person "drives" (types) whilst the other muses over the design and act as the brake.

[Resolution]

Does anyone know what DB seratonin is using?

[el8]

Does anyone know what DB seratonin is using?

mysql, see CONNECTION_STRING in test.php

define('CONNECTION_STRING', 'mysql://root:@localhost/test');

I guess that you have problem with fetchRow. I had
provided sql schema is using 'usage' as table name and since usage is reserved word table cannot be created. Change USAGE_TABLE constant in pear_storage.php to new tbl name.

[Captain Proton]

[offtopic]

Change USAGE_TABLE constant

If you have to change a constant, it doesn't really have any business being a constant, right? [/offtopic]

[seratonin]

I had to make a minor change to the database schema. I left out the fact that together the two id's make the primary key for both connective tables (usage_assign and perm_assign). Also, regarding the reserved word "usage". I ran into the problem of MySQL not liking it so I ended up putting "`" marks around it and got it to work. The best idea, I think, is to just change the name of the table all together.

Thanks,

JT

[seratonin]

It is actually my prefered approach (tracer bullet). I just didn't want to end up feeling guilty if the chosen refactoring ended up nuking all your code...

No worries. The intention is to refactor and improve the design. If that means replacing all of my code -- well then, so be it. Continuous improvement is the ticket, besides, it didn't take very long to write that code anyway (as I'm sure you, and others can tell).

JT

[dagfinn]

Thanks to all of you for an extremely interesting thread. I've finally managed to read all of it. At the risk of seeming grumpy, I'll start by mentioning what struck me as the worst feature of this design: the term "usage". It took some reading of the actual code to figure out that a Usage is actually a user. I was thinking it must be some sort of relationship between two objects.

I see that lastcraft doesn't like User objects, but as far as I can tell, all you've done is use a different word. If you'd called it User instead of Usage, it would be exactly the same design, and except for possible name conflicts, it would work exactly the same.

It's pure obfuscation as far as I can tell. Calling it Foo would make the code more readable, it would be less misleading.

[seratonin]

One possible refactoring is to move some of the common code from the RowDataGateway implementations into a super class.

For example:

<?php
class PearRowDataGateway {
    var $_connection;

    function PearRowDataGateway(&$connection) {
        $this->_connection =& $connection;
    }

    function insertString() {
        return "";
    }

    function updateString() {
        return "";
    }

    function deleteString() {
        return "";
    }

    function insert() {
        $this->executeQuery($this->insertString());
    }

    function update() {
        $this->executeQuery($this->updateString());
    }

    function delete() {
        $this->executeQuery($this->deleteString());
    }
    
    function &load(&$row) {
        // ...
    }

    function executeQuery($sql) {
        $this->_connection->query($sql);
        if (DB::isError($this->_connection)) {
            die($this->_connection->getMessage());
        }
    }
}
?>

This would make the PearUsageGateway implementation look like this:

<?php
define('USAGE_TABLE', '`usage`');
define('USAGE_TABLE_ID', 'id');
define('USAGE_TABLE_NAME', 'name');

class PearUsageGateway extends PearRowDataGateway {
    var $_id;
    var $_name;

    function PearUsageGateway(&$connection) {
        parent::PearRowDataGateway($connection);
    }

    function setName($name) {
        $this->_name = $name;
    }

    function getName() {
        return $this->_name;
    }

    function setUsageId($id) {
        $this->_id = $id;
    }

    function getUsageId() {
        return $this->_id;
    }

    function insertString() {
        return "INSERT INTO " . USAGE_TABLE . " (" . USAGE_TABLE_NAME . ") VALUES ('" . $this->_name . "')";
    }

    function updateString() {
        return "UPDATE " . USAGE_TABLE . " SET " . USAGE_TABLE_NAME . "='" . $this->_name . "' WHERE " . USAGE_TABLE_ID . "=" . $this->_id;
    }

    function deleteString() {
        return "DELETE FROM " . USAGE_TABLE . " WHERE " . USAGE_TABLE_NAME . "='" . $this->_name . "'";
    }

    function &load(&$row) {
        $gateway =& new PearUsageGateway($this->_connection);
        $gateway->setUsageId($row['id']);
        $gateway->setName($row['name']);
        return $gateway;
    }
}
?>

Unfortunately, this doesn't buy us much. Maybe if we can somehow make the "load" function more generic it would be worthwhile.

JT

[seratonin]

Thanks to all of you for an extremely interesting thread. I've finally managed to read all of it. At the risk of seeming grumpy, I'll start by mentioning what struck me as the worst feature of this design: the term "usage". It took some reading of the actual code to figure out that a Usage is actually a user. I was thinking it must be some sort of relationship between two objects.

I see that lastcraft doesn't like User objects, but as far as I can tell, all you've done is use a different word. If you'd called it User instead of Usage, it would be exactly the same design, and except for possible name conflicts, it would work exactly the same.

It's pure obfuscation as far as I can tell. Calling it Foo would make the code more readable, it would be less misleading.

Thank you for the feedback. You bring up some good points about our naming convention. I am also not too fond of "Usage". Maybe we can come up with some alternatives.

JT

[lastcraft]

Hi...

It took some reading of the actual code to figure out that a Usage is actually a user.

It is not a User and that is the whole point . It is just an access token held by a real person or another machine. Calling it a User would be flat out mismodelled because of the potential one to many between User and Usage and all the extra information that would be held in User, but not Usage.

Ok, "Usage" is perhaps a bit duff. "Access" has too many connotations, as does "Key". "Login" smacks of authentication rather than authorisation. I am a bit stuck.

yours, Marcus

[seratonin]

Hi...



It is not a User and that is the whole point . It is just an access token held by a real person or another machine. Calling it a User would be flat out mismodelled because of the potential one to many between User and Usage and all the extra information that would be held in User, but not Usage.

Ok, "Usage" is perhaps a bit duff. "Access" has too many connotations, as does "Key". "Login" smacks of authentication rather than authorisation. I am a bit stuck.

yours, Marcus

Principal

[Resolution]

Which DB class are we using? Or is it just the standard fair of function calls?

[Resolution]

Hi...



It is not a User and that is the whole point . It is just an access token held by a real person or another machine. Calling it a User would be flat out mismodelled because of the potential one to many between User and Usage and all the extra information that would be held in User, but not Usage.

Ok, "Usage" is perhaps a bit duff. "Access" has too many connotations, as does "Key". "Login" smacks of authentication rather than authorisation. I am a bit stuck.

yours, Marcus

How about
client_handle,
client_id,
client_pointer,
client_ref,
client_allusion,
usage_ticket,
dog_tag,
id_bracelet,

or even
passport.

[lastcraft]

Hi...

How about
client_handle,
client_id,
client_ref,
or even
passport.

Passport is the right idea but carries extra meaning. AccessKey? What do you call something that just has a bunch of roles or permissions and is an identifier? Just UserId is possible.

yours, Marcus

[seratonin]

Which DB class are we using? Or is it just the standard fair of function calls?

I am using PEAR DB.

JT

[seratonin]

Why don't we use "Principal" and be done with it? Here are some excerpts from the Java API:

public interface Principal

This interface represents the abstract notion of a principal, which can be used to represent any entity, such as an individual, a corporation, and a login id.

and

public class Principal extends Object

A class that contains information about the identity of the client, for access control and other purposes. It contains a single attribute, the name of the Principal, encoded as a sequence of bytes.

To me, this sounds like what we want...

JT

[lastcraft]

Hi...

Why don't we use "Principal" and be done with it?

Because I didn't realise what the word meant . Cool, that's a good find.

yours, Marcus

[seratonin]

Hi...



Because I didn't realise what the word meant . Cool, that's a good find.

yours, Marcus

We could have the Authenticator return a Principal object that contains either an id or a name which the Authenticator uses to gather permissions.

JT

[dagfinn]

Hi...



It is not a User and that is the whole point . It is just an access token held by a real person or another machine. Calling it a User would be flat out mismodelled because of the potential one to many between User and Usage and all the extra information that would be held in User, but not Usage.

Ok, "Usage" is perhaps a bit duff. "Access" has too many connotations, as does "Key". "Login" smacks of authentication rather than authorisation. I am a bit stuck.

yours, Marcus

You're right, that had already occurred to me. What also occurred to me is that this is what is commonly called a user account.

[dagfinn]

Here's my next reaction to the implementation.

It can be simplified by removing the PearAuthorizationEdit class and using the gateways directly. (I realize there's a reason why it's there, but let's look at the alternative before discussing the objections to it.) In the setUp method in the test class, we can do something like:

$db =& DB::connect(CONNECTION_STRING);
$fred = & new PearUsageGateway($db);
$fred->setName('fred');
$fred->insert();
$pleb = & new PearRoleGateway($db);
$pleb->setName('pleb');
$pleb->insert();
$do_stuff = new PearPermissionGateway($db);
$do_stuff->setName('do_stuff');
$do_stuff->insert(); 

To assign roles and permissions, we have to move and simplify a couple of methods so we can do it like this:

$fred->assignRole($pleb);
$pleb->permit($do_stuff); 

I would also simplify the Gateway interface so I wouldn't have to set the names explicitly:

$fred = & new PearUsageGateway('fred');
$fred->insert(); 

Now for the objection, or what I think is the objection (there may be others): The PearAuthorizationEdit is designed as a Remote Facade even though it's not currently used remotely. So if it's to be used as a remote interface, there's a performance gain from commiting all the work at once.

My response to that is:

• The remote interface is only theoretical at this point and I haven't seen any compelling arguments that is likely to become real.
• The class only does operations that are done relatively rarely, so it's very unlikely to become a performance bottleneck.
• The implementation as it currently stands would be slightly more efficient with my proposed change, since you don't have to get the objects from the database when you assign. (If they're already available, as they are in the test class.)

[Azmo]

It is not a User and that is the whole point . It is just an access token held by a real person or another machine. Calling it a User would be flat out mismodelled because of the potential one to many between User and Usage and all the extra information that would be held in User, but not Usage.

Ok, "Usage" is perhaps a bit duff. "Access" has too many connotations, as does "Key". "Login" smacks of authentication rather than authorisation. I am a bit stuck.

The choice to store extra information in the User object is made by the developers. If they model an object in such a way that it contains too much data or functionality, then it is their fault, not the object's. Personally, I blame the Domain Model, because it forces our thoughts in the direction of how the user interprets the application instead of the true nature of the application itself.

I think what we're really dealing with here is the unique identity of a remote client. And IMO permissions and whatnot should be kept in separate objects, since authentication and authorization are two separate concerns.

I also have a question for you guys working on this project: how would it handle a more complex situation, like a message board? Here users are allowed to edit or delete their own posts and topics on some forums, but not on others. Moderators are allowed to modify posts written by anyone on the forums which they moderate. Admins are allowed to do anything they like.

How would your implementation of RBAC deal with this, or even higher levels of complexity?

[Resolution]

How would your implementation of RBAC deal with this, or even higher levels of complexity?

Great question! I thought about this and came to the conclusion that one simply would need a ownership FLAG for all data. The flag would be for a single 'user id' or 'group id'. The permissions should then be able to define what groups or users may then edit, delete, ect. any post or forums, ect. in regard to data ownership.

To deal with a SPECIFIC forum (row) in a table or any row table data specificly for that matter one could simply "anchor" to that row's unique key for the data needing to be handled.

For this very reason, I ask if we could slow down the development some. This may mean a MAJOR rewritting of what has been done is needed if these ideas are adopted. Anyhow, I have some tables done but they are in conflict with has been done so far.... So, if you guys want to see some of those ideas, let me know. Otherwise, I'm helping out the current plan any way I can!

Make sense?

[lastcraft]

Hi...

It can be simplified by removing the PearAuthorizationEdit class and using the gateways directly.

We currently have three abstractions: Storage, Gateways, PEAR. Storage basically is a data accessor and little more and so this and the Gateways are redundant with respect to each other. In practice I think the PEAR one will be redundant too as it only abstracts teh connection, not SQL specifics.

In the setUp method in the test class, we can do something like:

I don't think the code should be driving the test case. The problem with your new test code is that it is too implementation specific. The client code is getting way more complicated as well.

Now for the objection, or what I think is the objection (there may be others): The PearAuthorizationEdit is designed as a Remote Facade even though it's not currently used remotely. So if it's to be used as a remote interface, there's a performance gain from commiting all the work at once.

That is not actually true. It was a domain object view of what is happening and merely the simplest code I could think of. You make some edits and then commit them. By using data centric gateways in the interface the implementation is creeping into the client code.

Here are alternate storage schemes.
1) The one we are using. This assumes two link tables connecting Principal, Role and Action. It is an obvious response, but only fits exposed RDBMS's. What if all of this is done with stored procedures? Perhaps just the roles and actions? What if you are using views to get the permission set directly rather than with an explicit join. None of this will ever be possible if you expose the structure and yet both are entirely likely if you are mapping from an existing schema.
2) I actually think the naive schema is flat out wrong. The actions are not actually normalised within the problem domain. For example if you rename an action belonging to a role, do you want to rename the action within all the other roles? Probably not. You just got one of the roles wrong the first time around. This is even more likely if the different roles are grouped by application. You certainly want these groups independent. That second link table should go in most cases and this means that the role has to be completely encapsulated at least (to give you the option).
3) Saving to a file is a one shot operation and it is this that caused the storage classes to be introduced.
4) Remote authorisation. This is common in intranets so I wouldn't rule it out too quickly.
5) Placing the system in two DBM files. The serialised roles in one and the Principal/Role mapping in another. This would also be blindingly fast for when there are a lot of edits, but would require a third Principal/Permissions cache. If I were implementing it as a stand alone module, this is the way I would do it.

[*]The remote interface is only theoretical at this point and I haven't seen any compelling arguments that is likely to become real.

No, but making the system SQL only would narrow the scope. I am not against that (although it does make the whole problem rather trivial), is that what you are suggesting? The interface implies it.

[*]The class only does operations that are done relatively rarely, so it's very unlikely to become a performance bottleneck.

Yep. It is the permissions finder that has to be fast.

[*]The implementation as it currently stands would be slightly more efficient with my proposed change, since you don't have to get the objects from the database when you assign. (If they're already available, as they are in the test class.)

Except that performance is not an issue right? The trouble is the implementation tail is wagging the interface donkey. Also it is no more efficient anyway. If everything was in a single hand coded storage class you could take advantage of "replace into" and other syntaxes to improve the queries. Even more so as I feel that addPermission() and dropPermission() are completely redundant. I think it is the Gateways that are wrong. They are more suited to tabular data and reporting. Not to small amounts if intricate and optimised data.

Now I understand your concerns, the design suddenly got very bloated. Is it possible to come up with an alternative that still has a tight interface and maintains some flexibility?

yours, Marcus

[Resolution]

Perhaps we should see this problem from the top down and from the bottom up - view to data and data to view to fully conceptualize the issue we are facing.

Here the problem I see. The API is being defined with no real conversation regarding the interface.

Example: How would one manage permissions is a forum (as proposed above) with 1000 members (extreme really magnifies the problem) and 20 groups from a visual perspective? Are you going to load it all into memory or are you just going to load a representation from the DB/XML data source straight to screen?

Solution: I see a 2 frame view with one side holding a Javascript / DHTML hiearchy view of the entire hiearchy that one can edit be it all groups and users for an AREA (forums) or a select group or a select groups of users. On the other side would be the controls. As such:

1. Add / Delete / Enable / Disable an Permission (enable/disable would be like delete without actually deleting the permission)
2. Add / Delete / Enable / Disable an Area

Explanation:
Imagine a physical tree (look out your window). Starting from the TRUNK (it should have one trunk) which branches off to a few limbs these limbs branch to other ever more limbs which could branch to leaves, flowers and or fruit. ok?

The trunk would function as the BASE area. the badse area would be 'FORUMS' which branch into "USER" and "ADMIN" branches. The ADMIN section would govern the administrative functionality for that AREA - 'FORUMS'. The USER branch would govern the typicle USER who does not need to ADMIN anything.

The PERMISSIONS would be the FRUIT which an ADMIN or USER could reach if they had sufficent GRANTS for thier GROUP or USER (overides).

PERMISSIONS could be GRANTED (enabled) or DENIED (disabled) in regard to each GROUP or USER.

Also from the GROUP and USER side one could deisign the PERMISISON MAP to ALLOW or DISALLOW certain AREAS and PERMISSIONS - Grant or Deny.

This scheama gives maximum access control to USER and GROUPS from the side of the PERMISSION "tree" or the side of the GROUP/ USER "tree". Also one would be able to GRANT OR DENY on an individual basis for specific USERS and or GROUPS.

In addiition, I have figured a way to LINK or condition AREAS and PERMISSIONS so that one could not WRITE if they did not allready READ in the PERMISSIONS "tree".

Make sense?



Conclusion:
So... Working from the the bottom to the top, I have a way to do "ALL" that we have stated thus far plus more (overides and conditions). Also in regard to caching permissions it would be far eaiser, when caching permissions, upon loading a USER's permissions to simply cache the DATA or ARRAY of thier permissions for that AREA until those permissions change. This would allow a penalty for the FIRST load and all addional - even on another day in a different session - to quickly just call the serialized data from cache - DB/XML - (precompiled form the previous visit) in an instant! When the permissions must be changed the caches are auto whiped clean so, by logic, the client would need to recompile the USER's permissions "tree".

Make sense?

I put some serious thought into this. It should work lovely and seriously outclass anything out there to date.

later

PS:Please excuse TYPOS.. The Whisky (Johnnie J. Black) I has a way with my words...

PSS: Oh yea... GROUPS cna be linked as well.. So one could use a BASE GROUP as a start for the next GROUP. Thereby reducing the need to create ALL new permissions for common tasks.

[seratonin]

I want to get back to the basics and try to gain a better understanding of the problem(s) at hand. I think that there are two areas of interest Authentication and Authorization. They are clearly two distinct processes. Authentication addresses the following question: "Is this user (or principal) really who they say they are?" Authorization addresses this question: "Does this authenticated user (or principal) have permission to do this operation on this object (thing)?" So clearly, it would seem that Authentication must occur first, followed by Authorization. Therefore, there is an *order* dependency.

Now here are two possible interactions:

                1. <username, password>
User  -------------------------------------->   Authenticator

                2. <user id>
User  <--------------------------------------   Authenticator

                3. <user id>
User  -------------------------------------->   Authorizer

                4. <permission set>
User  <--------------------------------------   Authorizer

In this version, we have the user sending a username and a password to the Authenticator. The username must be unique. The Authenticator sends a response back to the User containing a unique identifier associated with that user. The unique identifier is different from the username. The user then goes out with this new token and requests a permission set from the Authorizer. The Authorizer uses the unique identifier to look up the permissions associated with that user. In this version of the model, the Authenticator does not interact directly with the Authorizer. Let's call this the "non-interacting" version. Why do we want a separate unique identifier for the user (other than the username)? My rationale is this: I am trying to enforce the *order* dependency I mentioned early. I want the user to obtain an identifier from the Authenticator and I want the Authorizer to only accept an identifier of that form.

Alternately we could have:

        1. <username, password>                      2. <user id>
User --------------------------> Authenticator -------------------------> Authorizer

        4. <permission set>                          3. <permission set>
User <-------------------------- Authenticator <------------------------- Authorizer

In this version, the Authenticator interacts directly with the Authorizer. It is the "interacting" version of the model. What are the tradeoffs between these two versions? What alternatives are there to these two versions?

In our RBAC implementation, if we use "interacting" version of the model, then we have to take into consideration the Authenticator because it sits between the User and the Authorizer. We also need to think about what implications all this has on the data store.

JT