Cloudentity provides a robust set of tools to manage Identity and API security, or the complete chain from Authentication with our CIAM platform and Authorization with our API security enforcement gateways, sidecars and other tools.
But even when we think of Authentication as Identity and Authorization as Enforcement, there’s still confusion about where AuthN leaves off and AuthZ begins. Let’s take a quick review.
Authentication is not security in itself – it allows a person or thing to prove they are who they say they are, and then returns details about that entity. Those details might include Personally Identifiable Information (PII), or it might be abstracted with a unique user ID (UUID).
Tools for authentication might be a username and password, a “magic code” in the form of a one-time token in a passwordless flow, biometric data like fingerprints or combinations of identifiers. But all of these mechanisms do not secure your application, they simply corroborate the identity of the entity in question.
Authorization is the actual act of enforcement. We’ve gone through our login and MFA process, and now we have some details that the application can use to grant or deny access to different kinds of data. It might limit access to an individual’s records based on roles or attributes assigned to one’s identity, it might look at scopes and give access to more detailed reports, or not. It’s up to the business logic and the enforcement in Authorization to apply those details to enforce access rules.
You can think of Authentication as the key and Authorization as the lock.
Only here’s the problem – there are lot of applications out there with lots of different locks. Some of them are custom code, some of them are gateways at the edge of the network using access tokens, some of them are server-side tools that enforce rules based on the original SAML response… And each one of those has a set of rules that are applied in different ways by different people with different monitoring and audit tools.
In practice, Authentication is often less of a key and more of a suggestion while Authorization is less of a lock and more of a latchkey – you might be able to open it with a pocketknife, and even if anyone looks at your credentials, they might just glance and wave you through.
Modern application security requires a combination of tools that work together; we can’t look at AuthN and AuthZ as two separate things, and we can no longer support the idea that applications can be trusted to secure themselves.
A Consumer Identity Access Management system allows individuals to identify themselves. It should support multiple factors to make sure the individual is who they say they are, and it should allow administrators, workflows and other authorized tools to provide increasing details about that individual for granular access control.
API and Application Security should be platform independent allowing the same basic set of tools to be used to secure legacy systems, cloud-hybrid, cloud native, and multi-cloud architectures. In other words, no matter where it’s deployed, it’s secured.
But Identity and Authorization need to be tied together with secure policy management. Polices define how that AuthN key fits into that AuthZ lock – that is, policies are aware of all of the data that describes the individual and how that data is applied to security enforcement.
Once you tie your Identity Access Management to your API and Application Authorization you start to have a complete ecosystem – now with everything can be logged because everything is tied together, and if it’s logged it can be visualized.
Policies should be able to be defined and refined as part of the application development process. Libraries of known policies should be able to be created and shared so developers don’t have to reinvent the wheel.
At the end of the day security is something we are all responsible for. The fact we, as an industry, do it so piecemeal, slows us down – trying to explain the security to a compliance officer when your security is wrapped up in code is like speaking Japanese to someone from Finland. We need common language, consistent identity, and clear documentation about how identity is applied to individual services and applications.
It shouldn’t be complicated but unravelling your current security and modernizing it might take a little finessing – feel free to contact us to learn how Cloudentity can help tie together your AuthN Identity and AuthZ security in a seamless way.