Patterns Tutorial Series (part 1): RBAC Domain Model

[Resolution]

What alternatives are there to these two versions?

Just about to catch a nap.. good.

I figure we can skip Authentication by using simple interface to the Authorization. In this manner we would not NEED to Authenticate in any specific manner we would only require a connection ID and NAME (Principle) between the user of the Authentication and our Authorization.

Make sense?

Example:

So the Authorization init string would't even need to change much.

<?PHP
$authorizer = &new Authorizer (&new PearAuthorizationStorage(CONNECTION_STRING), &new Authentication(SESSION_ID));
?>

The interface would simply tell the Authenticator to please pass the Principle (ID and Name) in a way the Authorized can reconize. The functions to add the ID and NAME of the Principle are allready in place. Should work.

PS: We could even use a conditional

<?PHP
     if ($authorization = &new Authentication(SESSION_ID)){
            $authorizer = &new Authorizer (&new PearAuthorizationStorage (CONNECTION_STRING), $authorization);
     }
     else {return(new error($authorization));}
?>

Edited again... With return

[seratonin]

Just about to catch a nap.. good.

I figure we can skip Authentication by using simple interface to the Authorization. In this manner we would not NEED to Authenticate in any specific manner we would only require a connection ID and NAME (Principle) between the user of the Authentication and our Authorization.

Make sense?

Example:

So the Authorization init string would't even need to change much.

<?PHP
$authorizer = &new Authorizer (&new PearAuthorizationStorage(CONNECTION_STRING), &new Authentication(SESSION_ID));
?>

The interface would simply tell the Authenticator to please pass the Principle (ID and Name) in a way the Authorized can reconize. The functions to add the ID and NAME of the Principle are allready in place. Should work.

I am kind of thinking that there are instances when you would want to authenticate but not authorize (everyone has the same permissions). That is why I am more in favor of the previously mentioned "non-interacting" version of the model. I understand the desire to use only the Authorizer interface as it keeps things simple. But does the Authorizer really have any business verifying my identity? Do I want to give the Authorizer that much control? Hmm... This seems like such a simple problem to solve until you think of the various scenarios.

JT

[Resolution]

But does the Authorizer really have any business verifying my identity?

Sorry edited my post.. above..

The authorizer should't authenticate ANYTHING. It simply takes what it is given as LAW. The reason I stated as above is that this gives EVERY one a way to create their own Authentication.. Including us.

[Resolution]

Sorry edited my post.. above..

The authorizer should't authenticate ANYTHING. It simply takes what it is given as LAW. The reason I stated as above is that this gives EVERY one a way to create their own Authentication.. Including us.

Also using an interface and a factory we could CHAIN authentications so that ONE or MORE authentications had toreturn true before Authorization would continue. it's just an idea but this way we can do the bast of both worlds - as I see it. feel free to slice and dice at will. lol

[Resolution]

This seems like such a simple problem to solve until you think of the various scenarios.

Last question before nap.

What scenarios do you foresee? Would you give example as well?

Thx

[seratonin]

Also using an interface and a factory we could CHAIN authentications so that ONE or MORE authentications had toreturn true before Authorization would continue. it's just an idea but this way we can do the bast of both worlds - as I see it. feel free to slice and dice at will. lol

I agree. The Authorizer must use whatever it gets to look up the permissions for that User. I guess the client code determines the flow of events more than anything as in your example.

So the general structure of "Authentication" (happens once upon login) would look like this (please excuse my pseudo-code):

authenticate user

if the user is authenticated then
      get the permissions for this user
      store a local copy of the permissions somewhere (e.g. the session)
      redirect/display success
else
      the user is not authenticated
      redirect/display login
end if

And the "Authorization" (on each page or for each request) would look something like this:

if the user is authenticated then
    if the user has permisson to do this operation on this object then
        do operation on object
        redirect/display success
    else
        user does not have permission to do this operation on this object
        redirect/display error
    end if
