There’s an endemic problem that plagues most of the projects I’ve worked on. A client does the hard work of identifying their users, products, and customers; even going so far as to give code names to aspects. Thinking they’ve got the sales process nailed down, they tell me that when customer Bob buys a vacuum, Sally in Sales will be automatically notified of the transaction. Then I ask, “how do we know it’s Bob placing the order and what will Sally do with the transaction now”? It’s most often a question that doesn’t have an answer and the project comes to a screeching halt.
Let’s begin with the premise that everything in platform architecture is malleable. Anything can be adapted and iteratively improved on as needs change and companies grow. The most critical aspect that creates this invaluable adaptability, often gets overlooked. We must first define Who someone is and What they can do. These answers are fundamental to every aspect of creating technology people want to use. Additionally, it’s of paramount importance to fully define and develop in the earliest stages of creating any new product or service.
Let’s take Bob and Sally from the previous use case and assume for a moment that they both have a very tangible form of identifying information they carry around every day. Let’s say that tangible form of identifying information is a driver’s license. This driver’s license includes useful data like their weight, height, hair color, date of birth, and residence. Sally uses her license to verify her identity at the checkout counter to buy a bottle of wine and Bob gives his license to a police officer to prove that, despite his leadfoot and just going a hair over the speed limit, he can legally drive. Now, what actually makes these licenses credible is that a large, trustworthy entity granted them to Bob and Sally after they were tested and able to prove who they are. While each state may have a different way of granting a license, they harbor the data and the trust to verify someone is who they claim to be.
In the world of platforms and services, the issuer of the “licenses” is what we call our identity provider. Licenses are the systems that a user inputs various credentials into, in order to prove they are in fact, Bob or Sally. These identity providers are of paramount importance in any platform because they are the source of identifying truth that we base everything else on. This is the Who someone is to then define What they can do. While the actual identity provider isn’t necessarily the most important aspect to nail down, what is paramount is that the solution used must be flexible and useful, like a drivers license. Let me introduce you to two important industry standards: OpenId Connect (OIDC) and Security Assertion Markup Language (SAML). Using one (or both) will make sure that your identity is aligned with industry standards and expectations
Access control is simple to understand at a conceptual level, although far more challenging to implement. How to structure access, including explicit and implicit, roles, and such, deserves a full article of its own, which will be the natural next level of discussion in access control. The most important point to remember about access as it relates to any service is that it’s derived from someone’s identity. That someone cannot have access without first having identifying information.
If we go back to Bob and Sally’s license examples, information like date of birth provides no intrinsic access in and of itself. However, when Sally goes to the local bar and shows her license to gain access, the correct date of birth gives her what she needs to get in. This is a simple, but robust access grant rule. Remember, there is no access without identity and all your information about granting access should ultimately be derived and understood from identity.
How you structure your access and access management is a whole other bed of weeds. Always ensure there’s clarity of how you will identify Who and then use that information to answer What.
