In my last post I included this quote:

…Amazon Cognito is our identity management solution for customers/developers building B2C or B2B apps for their customers—so a customer-targeted IAM and user directory solution. AWS SSO is focused on SSO for employees accessing AWS and business apps, initially with Microsoft AD as the underlying employee directory. We plan to integrate Cognito User Pools and AWS SSO as part of our roadmap.

In the modern business the buy-versus-build pendulum has swung heavily in favour of buying SaaS providers. Rather than suffer the TCO of maintaining 3rd party software in-house — whether on-premise means private data-centre or own cloud-account — software has become an outsourcing target. Cheaper integration and rising security maintenance costs have pushed firms to minimise the software footprint they are responsible for keeping available and patched.

Cloud adoption is also rife in businesses large and small — the plethora of services powering teams and processes to higher efficiencies and capabilities.

Given a firm is therefore composed of multiple 3rd party services, a unified authentication layer would make sense. However, even AWS appears to have two distinct approaches to the same problem. If a SaaS provider is to be a native cloud provider, why would the authentication and access model be so different?

For example, when accessing an S3 bucket, with AWS key+secret credentials, the user has a first-class AWS identity and associated role.

When storing a file into the bucket from a webapp (a typical model), the user will likely have a JWT token (from Cognito say, to keep things AWS focused). This JWT is used to authenticate the request at the API Gateway layer (to improve security, allow throttling etc), however as the request proceeds, the request becomes a gateway service invocation, not user one. When the lambda (say) receives the request it uses an execution role.

This is feels like an app server of old with powerful cross-tenant service roles and rights, versus a modern fine-grained cloud identity model. There are endless role and policy combination approaches via a multitude of techniques, but it all feels like a simpler model should be feasible.

Cloud providers have endless compliance certifications in place however each SaaS provider built on top only benefits to the limit of the shared responsibility model.

SaaS users (perhaps of a tenant grouping within the SaaS platform) are logically equivalent to cloud account users (IAM users on AWS). However, the identity and audit trails are disconnected.

If the identiy and RBAC / ABAC models were harmonized, the audit and compliance efforts (internal processes notwithstanding) of cloud providers would be able to be leveraged to a greater extent (especially if a cloud-blessed GitOps model was available to provide deployment boundary).

Harmonization of RBAC and audit would be a huge win for customers leveraging cloud-native SaaS applications. Unification of identity between cloud and SaaS platforms running on top feels like a win.

Can we get there?