Learn the Magic Words: Authentication & Authorization
“Open Sesame!” “Abracadabra!” In fairy tales, magic words like these are invoked before the treasure chest unlocks and doors open. In the software realm, we don’t call it “magic”, we call it “authentication” and “authorization”. Authentication is needed to protect access to precious data. Authorization tells you what you can do once you are inside.
My mom taught me the magic of access protection in my early childhood. As a kid, I wanted to grow up and shop on my own. So one fine day she let me go to the grocery store and pick up the items on her shopping list. I learned how the process worked:
- She gave me the customer identification card.
- She gave me the list of items she needed.
- She also sent the list to the store and paid for it in advance.
- When I handed over the customer identification card to the billing clerk, he confirmed that I was authenticated to purchase for my mom.
- Her list (sent before I got there) authorized what I could purchase.
Today, in the research world, we come in contact with large groups of people who are providing us various data points about themselves, their families, likes, dislikes, medical information, etc. Every time I look at a data extract, I remind myself that it is very important to take all necessary precautions to protect this data. To ensure it is protected, you need to authenticate identity and authorize users who have access to the data.
The two terms are frequently used interchangeably in conversation, and no doubt they are both tightly associated. Together they are key pieces in protecting data. But the two are really different concepts, often completely divorced from each other. Authentication is the process where by an individual’s identity is confirmed. Authorization is the association of that identity with rights and permissions.
What is Authentication?
A user needs access to data. The software offers a challenge. Identify yourself, say the magic words, and you get in. The software not only needs to know who the user is, it needs to track the changes the user makes to the data.
Once you have an authentication mechanism built, you also want to start thinking of strengthening the mechanism. Some of the things to consider are:
- Password policy – Which administrators are allowed to set strong policies for the password, and what policies (characters, numbers, case sensitivity) should be enforced?
- Expiration Policy – How frequently should the password be changed?
- SSO (Single Sign on) – Should you integrate your systems with a single sign on system, so users do not have to manage passwords for multiple applications?
- Two-factor Authentication – Should you allow users to have another mechanism (SMS, Email) to receive a soft token needed, in addition to their username and password, to authenticate into the system?
Selecting the appropriate authentication policy and mechanism is a vital first step towards securing the privacy of your participants.
What is Authorization?
Once “Abracadabra” opens the door (authentication grants a user access), Authorization lets you control what is available to the user within the framework (like my mother’s shopping list). Authorization is the function that enables security system administrators to specify user (operator) access rights and privileges. Specifically, administrators restrict the scope of activity by:
- Giving access rights to groups or individuals for resources, data, or applications.
- Defining what users can do with these resources.
Authorization is usually implemented through the following elements:
Privileges. Privileges grant access to specific operations. For instance, administrators have the privilege to create or disable other user accounts, while normal users will only be granted the privilege to change their own password and profile information.
Access Roles. A role-based authorization framework should let the administrators govern what level of access an authenticated user may have on the data. This is usually established by feature / data specific rights (read only, can edit, invisible) that are set to users of the system.
Under normal circumstances, an authenticated user is allowed to perform all operations they’re authorized to do. In my case, after showing the store card to the clerk, I could purchase items on the list (and only those items). However, when a user wishes to access a specifically sensitive resource or operation, additional steps must be taken to authorize the request. For instance, when users want to perform a payment, they will be asked to reenter their credentials, or basically repeat the authentication process.
Great Article!