Authentication vs Authorization component

In a typical ledger application architecture we use an identity management system to authenticate a user (ie. confirm his/her identity). These systems typically return identity (eg. social ID) tokens with some standardized claims in it (eg. issuer, expiry, etc.). Once a user is authenticated we need to find out what his authorization is against a ledger (ie. if he’s an admin, which party he can read / act as, etc.). I understand from this blog post that Auth0 is a service that supports setting up custom access tokens and stores the party-related metadata for a user.

In an enterprise setting (where Auth0 is not an option) do I have to write such authorization component (and an associated database to store authorization details) myself? It seems quite a sensitive piece in the architecture so I’m wondering if there are any off-the-shelf solutions for this. Is there somewhere an overview of which IAM systems support setting up custom access tokens?

In particular I’m looking at using Azure Active Directory against DAML-on-SQL. The AAD access token format is specific and different to what DAML-on-SQL expects. While it allows me to specify custom claims, it doesn’t seem to allow changing the format of the access token itself. So rolling my own component to do this seems like my only option.

2 Likes

Auth0 does a whole bunch of stuff out of the box which is why we use it in our example. A common use-case is the one you describe: You have an IAM system, but need to do user management for the ledger somewhere (connecting users to parties) and your IAM system can’t issue custom tokens.

If your IAM system covers the user management, like AD does, you can probably get away with an ideneity and access proxy (IAP) like ORY Oathkeeper, which allows you to transform the tokens on the fly.

If our IAM system doesn’t store meta-information like DAML parties belonging to users, you need some additional infrastructure that stores that information. An easy example would be storing a file next to the Sandbox which contains the mapping from external identity to DAML claim, and a custom Auth service which validates incoming tokens, looks up the claim from the file, and then returns that.

2 Likes