Recently, I've been dealing with authorization issues in applications. I'm beginning to wonder whether or not a 'general-purpose' Authz module could be created. This is not a finished idea.
Basically everyone understands Authentication and Authorization are different concerns. But, of those concerns, Authentication receives almost all of the coverage. Compare the number of *authen* to *authz* modules on the CPAN. Authorization modules tend to be part of application distributions as well, and not modules for general-use.
Does the lack of modules represent a lack of interest or need, or an inability to generalize all the bits surrounding authorization?
Since many people don't exactly agree on definitions*, I'll make my ideas clear. Authorization is the run-time process for determining whether an actor may take action on an object under present conditions and allowing or denying the action. Permissions are the data used in the determination. I call the combination of actor, object acted upon, and conditions context.
Based on these definitions, the first half of authorization can be thought of as a boolean function of action, context and permissions.
boolean authorized( action, context, permissions )
This function is the determination part of authorization. Allowing or denying is the other half.
if ( authorized( action, context, permissions ) ) {
allow action
}
else {
deny action
}
That's a pretty general framework for authorization.
Action is somewhat dependent on the system or application, but there are some common actions that almost always require authorization.
Create Making new things Read Looking at things Update Changing existing things Delete Removing or destroying things Execute Using things
Context includes actor, object and conditions. They are pretty self-explanatory, I'll just mention that actor can be anything authenticated (a person or another program or computer) and object doesn't imply OO, but rather, a thing. Condition represents additional factors that might be important to authorization. Date and time are typical 'condition' examples.
Permissions are a persisted set of actions and contexts that are either allowed or disallowed.
Consider some common examples of how authorization is implemented.
Usually action is represented by an enumeration or bitmask values. Could 'action' be an actual coderef? Can authz code be wrapped around any sub in a Hook::WrapSub manner?
For command-line apps, a simple 'you do not have permission' message is ok. For GUI apps, the user expects to only see an option if it can be performed. So, an authz/perms system should be able to list the permitted actions for a context.
Since permissions themselves are 'a thing' or 'things', there might be permissions for permissions. Should this functionality be built in by default?
Permissions should work with groups--groups of actions, groups of actors and groups of objects. Krang's permissions, for instance, only work with groups. But this may be tricky for a generic authz module, which would have to be told what's in groups, where groups are based on data for the rest of the application.
... more rambles to come...
* I asked some folks what the differences were between 'permissions' and 'authorizations.' The responses I got are repeated here, anonymized for everyone's protection.They're basically the same thing.Authorization is allowing access to a resource if the person has permission to do so. Not quite synonymous, since they can't be interchanged without breaking the grammar.
Authorization is "general permission to use the system", while permissions are handed out for every single task there is to perform
If someone has been expressly authorized, they have permission, but having permission doesn't mean they have been expressly authorized
In computers, authorization is something that permissions can allow or deny
Re:can get very complicated and application specif
TeeJay on 2004-08-18T21:51:53
Thats not hugely application specific.You can apply general rules for the general cases and apply subclassing or plugins or triggers or whatever to handle the edge cases.
It boils down to can this person or group do this action on this data (or just do this action).
Re:can get very complicated and application specif
jmm on 2004-08-19T15:59:09
Consider a rule: The manager of the manager of the salesman of a customer is allowed to cancel a transaction as long as it is for less than $1000.To apply that rule means knowing how the corporate/business relationships are mapped, which fields determine a transaction, how to determine the aggregate total value of the components of a transaction,
... The rules would have to be written in something like SQL, with a database description of the data involved before a generic authorization module could be used. Re:can get very complicated and application specif
TeeJay on 2004-08-20T08:34:40
Thats beyond the scope of general authorisation in the general sense and well into the application. Its a business rule which changes from business to business.In this scenario, the ammount may be different for each type of transaction. It would be better for the application to check the authorisation using a standard interface but handling the specifics itself.