OAUTH - Azure IDP - Suitable Product and Apps Combination By Environment

[asharma377]

Hi,

We would be using Azure AD as OAUTH Token Dispenser and for creating apps. The same JWT token would get validated in Apigee

Below is how we intend to handle App creation on Azure and Apigee.

a. Two apps on Azure AD one to represent the API resource (APIGEE API URL), and other client App with permissions to access Resource App( this app will provide the cilent id and secret for clients to get token)

b. A replica of client Azure app would be required on Apigee with matching client id and secret.

This blog post covers this approach -

https://medium.com/levvel-consulting/saml2-vs-jwt-apigee-azure-active-directory-integration-a-jwt-st...

Some other considerations are -

1. We have 5 environments and a single organization at this point

2. We intend to use two Dev Portals ( Test & Prod )

3. Total around 70 APIs (including sub resources)

4. Client id and secrets will have to be sync across Azure and Apigee.

Questions:

1. If we take approach to create Product per environment. This will allow us to isolate Developers access to our APIs. i.e Developers of Test-Product can not access Prod-Product or Dev-Product.

But, this will increase the number of apps we have to handle. So total combination for one API would yield apps below i.e 15 for all environments and 5 products as given below.

API Product	Client App	Resource App (mapped to app Id field )	Apigee-App
sample-pets-dev-v1	sample-pets-dev-app	host- dev.apigee.net/v1/sample-pets	sample-pets-dev-app
sample-pets-test-v1	sample-pets-test-app	host- test.apigee.net/v1/sample-pets	sample-pets-test-app
sample-pets-preprod-v1	sample-pets-preprod-app	host- preprod.apigee.net/v1/sample-pets	sample-pets-preprod-app
sample-pets-sandbox-v1	sample-pets-sandbox-app	host- sandbox.apigee.net/v1/sample-pets	sample-pets-sandbox-app
sample-pets-prod-v1	sample-pets-prod-app	host- prod.apigee.net/v1/sample-pets	sample-pets-prod-app

We are trying to find right way to approach this problem and reduce complexity. Some points that we are contemplating -

1. Same Product and App for environments below Test (in RED Color above can be clubbed together).

AppId in Azure Client app will not be the api host url then

2. On same lines can we club preprod and sandbox together ? (Would not want same keys to be valid for both sand box and preprod though)

3. Total Apps required = No of APIs * Apps By Environment will give us 70 * 15 (1050 Apps). But, this may not be true as Apps should only be required per Proxy (covering sub-resources using scopes etc.)

4. An API Product may well be combination of two proxies as well (say Orders and Cart are bundled together). This may bring additional complexity

5. What would be the impact on analytics if we have same product valid for two or more environments Analytics Information should still be distinguishable by environment and Developers.

6. CI/CD Automation process for this combination with least friction

I didn't find much information on how Apps-Product Combinations have been structured in Apigee Succesful implementations in past and how this has been approached.

Any inputs and direction points are appreciated.

thanks,

Aakash

[robert]

Hi, you covered a lot here and so I will try to respond as best as I can based on general patterns for this type of work.

First, with external IDP's typically you just create the app in the external IDP system and have an automated process to import the external client ID's and secrets into Apigee.

Second, I'm assuming you will also have Azure be your IDP for the authorization code grant type so hopefully you already have the understanding on how to integrate an exernal IDP with Apigee for runtime traffic? With that properly setup, Apigee with "be aware" of the apps and tokens and can then verify the tokens at runtime. This also ensures you have proper analytics around the traffic.

Third, for products and apps and developers, the first focus should be on the developer experience. Do what is best for them and easier for them. Therefore, the recommendation typically is to create one portal where each specs has two hostnames like test.api.company.com AND live.api.company.com (<<-- or something like that).

