Saviynt Forums

Swathi · ‎08/10/2023

Short Description

Best practices guide for the recommended guidelines for effectively managing Saviynt API service account (Saviynt user identities) used for generating bearer token for authentication of various Saviynt APIs.

Applicable version

All version

Detail best practice:

Saviynt utilized JWT token for authentication, which is based on RFC6750. This token must be present as Bearer token to call any Saviynt API. This access_token is generated based on service account and access to token is granted based on SAV role linked to the service account.
Follow a standard naming convention across all Saviynt API user identities. This will help in maintaining consistency and clarity throughout the system.
- As an example, adherence to a standardized naming convention such as– [Prefix]_[Unique Identifier]_[Module Component]
Avoid assigning the "ROLE_ADMIN" SAV role to every API user identity by default. Instead, implement a least privilege approach by creating a custom SAV role that has no features accesses and only includes the necessary web service permissions.
- For instance, if the requirement involves managing Access Requests via Saviynt APIs, limit the webservice access permissions to specific APIs such as "/getToken", "/validatetoken", "/getUser", "/getAccount", "/getEndpoint", "/getEntitlement", and "/createRequest". On the other hand, if the goal is to manage user lifecycle through Saviynt APIs, restrict access to relevant user APIs like "/getToken", "/validatetoken", "/getUser", "/createUser", and "/updateUser".
If the password expiration flag is set to true on the API user identity, it is not possible to generate a bearer token for authentication. Since API users do not have access to log into the Saviynt UI, the following steps should be followed.
- Maintain an ADMIN API user to manage the passwords of API users
- Set the password of the API user using the changePassword API [{url}}/ECM/{{path}}/changePassword].
- Update the passwordExpired flag to '0' through the updateUser API [{{url}}/ECM/{{path}}/updateUser].
Assigning owners to take ownership of API user identities facilitates the process of conducting regular access reviews on API user identities along with regular reporting to meet an organization's compliance and audit requirements.
If an API User identity is no longer being used, it is advisable to inactivate the identity and remove the SAV Role for security purposes.
If possible, make use of Refresh token to generate access token so that static service account userid and password is not needed to be stored in application making API calls.
The Access token by default gets expired after 1 hours and a new access token needs to be generated to authenticate API calls. This expiration duration can be changed however it should be kept small for security reasons.
Do not generate a new access token before every API calls, this can impact performance. Generate the access token only when existing access token is expired.
Refresh token by default do not expire, however for enhanced security they can be configured to expire.
The access security with API can be further enhanced by adding the endpoints to which APIs can be invoked. This configuration can be enabled by:
1. Adding endpoint in linked Sav role field "Access to Endpoints"
2. Setting "Restrict API access based on SAV Role" to TRUE in Setting > API
Following could be a good practice while designing API security by making use of Refresh token:
1. Create an API service account:
  1. Which has complex password
  2. Is linked to SAV role which has only access to required webservices
  3. Do not have access to interactively login to Saviynt
  4. Has a owner defined
  5. Follows naming convention based on organization standard
2. Set expiration duration to both access token and refresh token. As best practice access token expiration should be kept small like 1 hour and Refresh token expiration should be based Saviynt API usage for example if you know for sure that Saviynt will be invoked at least 1 in 24 hours then you may want to expiration little more than 24 hours. Note - at any time you don't want refresh token to get expired before a new pair of access_token and refresh token are generated, else the only way to regenerate the token will be by making use of userid/password.
3. In the custom application configure API authentication as follows:
  1. The Saviynt admin should generate the par of access token and refresh token and share it with the application owner. They should not share static userid and password
  2. The custom application should have an option to store both access token and refresh token securely and should reuse access token to call Saviynt APIs instead of generating new access token before every call.
  3. If the access token call return access denied error then that means the access token is expired so need to generate a new access token
  4. Use the stored refresh token to generate a new pair access token and refresh token (refer API documentation for the APIs). Store both newly generated Refresh token and access token securely
  5. Use the new access token to call Saviynt APIs until it get expired and then follow the same steps.

Key Benefit (Quantitative/qualitative):

Improved security - if stringent security is not in place the Saviynt API can case significant risk

Reference documentation:

https://documenter.getpostman.com/view/1797923/2s83mbojGM

rushikeshvartak · ‎09/10/2023

Reference Documentation Link should be changed to https://docs.saviyntcloud.com/category/Dev-Ref