Slack integration with Jira ,workboard jira integration and Rev-trac jira via Apigee

[GRaj]

We have 3 Requirements where we want to Integrate Slack  with Jira ,workboard jira integration and Rev-trac jira via Apigee. All are 3 different requirements . But we want to use Apigee as a middle layer for all this Integrations.

whereas Rev trac will have Bidirectional call. When a change request is created in Jira, A rev track request get created and that request get mapped to Jira story. so, then whatever changes happen in rev track request that should reflect in jira and when the deployment completes in Rev-Trac in production the status will get changed in Jira and that user story/ ticket should also get Automatically closed, 

[dchiesa1]

It sounds like it might be an integration problem.

If I were working on a solution here, I would want to start by building a set of Sequence Diagrams that describe the interactions for the various flows. 

You can try this online tool .  The diagrams will help to clarify what messages need to go where, and when they should go there, and what happens when they go there, etc. 

[GRaj]

Thank you @dchiesa1

[GRaj]

Hi @dchiesa1 I didn't get what sequence diagram is and how to design it. I have shared a 5-minute recording of Rev Trac integration with Jira. So, i am not getting whether Apigee supports bidirectional calls or not. 

Rev-Trac Platinum now integrates with Jira - YouTube

[dchiesa1]

A sequence diagram will describe an ordered sequence of events. In the context of a web service or API, the events will be messages that are sent from one part of a  system to another,  the actions these "parts" take when they receive these messages, and the response messages they send.  Here's a good written tutorial .   Here's a good video tutorial.

The diagram will clearly and rigorously describe the precise sequence of events you want. It's a good way to specify your requirements. 

[GRaj]

Hi @dchiesa1 I have implemented following solution. Please let me know your feedback and also pls suggest any alternate solution.

1. Client App will be registered with apigee to get the access token

2. Client App users are also registered users in JIRA(onprem/Data center)9.0.

3. Client App (Example: Workboard) will invoke apigee API proxy with access token and also send JIRA credentials in the header as Base64.

4. Apigee will invoke backend JIRA APIs by using basic auth (Basic auth credentials are obtained from Client App) 5. The response is sent back to workboard app

[dchiesa1]

That will "work", in the sense that all the connections will succeed and data will flow. 

But in my opinion, your approach violates "zero trust".  The design calls for  passing credentials from the client app to Apigee.  Now Apigee is acting as the client app, in the case that the credentials are client credentials.  or maybe Apigee can act as the registered user in Jira, if the credentials are user credentials. This implies that the user is "trusting" Apigee to do the right thing with its credentials. Ie, not zero trust.

In general it is not a good idea to send credentials around in the network like this. Apigee should authenticate to Jira as itself. If Apigee is acting on behalf of a user, then Apigee should act as the client, and should have the appropriate credentials to access data owned by the user.

I don't know Jira, but I think the correct way to do this, is for Apigee to obtain a token from Jira, via a 3-legged Oauth token grant.  This is described here: https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/ 

Basically Apigee acts as the client, and it needs to 

1. direct the user to an Atlassian web endpoint, specific to your instance of Jira I guess, that prompts them to grant access to their data on Jira. 
2. The user, if necessary, signs in to Atlassian. After sign in, the Atlassian webpage displays the access being requested in the Atlassian product. The user grants or denies the requested access to their data on the Atlassian site, via the web form.  I call this the "login-and-consent" experience, and it's common to all OAuth2 3-legged flows, whether Jira, or any other system. 
3. After affirmative consent or denial, the webpage redirects the user back to an endpoint hosted by apigee. If the user granted access, Apigee receives an "authorization code" which it can exchange for a token that grants access to Jira (within the specified scopes)  on the user's behalf. If the user does not grant access, there is no code, and so Apigee cannot get a token. 

This is how I would want to architect a system, if I wanted it to be secure. 

Apigee often acts as a token dispensary in Oauth2 3-legged flows. But this is a little different: Apigee is acting as the client in a 3-legged flow, while Jira is the token dispensary.