else
    the user is not authenticated
    redirect/display login
end if

JT

[lastcraft]

Hi...

Principle (ID and Name) in a way the Authorized can reconize.

I don't exactly see what changes this forces on the Authoriser interface as is. It only needs a single ID. Also the separated interface is correct in some sense because authentication will happen less often than authorisation. For example, once authenticated the Principle (Username/UserId) can be stashed in a session.

Maybe I am just losing the plot ? Anyone want to respecify the problem as a test case?

yours, Marcus

[seratonin]

Marcus,

I attempted to take a step back for our second iteration so that I might better understand the fundamental problem we are addressing. Please comment on my post regarding the two versions of interaction between the User, the Authenticator, and the Authorizer as well as my pseudo-code above.

I will try to come up with a test case to drive this next iteration.

Thanks,

JT

[lastcraft]

Hi...

Please comment on my post regarding the two versions of interaction between the User, the Authenticator, and the Authorizer as well as my pseudo-code above.

I don't see them as that different as you can construct an integrated service from the other two in a variety of ways...

class WapSignIn {
    ...
    function getPermissions($name, $pin) {
        $authenticator = &new WapAuthenticator(...);
        $authoriser = &new RbacAuthoriser(...);
        return $authoriser->getPermissions(
                $authenticator->getPrinciple($name, $pin));
    }
} 

...for example. I assume we are still building the authoriser only and are looking at authentication to nail down the authoriser interface.

As for being able to edit owned objects, etc (mentioned again in a recent post), this is application stuff. Having two different permissions does work and is relatively simple - say edit_post, edit_my_post. There may be other ways of doing it based returning more from the PermissionsFinder than a simple bunch of strings. We aren't running into a brick wall at all so this is a non-issue right now. We can return to it later.

Let's get the test case sorted and implement it as simply as possible and then add the necessary patterns on a need basis. We have all been designing ahead a little bit only to run into conflicts later. I say let's try the Ward Cunningham thing of the "simplest thing that could work" and then refactor.

yours, Marcus

[Resolution]

seratonin: The psuedo-code looks good, now there just needs to be a test case for it.

marcus: That's exactly what I was thinking. I don;t know why I put name, sleepy.. ? Anyhow, that's it.


What of the data tables? Has anyone given thought to this?

[Resolution]

class WapSignIn {
...
function getPermissions($name, $pin) {
$authenticator = &new WapAuthenticator(...);
$authoriser = &new RbacAuthoriser(...);
return $authoriser->getPermissions(
$authenticator->getPrinciple($name, $pin));
}
} 

...for example. I assume we are still building the authoriser only and are looking at authentication to nail down the authoriser interface.

hmm.. I'm not sure about passing name/pin TO authenticator while authorizing at the same time..

They seem to need to take place at distinctly seperate times. First Authenticate THEN Authorize, but doing them both just doesn't seem needed.

Signin shouldn't have anything to do with authorization - IMO. "getPermissions" should be in a seperate permissions class which could use a simple interface.

So.. This whole function should be simpler..

 
class WapSignIn {
...
function getPrinciple($name, $pin) {
     $authenticator = &new WapAuthenticator(...);
     return $authenticator->getPrinciple($name, $pin);
}
}
 
class PermissionAccess {
...
function getPermissions ($principle){
     $authoriser = &new RbacAuthoriser(...);
     return $authoriser->getPermissions($principle);
}
} 

[lastcraft]

Hi...

Signin shouldn't have anything to do with authorization - IMO. "getPermissions" should be in a seperate permissions class which could use a simple interface.

Agreed. It was just an example showing that they could be combined by the app.

As for the a DB schema, here is the simplest one I can come up with in pseudo code...

create table assignments (principle char[24], role integer, key (principle, role) unique)
create table roles(id integer sequence, name char[64] unique)
create table permissions(role integer, operation char[24], key(role, operation) unique)

That is roles have many permissions and many assignments so only three tables. More important than the schema is the transactions.

