Preliminary investigation of using oauth2 for hpcc

Oauth2 and OpenID Connect have been rapidly adopted in federated identity management and delegated authentication and authorization. Two typical use cases include, (1) site A uses site B as identity and authorization provider, for example, spotify allows users to login with their facebook account and (2) Site A accesses user's data on site B, for example venmo accesses a user's facebook friend list. In both cases, site A redirects the user to a login and consent page from site B, and upon completion the user gets redirected back to site A, with a ID-Token, authorization code or authorization token.

Azure Identity Management (AIM) has full implementation of oauth2 and openid connect, through which a registered application can get ID token and profile and other info of a user, or get a token to access data and services of Microsoft's built-in applications such as MS Graph, and to access data and services developed by other organizations, including the user's own organization. As a consumer, the app need to specify all the API permissions that it will need in the app registration, so that when a user logs in via AIM, the user will be prompted to consent to all the permissions. As a producer, the app can "Expose an API" in the registration, where a set of scopes are defined as needed (One example of a scope is "mail.read"). The app can specify whether the scope requires admin only consent or admin and user consent.

As it is now, hpccsystems on bare metal currently uses Active Directory for authn and authz, over ldap protocol. Users and groups can be shared over multiple environments if the environments use the same AD server, and each environment can have its own permissions defined under separate "BaseDNs". When running in Azure cloud, things work very similarly, using Azure AD. The users and groups can be managed, i.e. added/deleted/modified through the Azure portal or cloud shell, and the permissions can be managed in eclwatch.

So how can we take advantage of oauth2 and OpenID Connect of azure AIM?

For authN, I guess we can redirect to AIM over oauth2, and expose a call back url to accept IDToken and auth code/token. I don't believe we gain much from doing this, because we're already using azure AD for user authentication, and thus are already taking advantage of AAD's identity management policies etc.

For authZ, the difficulty may lie in mapping the permissions onto AIM. Currently we have very detailed permissions to control the service methods, workunit scopes and file scopes. I haven't found a good way to map the permissions onto AIM. The API scope you define in app registration only enables consenting, and doesn't define permissions. Roles in RBAC are used to control Azure resources, not ad-hoc scopes that are defined by users or applications.

One area that could benefit from oauth2 is inter-component communication within an environment or between environments, where an access token or refresh token can be kept for accessing without user intervention. But without proper permission mapping and checking, generating the token can be problematic.

Another approach is to use a custom oauth2 authorization server. There're open source solutions like ory hydra. Or we can use a combination of (1) open source (2) Azure AIM and (3) in-house developed components. A thorough evaluation of risk, benefit and complexity will be needed.