Hats off to You if your phone doesn't have an home screen lock. To those who does, you definitely have your reasons. Every added layer of protective mechanism employed to a system is of importance to privacy or security strength. Here are some dictators of authorization policies i've had to consider while developing software.
To begin with, it'll be of importance to shed words on authentication and authorization.
Authorization & Authentication
Authorization plays a key role in the security of data as it specifies who has and doesn't have privilege to access a resource. Authorization should not be mistaken for Authentication, while authentication identifies the EXISTENCE of an entity within a system, authorization specifies what such entity has ACCESS to and to what extent.
Data is of high importance, despite this fact, Individuals/businesses gets to decide and define access policies to employ based on these dictators. Do also note that there is no hard rule to it, some might as well allow full access without any auth layer.
Authorization Dictators
Although authorization isn't imposed, in my years of building software, below are some factors that dictate to a great extent either or not authorization policies should be set
1) Platform
2) Auth Entity ( User, Device, APIs, e.t.c )
3) Roles
PLATFORM
The platform being built goes a large extent to determine either or not there'll be any authorization in place. A good use case to consider is of a simple personal blog: it becomes clear that while every other users on the internet would have READ access to the content, only the administrator would have WRITE access. Except of course the blog is not so simple.
AUTH ENTITY ( USER, DEVICE, APIs, e.t.c )
authenticatable entity
While Entity is its own jurisdiction entirely in the definition of authorization policies, if a platform doesn't provide a way to recognize (authenticate) an entity, there'll be no basis for which to grant authorization. In this context, an entity is anything that can be authenticated which can either be a User, Device, APIs or every one of them altogether. User as an entity is widely known as we're familiar with it.
In an attempt to consider how Entity helps authorization policies decision, lets take it that the personal blog has been having lots of visitors. While considering monetization, a decision is reached to create premium publications which would be available only to premium users. This would grant premium users READ authorized access to publications flagged as premium, inclusive of all other publications available to the public (non premium publications).
Platform that accounts for auth entity, regards any unauthenticated access to be coming from an anonymous entity.
ROLES
Roles are assigned to whatever it is that can exercise the duties required of it. This builds largely on the Auth Entity. Roles as an authorization dictator specifies the extent to which an auth entity is authorized access to a resource.
To drive this home, lets assume the personal blog has been successfully monetized but in other to stay relevant, there is need to increase the number of publications on the platform. So far it's just the platform administrator (the owner) that has got WRITE and READ access while every other users (anonymous & auth) of the platform only have READ authorize access. A conclusion was reached to open up the platform to writers who has shown interest by requesting a writer role access. Just like the administrator, writers would have WRITE access to create and update their publication and READ access to all of their publications and non-premium publication (except of course they're on premium plan).
Now your turn, what do you consider solid dictators to authorization while developing software ?
Top comments (1)
Some comments have been hidden by the post's author - find out more