When talking about Information Security, authorization is the act of determining whether a user, or resource, is allowed to perform a specific action with regards to specific data. In a very simple example giving someone a key authorizes them to open any matching mechanical lock. But a lock is a much less complex mechanism than an Information Security System. A mechanical padlock, or door lock, does not distinguish between one person and another, it simply opens for anyone with a matching key.
Previously, in this series of articles, I outlined the principles of Authentication. When combining Authentication with Authorization we can not only guarantee someones identity, but we can limit their access to specific resources accordingly. A resources access to information is often called their “privilege” or “rights”.
Within Information Security there is a principle called “Least Privilege”. This principle states that a resource should have the lowest level of access to information in order to perform their intended duty. For example a bookkeeper may require access to patient records for billing purposes, but they should be denied access to the pharmacy database, simply because they do not need access to that portion of the database in order to perform their duties. The fewer people that have access to a system, the less likely it will be for an authorized account will become compromised.
Authorization also can be restricted by time. If an intern is hired over the summer, a good Authorization system can schedule a user’s access for that period of time. They can also be used, for instance, to restrict data access for some full time users, to business hours only.
When I was tasked with writing an authorization system, to standardize our security, I came up with a simple general purpose scheme. It involved 3 things, Users, Resources, and Privileges.
A User is just what it sounds like, someone who is being given access to a resource. The resource can be just about anything a User would need access to, I tried to keep it as conceptual as possible. Finally a Privilege is some action that will be performed by a User on a Resource.
An easy way for someone to think about the relationship of these three concepts is to think of the sentence (“User” has “Privilege” Access to “Resource”). Within the Authorization system the administrator creates the necessary objects representing the Users, Privileges, and Resources that fit the desired situation.
If you wanted to grant John Doe, read-only access to a patient record, an administrator would create, or confirm the existence of, the user John Do, then do the same for the Privilege “read-only”, and again for the Resource of “patient record”. Once all three are linked together, a small amount of code within an application can be used to verify that user’s access to the patent’s record.
While the act of Authentication of an Information Security System is sort of like having a Drivers Licence while driving down the highway. An authorization system is kind of like a map, it tells you where you can, and cannot, go.
A good Authorization system is the heart of any good Information Security System. It gives the system flexibility, without one, access to system resources would either be given too freely, or the system would be too rigid and restrictive to remain useful for long.














That is truly interesting. I’ve had difficulties in the past implementing Active RFID authentication badges for single sign on, but hopefully the technology has matured enough that the kinks have been worked out.
Many of the problems with implementation I have ran into involve the interaction of the authentication system and the operating system. Specific vendor supplied Gina’s that were not as “open” to customer add-ons. And difficulties in the process of updating passwords have made it difficult if not impossible to implement on a large scale.
If you wish we can take this discussion to email. I can be reached at spamtron2005@gmail.com. Forgive the nature of the address but, after all, with bots these days I try to keep private email address exposure to a minimum, heh.
I would love to share technologies and ideas with you when you are able. I think we have some similar thoughts and efforts underway.
http://ducknetweb.blogspot.com/2009/02/proxense-rfid-and-encrypted-biometric.html
Matt