Distinguishing Authn and Authz
| DevOps |
Authz and Authn: Understanding the Difference
For many organizations, understanding how to monitor, manage, secure, and audit authorization and access is difficult because the distinction between “authorization” and “authentication” is poorly defined.
There many vendors and systems that purportedly solve “authorization and access management”, but are in reality identity (authentication) management solutions. As companies move an increasing amount of information into highly connected (and often cloud-based) systems, these sytems on their own are no longer sufficient. The modern organization must provide both authentication and authorization management at scale, with an architecture that is cloud native, programmable, distributed, and durable. In order to do so, however, they must first distinguish authn from authz, and then address each appropriately.
Authn primarily deals with user identity: who is this person? Is she who she says she is? There are a large number of systems that handle this “checkpoint” level of identity and access management, and help to reduce the number of credentials that a user needs to provide, often through single sign on (or SSO).
Authz, on the other hand, answers a different set questions: what should this user (or system – authz can manage service-to-service as well as user-to-service permissioning) be allowed to access? For example, an authz platform might determine if a user is a developer, and then grant her permission to push source code to a git repository, but prohibit them from directly changing the software deployed into the production environment.
This is a critical distinction for organizations that have fast-moving infrastructure, such as those that are part of a DevOps initiative, or where there is a push to move away from legacy IT and towards a cloud-first future.
In our experience, there are (at least) five use cases for authorization-as-a-service in the authz sense, none of which are handled by authn alone:
- Implementing role-based access controls (RBAC) for user-to- system and system-to-system permissions management.
- Keeping critical access keys out of code, off of hard drives, and away from repositories like Git.
- Generating audit reports to demonstrate regulatory compliance around access and authorization.
- Managing SSH keys and/or secrets at scale across dynamic systems.
- Gaining visibility into the total set of cloud systems in use and seeing who has access to them.
Is your organization moving fast, embracing DevOps, and/or shifting infrastructure to the public cloud? Conjur has helped organizations like Netflix, RetailMeNot, OpenDNS, and GNS Healtchare implement authorization-as-a-service as part of these kinds of initiatives and can help.