Before we get into things, let me start by saying that this isn’t going to be about authorization or any of the many, many mechanisms for authenticating a user and authorizing that user to access your system. While those mechanisms and specs are fun for the nerdiest of us, sometimes you just don’t want to think about cryptographic handshakes, zero trust authorization, or the cacophony of grant flows.
Sometimes you just want to write your app. And that’s fine — great, actually — because that should lead you to the conclusion that it’s better just to have someone else do that. And many companies provide different levels of services to make this happen for you — but, as I said before, that’s not what this article is about.
Regardless of how you decide to authorize your users, there’s one thing that you will always have to manage yourself: Authority. Users are allowed to use things, otherwise, they wouldn’t be users — and authority management is one of the most important components to your applications and system as a whole.
Defining identity and authority
Let’s start with some definitions. What is identity? It’s simpler than it sounds. Identity is just who your user is — a collection of data points that allows the system to link actions and activities to someone or something external to it. A user does something that needs tracking, and you link those data points to an audit log.
For example, a client wants to get notifications when they can buy that new scooter, and you link your notification service to that bundle of data. The point is that identity can be kind of boring, and letting someone else who does find it interesting take care of that for you is great.
Authority, on the other hand, is what your user is allowed to do in your system. And that’s what you want to spend your time planning and making sure you’ve got right.
Think about it like this: You (the system) are walking down the street in Chicago and a Venetian police officer, (an identified and confirmed user) tells you to show her your ID (a sensitive action). Now, you know she’s a police officer but doesn’t have any authority in Chicago, so you politely tell her no and continue on your way. But when those authority controls aren’t managed properly, how do you know what to do?
Managing identity and authority
The good news is that there are a lot of mechanisms you can use to manage identity and authority that are flexible and can meet all your authority needs. The bad news: There are a lot of mechanisms you can use, and choosing what works best for you can be difficult.
Though there are many ways to manage authority, their implementations usually come down to one of two control styles — fully compiled control lists or just-in-time access decision checks. Both have their pros and cons, and we’d like to help you decide which system works best for you.
Though a backing structure can be complex, a fully compiled control list is something that should be able to be, well, listed. That means all the capabilities, permissions, and entities a user is allowed to use must be retrievable — maybe even in a single call. You should be able to list any domain entities users can access and what level of control they have over any entity.
The pros of this method are that audit tracking is amazingly simple, and an admin can get a detailed view of what a user is capable of doing and accessing. The downside of this is retrieving that list. You can easily have a sort of gatekeeping application that enriches the downstream request with this information, but then you artificially inflate the request and add latency. Conversely, you can teach all the pieces of your system how to retrieve and interpret this, but maintaining that across applications gets harder with every application you add to your system.
Just-in-time access decision checks also require you to teach your application how to access them; however, the interpretation of the response is significantly simplified. It will either be yes or no. Each application is only required to know about the user context, which can include anything from who the user is, where in the world they are, the resource they wish to access, and what they want to do.
The backing control system uses a multitude of rules to determine if the user is allowed to perform the action on the resource, but the interface stays the same. An application must ask the authority manager if a user — or another application — is allowed to perform an action.
The biggest pro for this method is that you can never have stale permission data. The con is that every application must always ask the authority manager every time a user needs to access a resource. This can lead to a lot of intranet activity, which can lead to latency.
On to my point: Even though many development teams leave this piece to later points in the development cycle, authority and authority management are very important parts of how a system works and how the rest of the world interacts with your system.
I understand that while developing, it’s best to focus on what you’re working on and not have to worry about whether or not your test user is allowed to use the piece you’re working on. However, evolving authority configurations can slow development down as well. Still, that doesn’t mean that it’s any less important, and trying to fit authority base access in late stages can lead to mistakes in implementation and access control issues.
Regardless of the style of authority management, it’s always best to think about how you want to manage access as early as you can in the process and offload the responsibilities that you can to third-party systems and libraries. Though it may sound counter-intuitive, your data is usually safer in the hands of third-party security companies — because that’s what they do, and that’s all that they do.
Design your authority scheme early in your development process and offload authentication and identity responsibilities that you can’t afford to get wrong.
This article was written by Michael Gloystein, senior software engineer at SpotX.