Finding permissions...

begin
select unique operation from assignments, permissions
    where permissions.role = assignments.role
    and principle="Me"
commit

Adding permission...

begin
replace into roles (name = "new_role")
replace into permissions (role = last_insert(), operation = "new_op")
commit

And so on. Assuming that we are talking SQL of course .

yours, Marcus

[dagfinn]

I don't think the code should be driving the test case.

I'm listening to the code as a whole. I believe the way to the best possible API is to refactor from both sides of it--client code and the classes together.

The problem with your new test code is that it is too implementation specific. The client code is getting way more complicated as well.

I don't agree it's way more complicated. It's marginally bigger, but it's also more intuitive, to me at least as an OO programmer. I agree that
simplicity in client code is paramount, but there's a limit to how far I want to take that.

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.

All the objects I'm using in the test code are storage-independent domain objects in principle. (Except for the class names, which are easy to fix.) Notice that my client code doesn't use the association tables as objects.

If I really wanted to design for future requirements, which I don't, I would probably try using Data Mappers instead of gateways and assuming the Mappers could be re-designed to work with another kind of storage.

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?

I believe very strongly in maintaining flexibility only by keeping the design simple so it's easy to change later.

It comes down to whether you want to design for possible future requirements or not. I believe that YouArentGonnaNeedIt.

Theoretically re-usable designs are always mediocre in my experience, and probably terminally so. That's because you get so much complexity you can never see clearly enough to get back to lean and mean. The fog of Speculative Generality never clears. The only way to get to a great re-usable design is to keep it simple, re-use it a few times and add complexity only when required for actual re-use.

If you disagree with me (and XP gurus like Kent Beck) about that, then I respect your view 100%. Then you have to design differently than I would. If you haven't quite decided, then you could try something different from what you're used to. Or not.

This is a whole separate discussion and the key issue is: what are the requirements (in general terms) of a good design. I was considering starting a separate thread on that.

[lastcraft]

Hi...

I don't agree it's way more complicated. It's marginally bigger, but it's also more intuitive, to me at least as an OO programmer.

You have managed to turn a three to five line set-up sequence into nine. That's pretty much double and that complexity will repeat over and over throughout the application. Think how easy that lot is to test. I need three mocks instead of two and I practically have to set up the mocks with all of the application logic. When the tests are more work than the code itself then it is a sign that things are over exposed. You have a fat interface.

I can simplify your design by throwing out all of your little data only classes with one MysqlStorage class that just does everything with php functions and raw SQL. This is actually what I was thinking with the storage factories in the first place (I regret doing a PEAR one). XP/TDD doesn't throw out abstraction, it throws out repetition.

Also the data mappers don't want to fit here (at least not in an easy way that I can see). Can you come up with a data mapper solution? For the SQL case I could not come up with something efficient.

If you disagree with me (and XP gurus like Kent Beck) about that, then I respect your view 100%. Then you have to design differently than I would. If you haven't quite decided, then you could try something different from what you're used to. Or not.

Ouch !

Er...how did you use XP to come up with your design?

yours, Marcus

[Resolution]

create table assignments (principle char[24], role integer, key (principle, role) unique)
create table roles(id integer sequence, name char[64] unique)
create table permissions(role integer, operation char[24], key(role, operation) unique)

Good idea Marcus.. Keep it simple. that occured to me last night too, this PART 1: RBAC so we have time to make a more versitile/complex version on PART 2 and PART 3.

I have a question though. Why does permissions have a unique on role and operation? Shouldn't a role be able to do more than one operation and each role be independent of the other roles in regard to operation? Which mean two different roles can have the same operation?

The only other way around the now is to do chained roles, which mean one principle may have more than one role. This would preserve your inital schema but complicate the select/insert/replace of the permissions. I'l ldo it the simple way first - a single role for each principle.

