REST Collector Authentication
In recent blog posts, we've explored numerous integrations between RSA G&L and various SaaS applications, primarily relying on the Generic REST collectors. Despite their flexibility, navigating through the intricate components of these collectors can be overwhelming. This article aims to simplify the process by focusing on the authentication aspect, providing an overview of the supported authentication methods and offering common examples to clarify the integration process.
As of v8.0, RSA G&L generic REST collector supports Basic
, Token
and OAuth2
authentication methods. Rest of the article will cover the details of each configuration with examples.
Basicโ
This authentication type is an implementation of the HTTP Basic Authentication Scheme. This authentication type requires that the user name and password values are provided in the collector configuration and during the API invocation transmits the Base64 encoded pair of user name and password.
The G&L collector framework will ensure the Authorization
headers are set on the request and no additional configuration are required in the API page.
1 | User Authentication Type | Basic |
2 | Username | The service account user name |
3 | Password | The password corresponding to the user name |
The API configuration page will look something like this without needing any explicit Authorization
headers.
Examples
๐ References
Tokenโ
This authentication type is an implementation of the HTTP Bearer Authentication Scheme. This authentication type requires that a valid token value is provided in the collector configuration. The generic REST collector support both static as well as dynamic token types.
Once the connection details for the token has been configured, the subsequently all API calls must include the Authorization
HTTP header with value Bearer ${AuthenticationToken}
.
๐ References
Static Tokenโ
1 | User Authentication Type | Token |
2 | Get Token from URL | Unchecked |
3 | Authentication Token | Static token value |
Examplesโ
Dynamic Tokenโ
The configuration for getting a dynamic token can vary from endpoint to endpoint. Generally the token URL accepts requests over POST with additional authentication requirements passed through the POST body. The collector does support dynamic token calls over GET if needed.
Examplesโ
OAuth2โ
This authentication type supports the OAuth 2 authorization flow.
1 | User Authentication Type | OAuth2 |
2 | Client ID | The client_id for the OAuth application created on the target for the integration |
3 | Client Secret | The client_secret corresponding to the client_id |
4 | Authentication URL | Authentication URL to retrieve an authorization code and an optional refresh_token from target application |
5 | Access Token URL | Access token URL to acquire an access token using the authorization code from the target application |
6 | Scope | scope for the access_token being requested |
7 | Access Token Expiry | access_token expiration period in milliseconds. This value will be updated if the expires_in parameter is available in token responses. If refresh_token was provided in the access token response, G&L will make a access token request when the current token expires. |
8 | Token Validity | Displays when the current access_token will expire |
Once the above configurations are set, click on Get OAuth 2.0 Access Token to send the authorization request. Depending on the target application, you may have to go through the authentication process and once completed will return the code
, refresh_token
, access_token
to https://instance.securid.com/aveksa/oauth/callback
Examplesโ
๐ References
JWTโ
With G&L version 8.0 P02, REST collectors now support JSON Web Token (JWT) authentication, providing a stateless and secure method for transmitting authentication information. The JWT authentication type requires the API keys from the target provider to sign the web token.
1 | User Authentication Type | JWT |
2 | Client Api Key | Path to the file containing the API key that will be used sign the web token |
Examplesโ
- TBD
๐ References
- TBD