Identity and Access Management

As Hazy's use cases often involves confidential data, robust access control management is required to ensure only the rightful party can access specific resources.

Currently, Hazy supports Role-based access control (RBAC), allowing for fine-grained configuration of different roles for its platform users.

User management and access control is configured via Keycloak, our chosen Identity and Access Management (IAM) server running in conjuction with the hub. Keycloak can be installed in both Hazy Single container and Distributed architecture deployments. Please refer to Hazy's Keycloak installation page for more details on setup.

Identity Management¶

Keycloak provides several identify providers, including:

• User federations from LDAP and Active Directory.
• OIDC
• SAML

These can be configured within Keycloak. Please refer to Keycloak documentaion for details on identify management setup.

Access Management¶

Hazy uses the OAuth2.0 to limit user's access to resources.

In the context of OIDC, there are typically 2 clients at play for a normal UI session. The UI context within the web browser acts as one OAuth client, named hazy-hub-frontend. The backend hub web server acts as the second client, named hazy-hub-backend. The OAuth mechanism is used to enable the user to provide, via login through keycloak (and possibly in turn a downstream idP such as Active Directory) a token to the Hazy frontend (SPA) web application which can be used to ensure actions that take place in the backend are authorised.

Moreover, the use of scopes are used to provide access to specific functionality within the context of Hazy. In short, scopes are privileges to resources that the Hazy platform gains on-behalf-of the user who is currently signed in. Please refer to OAuth2.0 Scopes for more details on the scope mechanism.

The Hub backend will verify incoming tokens to ensure the necessary scopes have been issued before handling the request. The required scopes for an operation in Hazy are not configrable but it is possible to adjust the mapping of roles to enabled scopes on a per user and/or client basis within keycloak.

The default hazy realm in the Hazy-provided keycloak image is pre-configured a set of recommended roles and mappings from those roles to client scopes.

The following scopes and roles are preconfigured upon a Hazy install:

Notes:

• As explained above, roles are made up of a list of scopes (e.g. role hazy:AnalysisJobAuthor contains scopes [hazy:AnalysisJob:Create,hazy:AnalysisJob:Update, hazy:AnalysisJob:Delete]).
• Whenever a user logs in, Keycloak will send two JavaScript Web Tokens (i) identity token - identifying the user and (ii) access token that lists the scopes that are defined under the user's roles. Hazy can then use these scopes on behalf of the user to access resources.
• Scope checking for the access token is done both on the frontend and backend of the hub.
• Hazy system admins can create additional roles, assign these to groups of users/specific users, add any of the scopes listed above through Keycloak, allowing for flexible access control management.
• In addition to these scopes, top level hazy:DataProducer and hazy:DataConsumer roles, based other roles are available on initial install. These provide an example way to segregate viewers/authors of Generator Models:

Notes¶

• The hazy:DataConsumer role has access to the GeneratorModels and can create synthetic data.
• The hazy:DataProducer role has a near full access to the Hazy platform.
• The additional roles hazy:SampleDataViewer (that allows for sampling of real data during configuration) and hazy:MetricsViewer (that allows for viewer the model metrics which includes evaluation between real/synthetic data) are both not part of the top-role hazy:DataProducer and hazy:DataConsumer by default.

For further details on role managment and delegation to Hazy users, please refer to our Keycloak page for more details.