Also, shouldn't principle be a interger or a serial/hash of the name,id,source of the authorization since there could be more than one principle with more than one name or their ID could be the primary key (most likely)? Logic is clients can change names or naming schemes but the signon order usually stays the same which I expect would be used.

I'll leave principle the way it is for argument sake - the unique in permissions has been removed, for now.

create table assignments (principle char[24], role integer, key (principle, role) unique)
create table roles(id integer sequence, name char[64] unique)
create table permissions(role integer, operation char[24], key(role, operation) )

For the psuedo code, is it being loaded to memory or is it being fetched one operation at a time as requested?

Thx

[Widow Maker]

The only way to get to a great re-usable design is to keep it simple, re-use it a few times and add complexity only when required for actual re-use.

I'm starting to move towards this way of thinking myself. For the most part, just design for the functionality that you presently require, but design if possible, so you can add more later easily

As for Mock Tests/Unit Tests, never used them - do not see the point of using valuable time building tests just to demonstrate your point, whereby just printing the results gives the general idea of bugs and errors anyways

Just my thoughts

[dagfinn]

You have managed to turn a three to five line set-up sequence into nine.

Counting the lines in the code that was actually posted, it's gone from eight to nine.

I can simplify your design by throwing out all of your little data only classes...

OK. They're not my classes, though. They're the ones posted by seratonin three days ago. Calling them my classes rather obscures what I'm trying to do. I'm trying to simplify the design in one way, you apparently are suggesting an alternative way of doing it. I'm open to that. But I think our current discussion--about the virtues of the two different API's--is interesting in itself.

...with one MysqlStorage class that just does everything with php functions and raw SQL. This is actually what I was thinking with the storage factories in the first place (I regret doing a PEAR one).

That would be a kind of Table Data Gateway, then, but it would do all the tables?

XP/TDD doesn't throw out abstraction, it throws out repetition.

XP as I understand it throws out designing for the sake of future requirements. If abstraction is needed for current requirements (such as removing duplication in existing code) it's fine. If not, it's Speculative Generality.

Also the data mappers don't want to fit here (at least not in an easy way that I can see). Can you come up with a data mapper solution? For the SQL case I could not come up with something efficient.

I see a Data Mapper--in its simplest form--as doing the same thing as a Gateway, only the DB-related behavior is in separate classes. So I don't think efficiency would be the issue.

Er...how did you use XP to come up with your design?

I didn't, and I did say I did. What I've suggested is a refactoring (Remove Middle Man, in fact). Refactoring is not synonymous with XP.

[Andrew-J2000]

Some of the classes declared above are a little bewildering to me; it appears as if we are already introducing potential flaws, despite getting to a stage of refactoring. My implementation of this tends to sway from RBACS specification, which is why I have been hesitant to post and write up any code. Ideally, I would love to see a UML (Sequence & Class) diagram, of the current design.

All data should be independent of the format in the Data Access Logic Components. Admittedly this is not in the scope of the tutorial, however in order to demonstrate a functional Object Orientated Design (OOD), I believe this is a fundamental Component, i.e. alternating between XPATH and SQL.

I did mention that we should have a glossary of definitions/acronyms, which would have resolved the matter of ‘Principal’. Even an explanation of the patterns and why they are being used, would be advantageous as you can see where they are applicable and the problem they solve, which will also aid in the refactoring with there necessity.

Generally, when implementing Object Orientated Design (OOD), naming conventions are derived on business entities, as to why we have ‘PearAuthorizationEdit’ is beyond me. Whilst PHP does not implement namespaces, I still find that there is not a necessity to prefix classes with a company or brand name; even common method names such ‘initialize’ are being exchanged for ambiguous names such as ‘setUp’ or ‘can’.

One aspect I touched on briefly was placing the logic into the database using Stored Procedures (SP) or the database itself. IMO, I find that is essentially the best method as it allows for flexibility on the actual returned data and the DB administrator can handle the data to be represented by the principal.

Off Topic:



Scenarios: -

