If there is one aspect about building software that seems to cause the most headaches for everyone involved, from programmers to project owners, it's the question of access. Unlike anything else in software, this has to be is the most intangible and nebulous concept to deal with. Access has this unique way of needing exceptions, exemptions, and explanations that can make even the most hardened and senior software architects weep. Access, in short, is the question of who gets to do what when (and sometimes why). Access comes with caveats and considerations that require thought in implementation and in management, and has catastrophic ramifications if it’s implemented incorrectly. In short, Access is probably the aspect of software that is thought about the least and is actually the most important.
When building In any system, there are always critical few keystone decisions that need to be made and ramifications that should be fully understood before proceeding anything else can happen. Regarding For access, the most important decisions ones are:
In dealing with Access and Access Policies, the very first thing that needs to be addressed is whether your system will be permissive or dismissive. Whether your system will default to no access unless permitted, or all access unless otherwise noted. Systems that are inherently more sensitive by nature, or more ripe for abuse should focus on being permissive; however, systems that are more public facing, that encourage engagement, or less sensitive in their nature might benefit from a more dismissive approach as the restrictions around permissive systems might hinder platform grown or adoption. Think of it like this, you could either have a gated road with narrow access (permissive) and be very restrictive in who goes where and why, or an open highway with a couple cops enforcing some basic rules (dismissive). The most important thing, however, is to pick an access philosophy and stick with it.
Implicit versus explicit grants could best be described as the most pedantic aspect in software development; akin to a child justifying stuffing their face with a cookie because “mom didn’t say I couldnt have a cookie” (implicit). While I might see benefits in aspects of permissive versus dismissive access control, there is nothing redeeming about Implicit grants when it comes to access. Unfortunately, software ends up being rife with them. Explicit grants are exactly what they sound like, access is granted because there is an explicit process (or algorithm or policy) that grants without ambiguity. Implicit grants tend to happen when access is an afterthought into a system, and once they happen they develop this crippling dependency on them.
There is likely certainly more nomenclature around access that you are probably aware of. I’ve deliberately avoided mentioning terms like Roles, Permissions, ect. because they are less important from a software perspective than they are conceptually. What is important when implementing an Access management system is that it is flexible, and the way to develop flexibility is through verbosity. Simply put, the more fine grain data you are able to store and utilize as the driver for your access management system, the more you can deal with the sometimes bewildering access policies that need to be accommodated for.
However, when building flexible systems, a keen focus needs to be care needs to be taken around the ease of administration and auditing. The hardest part isn’t necessarily building a flexible system, but in developing a user experience where administration is clear. for clear administration of said system.
