Thoughts On User / Page Request Security Model

Just thinking out loud here, but ...

What if you gave each object a key and the user a keychain? You could then do:

SecurityManager.UserHasAccess( UserID, ObjectKey, AccessLevel )

The ObjectKey can be given to any object, whether an Event or a Target or some future kind of object that you don't know about yet. This unties the security from the implementation a bit.

If you have a common object base, then you just add a GetKey method in the ancestor class that creates a UUID at object creation, or gets it from the DB.

I tend to bake AccessLevel into my security managers, so that I can specify if they have Read, Write, or Full control.

I second Rick's comment. I like using a key/keyring method.

It's also nice cause you can deny access if they have a key, not just allow. And they allow for lots of flexibility as the site evolves.

The ObjectKey is a token, a GUID/UUID, nothing more. For things that map to database rows, like Targets, you can use a GUID in your database. For things that don't really map, such as Events, you can hard-code them in your constructor. As long as they are unique, you won't have any problems. (And you can make your SecurityManager class smart enough to cache.)

If you want to be really sneaky, you could bake this into your ancestor class so that anything you build automagically gets it:

<cfcomponent displayName="MyBaseClass">
function init( SecurityManager ) {
this.SecurityManager = arguments.SecurityManager;
this.ObjectKey = '{00000000-0000-0000-0000-000000000001}';
}

function userAccess( UserID ) {
return this.SecurityManager.getUserAccessToObject( UserID, this.ObjectKey );
}

function userCanRead( UserID ) {
return userAccess(arguments.UserID) gte this.SecurityManager.ACCESS_READ;
}

function userCanWrite( UserID ) { ... }
function userCanManage( UserID ) { ... }
</cfcomponent>

<cfcomponent displayName="MyEventClass" extends="MyBaseClass">
function init() {
super.init();
this.ObjectKey = '{00000000-0000-0000-0000-000000000002}';
}
</cfcomponent>

Then, in code:

<cfif thisEvent.userCanRead( request.UserID )>
blah blah blah
<cfif thisEvent.userCanWrite( request.userID )>
Edit this text
</cfif>
<cfif thisEvent.userCanManage( request.userID )>
Delete this text
</cfif>
</cfif>

Targets would work the same way.

You're probably going to want to have a few "filter"-type methods where you can pass in a UserID, AccessLevel, and an array of ObjectKeys, and get back the ones you have access to. It makes doing lists of things faster.

I know that it isn't exactly on topic, but have you ever checked out any python books? This one (http://www.amazon.com/exec/obidos/ISBN=1887902996) is especially good because it doesn't just hit on Python, but more on event-driven programming, target-driven programing, and tiered programming. Since going through it my coding has really improved, as I have started thinking about problems in a whole different light.

I've usually modeled this by using two different objects:

One, the Access Control Service knows how to read the Permissions collection and determine whether a user has a given type of permission based on their permissions. This CFC is composed of a bunch of different functions which return boolean based on whether or not the permissions object passed in is allowed to perform an action.

The other, a Permissions object, just serves as a collection of the various classes of permissions that can be assigned to a user. The interface is generally two functions: addPermission( scope, role ) and hasPermission( scope, role )

Thus, most of my calls look like this:

<cfif accessControlService.canEditContent( request.user.getPermissions() )>
<!--- Some protected Code --->
</cfif>

or

<cfif accessControlService.canEditContent( request.user.getPermissions(), scope )>
<!--- Some protected Code --->
</cfif>

This allows the flexibility to change the logic behind the canEditContent to be very customizable for the various actions, and also allows you to change the way the Permissions object works internally without changing the accessControlService.

Security isn't really the responsibility of the User, nor of the Request, nor of the Target.

Security is a separate area of responsibility.

You may want something like:

myAuthorizationServiceObject.IsAuthorized(user, action, target)

Security isn't "one thing" which can easily managed by a single object. Security is comprised of user rights (which are attributes of a user), and Constraints (which prevent users from reading, writing, or executing some things)

Think of the real world. We don't rely on people to say which houses they have access to. We give the people a collection of Keys, and then we have a set of Locks on the houses. When a Person with the right Key attempts to enter a house with the right Lock, then they are granted access. A user doesn't know for certain whether they have access to a house until they use their key to try it. The locks may have been changed since the last time they were there, so they may be locked out.

@Adam A User object should know the rights/roles/groups/capabilities that it has, because a list of rights/roles/groups/capabilities is a property of each User. But if the User object starts becoming aware of actions and targets, that's far too much information and behavior which is far outside the scope of what a User object actually is. But generic application code which simply needs a yes/no answer to the question, can a given user perform a given action on a given target?, should not deal with rights/roles/groups/capabilities directly - it should ask the AuthorizationService instance whether a given user is allowed to perform a given action on a given target, and then the AuthorizationService goes and does multiple things, including checking the given user's roles.

@Ben The "idealized" super-objects you imagine are the opposite of what object-oriented programming styles encourage! User objects are *not* centralized and smart - they have a specific, delimited, specified responsibility, and they perform that exact responsibility remarkably well, but they don't do anything else. The User object should simply be a representation of what a User is, and the AuthorizationService object should simply be a object that knows whether users are allowed to perform actions on targets or not. Note that AuthorizationService aggregates three very distinct concepts: user, action, target: and none of these concepts is a subsidiary of any of the other two. They should be kept separate and distinct, and only aggregated in another kind of thing whose purpose is to aggregate them and deal with them in combination.

