You have in place an existing Identity Provider. It may be based on Microsoft’s Active Directory, Google’s G Suite, LDAP, or other providers. But you may also have some applications that have a unique username & pasword. This is both a risk and an irritation. You may have data that you collaborate with different organisations. You may have loosely affiliated workers, contractors, temps. You may have people signing up for jobs that have not yet started. All of these are symptoms of needing to federate and simplify this identity. Allow users to login the way that is most natural. Enrich that with Authorisation.
New standards have emerged over the years to simplify the problem of ‘who’. OAUTH2, OpenID Connect, SAML They each solve more or less the same problem: are you who you say you are (and a little bit of information about you such as email address). Some are tempted to add more fields (e.g. groups, and then treat groups as authorisation in the applications). This is a mistake: it breaks your ability to use more than one identity provider. By allowing identity providers to do what they are best, asserting identity, we can federate them on this lowest common denominator. This allows using ‘User@company1″ and “User@company2” together, so we can collaborate.
Now, Authorisation. Many will try to build this in to each application. But that in turn creates the problems of:
- Audit: Who has what permission
- Group/Role based authorisation becomes impossible
- Have to rework all applications
- Applications all need to have their code audited
- No single point of audit and reporting and logging
So, we introduce Authorisation as a discipline, distinct from the Identity Provider, and, distinct from the Application. An Identity-Aware Web Application Firewall implements, via the cryptographic strength of Zero Trust Networking, JWT, SPIFFE, a set of assertions, per flow, and, enforces it enroute.
See how to configure your existing Active Directory / Office365 / Azure AD.