IAM
Identity-Management
Identity management (abbreviated as IM) solutions (such as Okta, and Azure Active-Directory) are used by organizations to keep track of the various identities they have, the organizational relationships between them (such as which department an employee belongs to), and systems the work with.
IM solutions provide protocols such as LDAP to query this information, and provide standards such as SAML, SSO and OpenId to authenticate against their directory.
IM solutions allow assigning roles, these are organizational roles, and shouldn't be confused with application roles (e.g. if an employee is an administrator in the IT department that doesn't mean he should be the administrator in the marketing solution the organization uses).
In general IM solutions often represent the customer side and its preferences.
Developers building applications with IAM should keep in mind the difference between the IM of their organization and that of their customers.
Authentication
Authentication (abbreviated as AuthN) solutions (such as Auth0, OneLogin, AWS Cognito, and KeyCloak) provide gateways into applications (mainly as log-in screens).
These solutions (as their name indicates) authenticate the incoming user's identity through a source of truth (such as its organization's IM solution), and allow/deny users from entering applications (this is the basic/limited authorization within authentication).
Modern authentication solutions gather the relevant information about the user into a passport like document called a JWT (Json-Web-Token). The JWT contains claims about the user (e.g. which department they belong to).
The Identity and claims are then signed cryptographically, allowing later recipients of the JWT (mainly the authorization layer and the application itself) to be able to make trustworthy decisions based on the user's identity without having to re-authenticate or re-query the IM solution. In web-based / cloud-native applications the JWT is propagated through the user's session (most commonly via HTTP headers).
Authorization
Authorization (abbreviated as AuthZ) controls access within a product. While IM and AuthN solutions work at the perimeter of a product (e.g. application, service, ...) AuthZ is responsible for all the complex patterns of access within the product itself. This is where you'd most often run into roles, permissions, ownership, application users, invites, approval flows, and many more common patterns.AuthZ architectures (especially microservices ones) are most commonly broken down into two main components policy-decision-point (PDP) and policy-enforcement-point (PEP).
PDPs are used to create a unified plain with the same rules and same world-picture to answer authorization queries with the right decisions (mostly allow/deny or data filtering) across the applications.
PEPs are used as gateways before accessing content, data, services or features. These are often implemented as flow-control in code (i.e. if), or as part of reverse-proxies (e.g. Envoy) or API-gateways.
A key part of authorization is policy - i.e. the set of rules governing access within the solution. Common models for policy you probably have heard of are RBAC and ABAC.
RBAC - or Role Based Access Control - assigns roles to users, and permissions to roles, and uses those to decide who can do what. E.g. Simon is an Editor, Editors can change files, hence Simon can change the file.
ABAC - or Attribute Based Access Control - uses the attributes of both the solution and the user to make decisions. E.g. David works in New York (has the attribute of location=='new york'), only people outside of the US can use the GDPR interface, hence david can't use the feature.
There are many more models, and in general models such as RBAC are only tools to help think about the problem - developers shouldn't expect a specific basic model to cover all their needs (especially not in the future).
The IAM Waterfall
Let's put it all together - Identity Access Management works like a waterfall, starting at the customer's Identity-Management cascading down to authentication via SSO and finally via JWT to authorization and the application itself.
Authorization vs. Authenticationā
As the names can be confusing here's an easy way to think about AuthZ vs AuthN:AuthN identifies who's at the door and whether they may enter, while AuthZ deals with deciding where can they go and what they can do when they are inside the house.
Different levels of authorization
ā It's important to remember authorization is needed across the multiple layers:
- Physical authorization (e.g. locks on doors)
- Network level authorization (e.g. Firewalls and Zero-trust networks )
- Infrastructure level authorization (e.g. which service can talk to which service in our cloud)
- Application level authorization (e.g. which users can interact with which users using which features) Each layer is a whole world onto itself and often will require different tools and solutions.
Fullstack authorization
ā It's important to remember authorization is not just the decision points and the enforcement points- but a whole stack of components. Including the back-office and interfaces the different stakeholders within(e.g. developers, security, product) and without(customers, partners, auditors) the organization need. Building authorization often requires building many interfaces on top, such as :
- User management
- Policy editors
- Role and permission assignment
- Invites
- Impersonation
- Audit logs
- ...
Authorization is hard
While authorization is commonly found in bottle-neck points of software (such as points of accessing databases, APIs, 3rd-party services, and triggering actions or change in a system), naturally as applications become more advanced they require more AuthZ checks.
Distributed applications and microservices in particular create more AuthZ points by design in the intersection between all the microservice, and so authorization challenges often grow exponentially as the software grows. Everyone often starts with a simple pattern for authorization (e.g. just two roles admin and user), and it's easy to overlook the complexity that will be added later. Combine that with increasingly complex models, expanding data plane, scale, cryptography, and ever coming new customer and security/compliance demands and you have a perfect recipe for constantly going back to the drawing board. We found that most companies end-up refactoring or completely rebuilding their authorization solutions every few months.
The best way to avoid constantly rebuilding authorization is to build on best practices, open-source, and of course complete services. Developers should avoid the temptation of building authorization on their own from scratch. Especially nowadays when there are so many great open-source options such as OPA, OPAL, ORY, and OSO.
Where to start
A good place to start is by reviewing what's available as open-source, even if just to learn the concepts.
You're welcome to join our community on Slack to dive deeper and ask questions about authorization and IAM in general.
Written by
Or Weis
Co-Founder / CEO at Permit.io