Sorry, this may be a bit off topic, but I just have to know. Why do you like Coldfusion so much? Like... rather than PHP or Python or Ruby? I just don't get it. Maybe it's because I come from a PHP background, but since I got a job doing Coldfusion I've started to hate programming. I used to love programming when I was writing PHP applications. Now I hate it. I hate it because I hate Coldfusion. What makes you like it so much? I just don't get it. Please don't take this as a flame, I don't mean it to be insulting, ya know I feel like to each their own, but I just don't understand what makes Coldfusion good. The syntax alone is enough to make me hate it.

@Luke

Not sure how you can talk about syntax and then say that Python has great syntax. Some people like it, but Python is a very different syntax than most other languages as well (more of a scripting style than a tag-base, but still).

I think that it also depends on what you are programing, how you program it and who you program it with. There have been some CF apps that I have worked on that drove me crazy. There have also been some PHP apps that I could not stand. If you work with some programmers that just get it, the experience is usually a good one.

@Brandon

Python does have great syntax. In fact I like its syntax better than any other language. Hands down. What I hate about Coldfusion's syntax is that it is so verbose that it's unreadable. Python code is just the opposite. Because of the fact that it uses indentation (whitespace) rather than curly braces, all python code looks the same and it is clear, concise and completely easy to read. It's beautiful. Coldfusion has two different syntaxes, neither of which can I get comfortable in.

Once again I don't mean to flame or troll or anything like that, and I apologize for de-railing the discussion. Like I said, to each their own. If you guys like Coldfusion, that's great, but I just can't get used to it. I just don't lke it at all.

Ben, rather than me de-railing the discussion any further, perhaps you can write a post about what makes you like Coldfusion over other langauges? I'm just really curious to know. Thanks :)

Good point Ben. Once again... sorry to de-rail the conversation. My bad. Maybe if I just understood Coldfusion as well as you I'd like it more. I guess I'll just keep at it.

@ben actually, I disagree with your assertion about "Idealized" objects. I wouldn't give a Bill object knowledge of where it had been, because that knowledge has nothing to do with being a Bill. I would instead create a BillTravelLog object which records a Bill and a collection of owners.

@Ben,

In general, it comes back to my statement about "that knowledge has nothing to do with being a Bill". I suppose it depends on your application. In general, your objects should be pretty limited in scope. They should only have the information and methods that pertains to what they are (from the perspective of the system) and what they can do. Thus, a bill might have a method named "changeOwners(Log ownerLog,User newOwner)", but the bill itself doesn't need to know who has owned it in order to be a Bill, so there probably isn't any need to save that information in the Bill. This becomes especially obvious when you consider that there are other objects (such as Coins, Houses, and Cars) which have one or more owners over their life span. You could do some sort of Inherritance to manage that (say, an "Assets" class), but remember the old OO maxim: Favor Composition over Inherritance. In the end, it's better to make each class as pure to it's purpose as possible. Thus, a Bill might have a "OwnershipLog" attribute, if that's important to what a bill is in your system, but the bill itself shouldn't know where it's been. That's knowledge that should be abstracted away from the bill.

@Ben You would probably ask the librarian, who deals with this particular set of concepts (definitions, intricacies, interrelationships) day in and day out.

From my experience, a library book is just another book, which happens to belong to the library. So the library has many books, and it also has many loans of books to customers. The librarian keeps a record of such loans, and incidentally happens to keep a copy of that record in the back flap of the book for the convenience of the borrower.

Unfotunately, Ultra-Objects is the style of object definition which ColdFusion makes easiest, because writing small classes and small functions in ColdFusion is a chore, and because ColdFusion is missing certain language features which would make such classes and functions much easier to write and much more expressive.

It is not that easy to learn good practices of object-oriented programming in ColdFusion: you must branch out to languages like Smalltalk, Ruby, Python, Java, or C# to begin to understand how to construct enterprise-scale systems using minuscule objects which do only one thing but which do that thing well, and which accurately capture the real-world concept they are intended to model. Once you learn the techniques well in another, more object-oriented, language, you can begin to apply them much more powerfully in ColdFusion.

@Ben,

For other OO languages, I would suggest starting to do some Flex. ActionScript is a very powerful OO language, fully typed and everything like Java, and without the object instantiation penalty of CF. Besides, things you build in Flex can act as front-ends to your CF apps very easily.

Well something I do is have a field in the database called permissions and authors where you can store the set permissions

for an example

permissions = author, all, admin etc...

I would also create the author(s) in a CF list then just loop through it to see if the user has permission to modify the entry or not. I know it might not be the best solutions but it works wonders.

I have been trying to play around with some other languages in OO, but it's a slow process for me; and, one that I wish I could devote more time to :)

If your not sanguine to redesigning the entire site... Consider using a servlet to create and serve up web page content dynamically on request. The request would contain the required access levels parameters needed and the servlet component would control which factory to call into play. When a request comes in for a new object, needed permissions and roles are sorted out. Users are denied or allowed access to the resource which would be freshly baked for the user. Objects are created using the factory pattern and the need for page level security is minimized as resources are created when requested..??