There’s a big difference between gaining successful entrance to the king’s castle (Authentication) and what you are allowed to do once you are inside (Authorization). Chances are, as a visitor, your actions and movement will be restricted and for good reason. Just because you got through that big iron door does not mean you are allowed to do whatever you please.
This article talks about the differences between authentication and authorization, and how, when used together, they further protect your information security environment.
Exactly What Is Authentication?
Authentication is proving who you are in order to gain access to a system or application (in most cases). It can require something you know (a password), something you are (a fingerprint) or something you have (a one-time-use token).
You were probably already familiar with the process of authentication because most of us perform it almost every day, whether at work (logging onto your PC) or at home (logging into a website). The truth is, in order to access most “things” that face the Internet, you have to prove who you are by supplying credentials. However, once you authenticate, there are many decisions that happen seamlessly in the background, thanks to the secret powers of an administrator.
Once you authenticate, you are then granted authorization or permissions to perform certain allowed tasks. In most cases, an administrator of that system provides permission through use of controls. What do we mean by allowed? An example would be authenticating to your bank website. Successful authentication will not give you the ability to look into other customer accounts or withdraw money that is not your own. Authentication does not give “keys to the castle”, as you are only authorized to access a room in the castle and not the moat.
To summarize, authentication grants you consideration of sorts. If you can’t authenticate successfully you are no longer going to be considered. The conversation between you and the application you want to access will be very short, resulting in denied access and possibly account lockout.
Authorization, however, gives you the actual ability to perform allowed functions once you authenticate. A bank customer representative logged on as a bank employee (and not as a customer) can access many accounts and perform additional functions that you, as a bank customer, cannot and for good reason. Hopefully you now “care” that there is such a thing as authorization and are eager to know more.
How Can Authorization Help with Information Security?
Consider this: Should an employee who is about to quit (and such employees don’t give prior notice on these matters!) be able to print the company’s customer directories on Saturday morning, so they can take a list of prospects with them to their new job along with the secret proprietary formula? This may be an extreme example, but scenarios similar to this can happen, they just don’t always make the news.
Users have access to what has been allowed on an MFD on purpose or by default. Authorization permissions can be very simple, such as authenticated users are authorized to perform any function at any time on the MFD and non-authenticated users can’t do anything except add paper to the trays for all the authenticated users! Authorization can also be extremely granular by defining user roles and assigning very specific permissions to those roles. Remember the permissions authorized for bank customers and those of customer service reps discussed earlier, they are surely not the same.
Get Granular with Authorization
Authorization can be very specific, such as certain users not allowed to scan to e-mail and fax. Other restrictions might not allow printing of certain applications like Excel or PowerPoint. It also can be more granular, such as art department users can only print from 8 am to 5 pm weekdays and Saturday from 9 am to 12 pm. These are only a few examples of the levels of granularity. Using Authentication and Authorization together provides greater information security protection since many functions can be uniquely authorized to users at a granular level.
Authentication and Authorization may not be required today within your organization, but that could change as soon as tomorrow. Recall that the keys to the castle do not have to include access to the moat!