The key to any security system is identity. It has to be strong, unspoofable, full of trust. But it also needs to be simple enough to use.

Many systems focus only on end-user identity, ignoring the critical aspect of the workload. Should this application access that database?

User identity is obtained from a federated identity provider (IdP) with a number of upstream providers which can be trusted (nominally Active Directory and Social logins). The federated identity provider provides an OpenID Connect workflow towards the application, and returns an ID Token. It also includes an authorisation service which can be used to exchange the ID Token for an Access Token (which encodes what services the user can access, and in what modes).

The administrator of each organisation is given 3 primary web pages to manage their user base. The first allows selecting identities (e.g. enabling the upstream identity to be used in the system), and optionally assigning the user to one or more groups.

The second allows assigning users into groups (which themselves are identities). The concept of a group allows simplifying permissions (e.g. create an application-admins group, assign permissions to it, and then as new users are on boarded simply assign them to the group if needed).

The third (permissions) allows assigning permissions to groups/users. E.g. here we can select that ‘application-A’ allows group ‘B’ to be ‘owner’, ‘group C’ to be ‘editor’ and individual user ‘alice’ to be ‘viewer’.

This enriched set of user roles/permissions/groups is attached to the identity returned by the upstream IdP. No local password (authentication) is used.

Identity workload.  In the same way we use user-identity to drive the application/role firewall between the user and the application backend, we use workload identity to identify traffic originating from the application backend towards either east-west services, or, towards backend exposed API or databases. This is implemented with an enriched web token (JWT) on a WebSocket connection, upgraded from the original TCP. It implements an identity standard based on X.509 and JWT called SPIFFE. This allows TCP connections to be confirmed from source to destination without having to rely on layer 3 or layer 4 coordinates, simplifying firewall setup. It also renders spoofing impossible.

Share This

Share this post with your friends!