Guardian Approval through Slack about guardian HOT 11 CLOSED

@utsav14nov Let's have the endpoint in this way - v1beta1/notifier/<notifier-type>/execute
where <notifier-type> = slack in this case

@rahmatrhd @mabdh @haveiss requesting for your comments.

from guardian.

@bsushmith I am trying to understand, so what the new endpoint responsibility is?
Is it being called when approve or reject button is clicked?

If yes, why not just using some appeal approval api ?

from guardian.

1. how will the user authenticate to access the APIs?
2. if slack can handle the authentication, we might as well treat the slack bot as a frontend client. And as @mabdh suggested, we can use the same approval API

from guardian.

@mabdh @rahmatrhd

1. We can configure only one request url in slack for an app where it post data on every button action in slack. It post data regarding what action is pressed, which user has clicked , from which channel it is requested and other metadata etc.
2. Approve and Reject endpoints need appeal_id and approval_step in url which needs to be build on runtime and slack doesn't supports it.
3. Also only one request url is configured for the one app, we cannot configure post url for each button in slack.
4. Slack Request is authenticated by our application through X-Slack-Request-Timestamp header sent through slack. There is a logic provided by slack to create this secret at backend and compare. This make sure that the request is coming from the authenticated slack app.
5. If above step is authenticated well, user slack id is provided in payload sent from slack which can be used to get email id of the user performed the action.

from guardian.

+1 on using same approval APIs, we should treat these as clients, very similar to CLI.

from guardian.

@utsav14nov can you also please share the link to the slack API that you refer to?

from guardian.

As discussed over the call, we all agreed on only on change in guardian i.e. adding support to notification messages to also send blocks/attachments to format notification better (Point 1 of changes recommended in above issue).
Rest flow will be taken care by separately other services.

cc: @mabdh @rahmatrhd @bsushmith

from guardian.

@utsav14nov Can we update the issue with final approach we are taking. Which also summarises the decisions taken.

from guardian.

@utsav14nov @bsushmith @rahmatrhd slack API on Approve/Reject button/action could capture account_id and action, account_id is an alphanumeric value and not exists in IAM users nor in appeal tables. If we add a flag into the post body of existing approval like source=slack then we can change appeal Api to resolve the email id for a given account_id using slack Api and continue with the rest of the approval flow given email id exists in appeal tables.

from guardian.

@singhvikash11 one of the primary problems with the initial approach or using slack api directly was with respect to authentication.

Currently, guardian service is built in such a way that it expects authentication is already done before it receives the API call(primarily through shield), and it expects a specific header with authenticated user email which slack is unable to send. so instead of mingling the responsibilities here, the following approach can be taken -

• slack is just another client which has buttons configured - approve / reject for example. These buttons will be configured with a endpoint(UI)
• The UI will have an endpoint to take the slack call, and then through authentication for example with google IAP, can call guardian API's with appropriate json body.

The UI is out of scope for guardian changes and it will depend on how it will be implemented by different users. With this approach, it will be extensible for other notifier providers also if needed later.

@rahmatrhd @AkarshSatija @haveiss

from guardian.

@bsushmith @utsav14nov let's update the main thread's description with that approach

from guardian.