Giving and receiving authorization and permission

We’ve been exploring the key concepts of identity management as promulgated by the Open Group in a recent white paper (link below). Today our topic is authorization and permission management.

The three As of security are: Authentication, Authorization and Audit. In identity management, we pay a lot of attention to authentication, express a firm believe in audit but sometimes tend to gloss over authorization. But rights and permissions are identity-based attributes and should play a very important role in the identity management universe.

As the paper points out, (and I mentioned in the last issue) resource provisioning is about granting access to resources (files, printers, applications, servers and services, etc.) but “access” is only one of the permissions that can be granted (and revoked). Others may include permission to compare, write, modify, create, destroy, execute, copy, print, forward, delegate, purchase, authorize, approve, sell, sublease, assign, transfer, hire, fire, promote, and so forth. Again, as was mentioned in the last issue, each bit of data – in this case, each permission – might have a different source of authority associated with it. The example given is payroll data – each employee may have the ability to read the data but only the payroll department (or HR) would have permission to change it.

There are two main vehicles for controlling authorizations: Access Control Lists (ACL, usually pronounces “ahkel”) and Policies. An ACL is an attribute of a resource – each identity allowed some form of access to the resource would be represented in the ACL along with an indication of the permissions allowed. Sometimes individual identities will be amalgamated into groups and the group will be represented on the ACL rather than the individual identity. This keeps the ACL smaller and more easily managed but does require tighter management of group membership (there’s always a tradeoff, isn’t there?).

While ACLs are definitely attributes of a resource, policies can apply to resources, individuals, groups or any other object within the identity store (usually a directory, but we won’t introduce that term in this context until the next issue). Policies also allow for multiple “if-like” processing so that any combination of identity, resource, access point or method and literally any other measurable quantity or quality can be combined to determine what permissions a particular identity has to a particular resource at a given time and place. Policies and policy engines (the services that enforce the policy) deserve much more space than I can give them here.

As the paper points out, authorizations can come from different places depending on the identities and resources involved. There are even instances where an “identity” isn’t needed. The paper gives the example of a ticket booth attendant at a movie theatre as an authorization authority; she grants permission to enter the theatre to anyone who pays her $7.50, regardless of identity. Actually, it’s the ticket taker who doesn’t care about identity; he accepts that the ticket seller has authenticated you by the ticket (a physical token) you present. The ticket seller may not care what your name is, but will make judgments (or ask you) about, for example, your age – are you a child, a senior, old enough for the rating on this movie? The answer will govern not only how much you pay but whether or not she grants permission for you to access this resource.

Next time, we’ll examine what the Open Group has to say about the role of directories in the identity management space. If you happen to be near Sydney, New South Wales, Australia next week, and happen to be going to the Identity and Access Management Conference (https://www.marcusevans.com/events/CFEventinfo.asp?EventID=7748), I’ll be speaking about these very same issues and concepts. If you’re there, be sure to say hi.