Authentication Service [ENT 21.1 ARC]

Motivation

Authentication Service is the central component for authentication and authorisation of an Enterprise MAM Solution:

• All frontends authenticate via Authentication Service.

• Backend applications accessing authenticated endpoints of an Enterprise MAM Solution authenticate via Authentication Service.

• Backend applications providing authenticated API endpoints accept and validate tokens via Authentication Service.

OpenID Connect

Authentication Service is based on the OpenID Connect standards. This not only brings with it a high security level, it also easy access to all authenticated APIs as there are ready-made client libraries available for almost any programming language or framework.

User & Group Management

Authentication Service always uses and external identity provider for obtaining users and groups. Only the built-in admin account and functional accounts for backend services are managed directly by Authentication Service. All further accounts, in particular accounts for human users, must be managed via the identity provider.

This allows implementers to benefit from crucial security mechanisms provided by the identity provider and share all relevant configuration (password complexity rules, password expiry rules, account expiry, account blocking, and many more) with an Enterprise MAM Solution.

Authentication Service In Kubernetes

Authentication of Web Frontend Applications

Web-based front-ends of an Enterprise MAM Solution use the OIDC implicit flow to authenticate:

Authentication of Backend Applications

Backend applications use the OIDC client credentials flow to obtain a token for accessing other backend services:

User And Group Syncing

This diagram shows how users & groups are fetched from the configured identity provider and where they are stored:

Authenticating The VidiCore API

JWT token validation is done in VidiCore via the public key of the certificate used by Authentication Service for signing JWT tokens. The public key of the signing certificate is exposed by Authentication Service on the OpenIDConnect discovery endpoint. During startup of the VidiCore Kubernetes pod, an init container is obtaining the signing certificate from the discovery endpoint and stores it as x509Certificate in VidiCore via the OAuth2 configuration API. This init container also configures the expectedAudience and tokenUser attributes appropriately.

When VidiCore is receiving a JWT token, it:

1. verifies the token’s signatures against the public key of the signing certificate;

2. checks if the aud claim in the JWT token (see example below) matches the expectedAudience value configured by the init container;

3. checks if the token has not expired yet by reading the exp value (Unix timestamp) and verifying that is still is in the future;

4. check if the token has a sub claim - it only has to be present, the actual value has no meaning;

5. obtains the VidiCore user name from the claim configured as tokenUser by the init container - tokenUser contains the fixed value vidispine_user in all Enterprise MAM installations.

From that point on VidiCore knows the name of the user doing the API call and treats this user as an authenticated user. VidiCore roles (functional rights) and ACLs (asset access rights) are applied to the API call for this user in the same way as for basic authentication.

Example Token

{
  "nbf": 1612446231,
  "exp": 1612457031,
  "iss": "http://colosseumeuk8s.westeurope.cloudapp.azure.com/vpms3/authservice",
  "aud": [
    "configportalscope",
    "identityscope",
    "http://colosseumeuk8s.westeurope.cloudapp.azure.com/vpms3/authservice/resources"
  ],
  "client_id": "configportalclient",
  "client_role": "CP_API_ADMIN",
  "sub": "8b38b7f2-b956-4165-b284-006caa62dd64",
  "auth_time": 1612446231,
  "idp": "local",
  "ntlm_username": "admin",
  "vidispine_user": "admin",
  "display_name": "admin",
  "email": "",
  "phone_number": "",
  "role": [
    "EM_USER",
    "PF_WfExpert",
    "EM_Test_Super_User",
    "MP_Admin",
    "PF_WfUser",
    "PF_MetadataEditor",
    "CP_VIEWER",
    "PF_WfArvato",
    "PF_MetadataUser",
    "MP_API_CONSUMER",
    "MP_Collection-Full-Access",
    "MP_Collection-Rename",
    "PF_WfEditor",
    "MP_Basic-User",
    "CP_EDITOR",
    "CP_ARVATO",
    "CP_EXPERT"
  ],
  "AspNet.Identity.SecurityStamp": "d82e6d74-fe57-4fe6-85c1-6768ba3eb53b",
  "preferred_username": "admin",
  "name": "admin",
  "sid": "AC7EED8B8E07FA02D4A7EC54BD381A54",
  "iat": 1612446231,
  "scope": [
    "openid",
    "profile",
    "configportalscope",
    "identityscope"
  ],
  "amr": [
    "pwd"
  ]
}

Authenticating VidiFlow APIs

VidiFlow’s APIs follow the same basic principles as described above for VidiCore:

1. Fetch the public key for token signing from the OIDC discovery document once during startup of the service.

2. Validate the received token signature against the public key.

3. Extract expiry time from token and check if it’s still valid.

4. Check for the appropriate OIDC client and scopes.

5. Extract roles from token and check if supplies roles match required roles for this API call.