• What if were using this with a web service, do we continually negotiate passing a username and password, or do you pass a token?
• The strange thing I see is that you seem to assume the protocol is automatically HTTP.

If I were to implement the current design in an e-commerce site, where would I be able to implement Auditing, and Transactions (State that Transactions are required in the current model)? I find that matching security to the role of an e-commerce site sets initial standards for your own implementation. Another scenario, what if we have a table of employees and another for consumers, does the current design allow for this? Generally, I have found WAP authentication simply matches the mobile number to a user, so I doubt there is a need for ‘WapSignIn’, I realise this is insecure; however it all depends on the context of its use.

Off Topic:



Marcus (LastCraft), I owe you a little apology as previously, I misinterpreted your code (Late Night Coding ). Glad you like your code being unethical though. J

[seratonin]

I see a Data Mapper--in its simplest form--as doing the same thing as a Gateway, only the DB-related behavior is in separate classes. So I don't think efficiency would be the issue.

A Data Mapper does not do the same thing as a Table/Row Data Gateway. The Data Mapper prevents dependency between the Domain Model and the Data Model by mapping between the two. This allows the two models to evolve independently. The Domain Model needs no knowledge of the Data Mapper.

So you have:

Domain Model <------ Data Mapper -------> Data Model (e.g. database)

Sometimes the Domain Model will have to load a collection (or graph) of dependent objects. In this case, the Domain Model uses a Finder interface to the Data Mapper to gather it's dependent domain objects.

Now, on the other hand, a Table (or Row) gateway creates an in-memory copy of the database either as a row or a set of rows. The in-memory copy of the database is not the same as the Domain Model. In fact they might be completely different... Or, they could be very similar (isomorphic).

If you do not have a domain model, then there is no need for a Data Mapper. We don't really have a domain model (other than the Permissions class which really isn't much of a domain object as it just holds data (no real logic) in the current implementation. The idea of the Domain model is to encapsulate both data AND behavior and in this application it appears to be difficult to do that.

JT

[dagfinn]

A Data Mapper does not do the same thing as a Table/Row Data Gateway. The Data Mapper prevents dependency between the Domain Model and the Data Model by mapping between the two. This allows the two models to evolve independently. The Domain Model needs no knowledge of the Data Mapper.

