Authentication and Authorization

Enclave services support PKI based pre-shared keys and OAuth2-JWT based authentication schemes.

note

The below description of how the access control lists are managed is for contextual purposes. If you wish to apply these, please consult the console documentation here.

1. PKI based Authentication

PKI based Authentication scheme is based on asymmetric encryption in which the service maintains a trust store of users and their public keys. The trust store is created based on build arguments and cannot be edited once the service is started since any modification in trust store changes PCR codes of the enclave service. This means that the specification of the users who have access to the enclave directly affects the attestation document via the PCR codes (hashes).

A service creator can provide public keys of all the users and their respective roles such that they can be authenticated to access enclave service. These are entered via the console and are internally stored as access control lists (ACLs):

{
    "AEDFT123123123213DSdaasdfsdcvn678FJGHASFDADSDF656767000000RSA0Public0Key0in0base6400encoded00format": {
        "user-id": "alice",
        "role": "USER,MANAGER"
     }
     
    "AEDFT1543298778hcjxnzcZNqASDa4234sdghoi123123213DSda000000RSA0Public0Key0in0base6400encoded00format": {
        "user-id": "bob",
        "role": "ADMIN"
     }
}

2. OAuth2-JWT based Authentication

Coming Soon...

Authorization

Enclave Services support a simple url-to-role mapping based authorization as part of the access control lists (ACL) where the URL could be a regex based on PCRE and role can be a permission or a set of permissions. A role in an enclave services authorization context is equivalent to permission.

{
    "url" : "role"
}

For example, let us assume we need to add authorization for a simple service that has the following APIs

GET /greet/{name}
PUT/POST /user/{name}
DELETE /users

We can assume the following roles

• USER
• ADMIN
• MANAGER

Then the following mapping can be added as a build argument during the creation of the enclave services to enable url-to-role based authorization

{
    "/greet":"USER",
    "/user/*":"MANAGER",
    "/users":"ADMIN",
}

and these roles are then associated to users

{
    "AEDFT123123123213DSda000000RSA0Public0Key0in0base6400encoded00format......": {
    "user-id": "alice",
    "role": "USER,MANAGER"
     }
}