Authentication and Authorization on FirecREST¶
FirecREST relies on industry standards for authentication (AuthN) and authorization (AuthZ), providing easy integration third party auth solutions.
Note
You can refer to this document to better understand the difference between AuthN and AuthZ.
Authentication¶
FirecREST enables OpenID Connect (OIDC) and OAuth 2.0 as the standard for authentication layer.
A JSON Web Tokens (JWT) is sent within the Authorization header bearer token with information related to the user that executes a command on the HPC system.
This JWT (also known as "access token") works as a credential to access the API instead of using username/password or SSH credentials.
This means that the HPC center using FirecREST must be supplied with an Identity Provider (IdP) that supports OIDC/OAuth2 Bearer Tokens for proper use of the API.
As IdPs that supports OIDC/OAuth2 we can find Keycloak, ShibbolethIDP5, Auth0, WSO2 Identity Server, among others.
Note
Note that in order to provide HPC user information in the IdP, this must be somehow synchronized with the user database of the HPC center (ie, LDAP). For instance, in ShibbolethIDP5 it is mandatory to provide a functional LDAP server to start the IdP service.
Token validation¶
The public key of the IdP must be set on FirecREST configuration to decode the JWT and check the access token has not expired and has been issued by a trusted IdP. This offline validation of the access token can also be complemented by evaluating specific scopes and roles in the token.
Note
Access token format depends on how the IdP is configured to issue access tokens. FirecREST allows different settings to decrypt and decode the JWT.
Given that FirecREST solely requires a valid access token from a trusted IdP, therefore the client application consuming FirecREST can use any authorization grant defined in the OAuth2 protocol
- Authorization code: used in UI applications (browser, mobile, etc).
- Implicit
- Password credentials, and
- Client credentials
Client credential type is especially important for APIs such as FirecREST, since it enables automated pipelines and workflows on HPC (for instance, a CI/CD pipeline that test a scientific library performs as expected on the HPC system every day at the same time, or automaticaly triggered after a maintainence, etc).
You can see a list of use cases where client credentials grant type is crucial to perform the workflow here.
A note on Client Credentials grant type¶
As mentioned above, client credentials grant type is an important case of authentication method for FirecREST, since it enables machine-to-machine communication, without the need of on-site human intervention with the AuthN process, enabling automated pipelines and cron jobs to run on HPC.
A limitation with client credentials is that it's not designed to be used by "human" clients but for machines (also known as "service accounts" for some IdPs), and thus it doesn't include any information of the user.
This integration between users and clients must be done on the HPC center side. FirecREST expects that the access token's preferred_username or username claims are populated with the user name on the target system (see FirecREST command execution docs)
Authorization¶
Note
The authorization layer is optional on FirecREST. By default no extra authorization more than validating the access token is done.
FirecREST supports fine-grained authorization allowing the community to easily integrate different paradigms within the API.
Typical use cases for having an AuthZ layer for HPC access are listed below:
-
Limit users to access HPC cluster/resources: users can be allowed via LDAP/SSH to use the cluster, however since the API is a different type of access you could limit how the users interface resources with a programmatic layer.
-
Constraint users (or OIDC clients) to access endpoints of the API: a user would like to set its client only for job submissions, another for data transfer, another for both, etc.
-
Quota management: limit the usage of resources (workload schedulers and managers, storage, etc) using FirecREST.
FirecREST ReBAC AuthZ¶
By default, it provides native integration with OpenFGA an open-source tool that uses Relationship Based Access Control (ReBAC) paradigm as authorization solution.
The OpenFGA adapter presented on the FirecREST-v2 package works as a client for the AuthZ service, expecting the latter to allow authentication with the same IdP.
