Credentials Management

Rustici Generator enforces authentication and authorization as a key component of its API. Credentials should be configured to manage these access controls for the application. As mentioned on the Initial Setup page, your application was setup with root credentials. We strongly recommend setting up credentials with tighter access controls that best fit your use case.

To configure your application credentials, consider the following API endpoints as a starting point:

• Create new credentials: POST /api/v1/credentials
• Get a list of current credentials: GET /api/v1/credentials
• Delete credential: DELETE /api/v1/credentials/{id}

When creating or reconfiguring credentials, the request to the API will require some or all of the following properties:

• id: The identifer property for the set of credentials
• password: The password property for the set of credentials
• is_active: Specifies whether or not the credential is currently authorized to make API requests. This can be helpful to quickly allow/deny access when a one’s need for API access is temporary.
• tenants: Specifies the set of ‘SUBJECT’ and ‘VERB’ pairings that define the credential’s tenant-specific authorization.
• scopes: Specifies the set of ‘SUBJECT’ and ‘VERB’ pairings that define the credential’s global authorization.

Rustici Generator uses a credentials’s id and password to confirm that the request is being made from an authenticated credential. The tenants and scopes properties are used to verify a credential’s authorization to complete the request. These properties use a set of ‘SUBJECT’ and ‘VERB’ pairings to define which resources and in what manner a set of credentials is authorized to interact with the application’s resources. More details about available ‘SUBJECT’ and ‘VERB’ values can be found here. The ‘Authorization Scopes’ page provides more detailed information on how credential authorization is handled in the application.

Me

We have a special subset of endpoints that enable a user to view and update details about their own set of credentials. This allows users some control over details of their own credential, without giving the user access to update other credentials.

• Get own credential details: GET /api/v1/credentials/me
• Update own credential details: PUT /api/v1/credentials/me

Restrictions

When managing your application credentials, there are a small set of retrictions that are enforced through the API:

• Credentials can not change its own is_active status to FALSE.
• Credentials must be inactive before it can be deleted.
• Credentials are unable to grant another set of credentials less-restrictive access than it has for itself.
• Credentials may only grant a subset of its own permissions to other credentials. For example, if a set of credentials only has WRITE access to the CREDENTIALS scope, it can not create or update a set of credentials with READ access to the CONTENT scope.