Your Users, Your Way
Federated Identity
Overview
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.
Backstory
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.
Authorisation
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
Solution
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.
By decoupling Authentication(Identity) from Authorisation, we can allow multiple parallel, peer identity providers. This in turn allows people to sign in with their own company’s Single Sign On, rather than creating shared accounts, or downwards-federating the identity providers. This allows for e.g. Joint Ventures, Contractors, etc.