When using any of the APIs in the ITAS collection it is necessary to authenticate using a JWT bearer token. Hivedome Support can generate a long-term token for on-premise integrations although these will effectively be static. Where there is a requirement for self-service token generation, such as off-premise access, identification of specific user account, quick expiration and/or regeneration, it is possible to achieve this through the Identity Server API. The Application consuming the APIs will be able to request a token and take this from the response for use for subsequent calls to other APIs.
where {{host.v2}} is the ITAS Application server with port 4750 (HTTP) or 5750 (HTTPS).
There are generally five parts to the request:
Identifies the way the application gets the token. Each grant type is optimized for a particular use case, whether that’s a web app, a native app, a device without the ability to launch a web browser, or server-to-server applications.
The most common approach is impersonate-subject as this will effectively allow the token to represent an ITAS user for the duration of the subsequent API request for which authentication is required. This approach will be used by Data Portal when a user logins in and can therefore be used for processes that require the identify of a user to be tracked, for example, creating or updating ITAS data. Other grant types available include client_credentials, password & authorization_code.
One or more space-separated strings indicating which permissions the application is requesting. Each API will have their own scope and examples include ODataService.API, ITAS.API and Documents.API
This will be provided by Hivedome during the pilot phase as the name needs to be configured on the client-side.
Similarly this encrypted code will need to be configured client-side and will be unique for each server.
When using impersonate-subject grant type this represents both an Active Directory and ITAS CMP account.