There's no conflict between that and what I'm saying. What I mean is that the actual actions taken (particularly the SQL code that's generated and executed) by the Mapper and the Gateway are very similar. But since the code is differently structured, you do get different dependencies.

[lastcraft]

Hi...

I'm trying to simplify the design in one way, you apparently are suggesting an alternative way of doing it. I'm open to that. But I think our current discussion--about the virtues of the two different API's--is interesting in itself.

Agreed...something has to go. About the only interesting this you can do with an RBAC authoriser though is play with the storage solution. As a tutorial it's a bit limited otherwise .

That would be a kind of Table Data Gateway, then, but it would do all the tables?

That was the rather vague idea at the time. I am not a fan of Martin Fowler's naming sometimes. Nock calls it a DataAccessor when it just presents domain level persistence methods and does everything databasey behind it's interface.

If abstraction is needed for current requirements (such as removing duplication in existing code) it's fine. If not, it's Speculative Generality.

It is als part of the design process to refine and define the requirements as we go. If we want storage independence then I still think it is the most minimal solution. If we are restricting storage options to SQL structures (except possibly caching) then I don't know what is simplest.

I see a Data Mapper--in its simplest form--as doing the same thing as a Gateway, only the DB-related behavior is in separate classes. So I don't think efficiency would be the issue.

The problem I had with a data mapper in this case is the visibility. The domain object has to be visible to the mapper, but not the other way around. A TableGateway/DataAccessor is aggregated by the domain object. That means that the mapper has to ask the domain object what state it is in so as to be able to save it. Easy for data, but not for complex structure. More efficient if you stack up queries (between requests in Java say), but a bit naff for incremental SQL operations - painful even. Haven't figured this one out yet.

I didn't, and I did say I did. What I've suggested is a refactoring (Remove Middle Man, in fact). Refactoring is not synonymous with XP.

It is one of the core practices and it would be a lot less well known otherwise. Whatever the hype around XP (the original C2 project was cancelled, for example) it has done a lot to cause a major rethink of the way software is written.

Anyway, what storage rquirements are we going to have? How about none. Just code the thing in raw Mysql functions and then refactor.

yours, Marcus

[dagfinn]

Anyway, what storage rquirements are we going to have? How about none. Just code the thing in raw Mysql functions and then refactor.

It would at least give us something real to discuss. What we have now, somewhat simpistically described, is a procedural Facade on top of an object-oriented storage mechanism. What I was suggesting was remove the facade and it would all be object oriented. If I understand you correctly, you want to do practically the opposite: remove the storage mechanism and make everything procedural.

I don't think OO is an end in itself. So it would be interesting to see if the procedural solution would really be significantly simpler--and even more important--more readable. (Or if refactoring it would lead us back to OO.) Readability might still be a matter of taste to some extent, but if we had the implementation, it would be easier to talk about it. Comparing different real solutions to the same problem is a powerful way to learn about design. It takes work, but there's nothing quite like it.

[lastcraft]

Hi...

Ok, I am pretty sure we agree on approach, but disagree on the design to adopt. Let's assume whiteboard discussion mode and argue it out...

What we have now, somewhat simpistically described, is a procedural Facade on top of an object-oriented storage mechanism.

This is not true. What we have (had) is just the objects that made sense to application code - the authoriser, the permissions set and a transactional edit. That's three objects (one stateful). A Facade is a stateless service layer. The only exposed class name was Authoriser (Storage was an interface) giving a Bridge pattern, an aggregate pattern when wrapped in an authoriser subclass. Everything else was implementation detail. I rather liked it .

Having role objects and permission objects and principles (a link table in effect) exposed at the top level is exposing implementation and is a data centric design (not OO). The code you gave in the test case was incorrect if you want to be able to swap storage solutions (like the bridge). Try writing it. You either need a nasty Singleton underneath, my stupid options class or a lot more code. Now add transactions in to the mix. This is a domain concept in just about every domain, so you will have to make them explicit somehow.

Now I wouldn't object to going down the data object route because I think the problems will become evident anyway as we progress (and it's a tutorial right?).

yours, Marcus

[dagfinn]

This is not true. What we have (had) is just the objects that made sense to application code - the authoriser, the permissions set and a transactional edit. That's three objects (one stateful). A Facade is a stateless service layer. The only exposed class name was Authoriser (Storage was an interface) giving a Bridge pattern

I can see how it might be an incomplete Bridge pattern--one with only one implementation. So, maybe you disagree, but I don't want a Bridge pattern unless it's needed. So can you tell me why you need it? In the GoF's terminology, what are the forces that make you choose to have a Bridge pattern?

, an aggregate pattern when wrapped in an authoriser subclass. Everything else was implementation detail. I rather liked it .

Hmmm...I was focusing only on the code in the setUp() method, so maybe I'm just seeing what you call implementation detail. But refactoring is mostly about changing implementation detail anyway, don't you agree?

I was seeing this: the Authorizer class does absolutely nothing except return a PearAuthorizationEdit object. Six out of eight methods in the PearAuthorizationEdit class only provide a slightly different and more procedural syntax for the operations on the domain/data objects. That's why I called the class a procedural facade on top of an object-oriented storage mechanism. I still think that's pretty close, but I know I'm only focusing on a part of the design.

Now I wouldn't object to going down the data object route because I think the problems will become evident anyway as we progress (and it's a tutorial right?).

I think the problems will become evident either way, and I don't have a strong preference. (My strong preference was about another set of alternatives.)

[seratonin]

dagfinn:

I was wondering if you would perhaps propose a new design for us to evaluate.

Thanks,

JT