Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Solo (3889)

  (email not shown publicly)

Journal of Solo (3889)

Wednesday August 18, 2004
02:06 PM

Authorization and Permissions

[ #20454 ]

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.

  • Apache's .htaccess files are the permissions for an actor- and object-based authorization where the directory is the object
  • File permissions include actor, object and action
  • ... (add Krang, SPOPS, and Gestinanna ) ...

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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • There are often classes of actors and subsets of data specific to those actors. A user might have read access (and perhaps change request permission for) his own data but no access to the data for anyone else. A salesman can access and change data for his clients' current info but might have no access to historical info or info for clients of other salesmen. The salesman might only be able to approve some forms of customer requested changes, others might require a manager. Different info elements (withi
    • 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).


      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • 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 us

        • 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.


          @JAPH = qw(Hacker Perl Another Just);
          print reverse @JAPH;