Current Notification Process

1. A scheduled job runs within the organization
2. The scheduled job fetches the token from IDAnywhere
3. The job then uses an admin personal access token to authenticate against the API
4. Update the notification template “Authorization” header with the token via REST API call

Desired Notification Process

Create an integration with native controller credentials into notification templates. 

We would like to have OAuth credential native in Controller. (GSSAPI+Kerberos as well)

Notification endpoints should have some kind of authentication protection, Red Hat should assume that the notification endpoints have an authentication/authorization-protected notification endpoint.

Business Impact

This is needed for more standard space and integrates well with the customer’s ecosystem. It would solidify the value of the product, would require less technical implementation around the box, and would allow them to leverage AAP more natively within their environment. It helps make the product more pervasive as other companies/firms/customers would benefit from this feature as well. 

Security Impact

The customer currently injects their OAuth token in clear text inside of the Notification Template. This could cause issues in the future as these fields aren’t currently hashed/encrypted as they are not stored in native AAP credentials.

Scale Impact

This feature is used heavily due to the scale of their environment. In order to reduce API call load, we are looking to send as much data out of AAP instead of making calls into the platform.