Once you have the hostnames figured out, you will need to come up with a strategy on products. Most customers tend to create two products for each API product. One is a non-prod product which allows access to the sandbox\test environment and a separate prod product which allows access to prod. As an example, a product name like Accounts-sandbox and Accounts-prod would work. To be sure, you can also have two dev portals and yes that will work. However, always consider the developer experience with that. Again, your questions are around a bigger topic about creating an API program and so it's not a pure technical play, it's more of business related to API's.

Finally, there are many other ways to design products and portals such as if you want to restrict certain API's to external (partner) vs internal developers. Essentially, it's a big topic so it might be worth partnering with an experienced Apigee consulting company to help with this initial design and setup.

I hope this answer helps a little. Good luck with your API program!

[asharma377]

thank you for your inputs Robert. A question -

"Therefore, the recommendation typically is to create one portal where each specs has two hostnames like test.api.company.com AND live.api.company.com (<<-- or something like that)"

AS: Are you referring to OAS 3.0 here that can support multiple hostnames corresponding to different apigee environments. If thats the case then will that not bear risk of API across different environments being accessible with same keys.

[kurtkanaskie]

Currently the Drupal 8 and Integrated portals do not support multiple server URLs.

And yes, I think this has the risk of keys being elivated.

[robert]

Yes, I was referring to OAS V3 type of implementation but for documentation only.

You definitely don't mix the keys between nonprod and prod environments. From the docs perspective, the spec will point and execute at the non-prod environment, but you can also show the alternative hostname for the prod environment in the same spec.

Take a look here and here for a couple examples of what I'm doing my best to describe to you.

Again, these examples are one similar way of doing it and there are other ways to accomplish. It all depends on your business requirements. <--- note that I didn't write "technical requirements."

[kurtkanaskie]

Hello, just a few comments on your approach.

Agree with Robert, sync/import the external IdP App keys into Apigee which will then treat them as it's own keys.

From there on, I recommend you keep separate API products, Apps and keys for each SDLC phase. This ensures isolation and avoids key elevation. It also simplifies CI/CD as you can use a replacer plugin for maven to automatically create those SDLC based API products and apps.

I don't understand the reason for the "Resource App". I think you should just have 5 apps in the end.

Hope that helps a little bit more.

[asharma377]

thanks for yout inputs Kurt Googler,

One question out of curiosity, what if we don't import keys from Azure but use Apigee default keys when we create App. Along with Azure token we can then pass Client Id as well.

This would still help to capture analytics for the app based on Apigee's client id.

[kurtkanaskie]

For analytics to be recorded you'll need to use either the Verify API Key or OAuth policy to be able to see analytics by client Id.

So if you're using Azure tokens, you can configure a Shared Flow to have Apigee "adopt" those tokens as it's own. For example:

• Validate token
• if not valid - validate with Azure
• if not valid - send 401 response
• if valid - create Apigee access token with Azure token as the value or custom attribute.

Next time through the token will be valid.

[robert]

One question out of curiosity, what if we don't import keys from Azure but use Apigee default keys when we create App. Along with Azure token we can then pass Client Id as well.

Unless there are specific requirements for such, the answer should be "no" Akash. That approach doesn't seem to prioritize the developer experience.

Your best options (from what I can glean from this limited discussion format): 1) Use Apigee to create the apps and then auto provision them into Azure. 2) use Azure to create the apps and auto provision them into Apigee.

PS - @Kurt -- that pattern you described sounds familiar 🙂

[asharma377]

Thanks both for your help and inputs.

I don't understand the reason for the "Resource App". I think you should just have 5 apps in the end.

@KurtGoogler,

For Azure AD this is what i could find to expose APIs that we need an app to represent resource and another client app that actually provides the client id, secret

https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad

https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-...

Is there any alternate way where we could use just one app

thanks,

Aakash

[kurtkanaskie]

The Azure AD approach is a bit peculiar, a client App having permission to call a backend App that protects the APIs.

From what I glean, the client App keys would be imported into Apigee and the backend App keys represent some form of service account.