How to give all products access to the authorization proxy automatically?

Not applicable

Hi,

We have a central proxy that handles the authentication for our APIs by providing the endpoint /oauth2 where developers / applications can get access tokens. We use Apigee Products to control access to buckets of data, rather than having a few products, most of our Apigee proxies have one product matching to them.

Right now, we have an apigee proxy & product for oauth2, is it possible to grant all Apigee products in our instance access to the oauth2 proxy? I know I could manually do that, but it seems tedious and error prone. I know I could probably make some API calls as well to perform this task for every single product. Is there a better way? The other option is to have every single developer / app register for a minimum of two Apigee products (oauth2 and whatever api they are trying to access).

Solved Solved
1 5 526
1 ACCEPTED SOLUTION

@jose.cedeno

Great Question, I have experienced same myself while creating multiple API products. If you are using Drupal based Developer Portal & If, It's the only entry point for Developer Apps, I have a suggestion for you.

Agree with you, Option to have every single developer / app register for a minimum of two Apigee products (oauth2 and whatever api they are trying to access) is a great idea considering the way we associated oAuth proxy with products at this point of time.

You can hook into the Developer App save process & always have oAuth product associated with the app. Let user pick the remaining products that he would like to access. It needs little bit of customization which can be done quickly. Having the same as a configurable option (which products are auto associated) in the Developer Portal will be really awesome.

Hope it helps. Keep us posted if any.

View solution in original post

5 REPLIES 5

@jose.cedeno

Great Question, I have experienced same myself while creating multiple API products. If you are using Drupal based Developer Portal & If, It's the only entry point for Developer Apps, I have a suggestion for you.

Agree with you, Option to have every single developer / app register for a minimum of two Apigee products (oauth2 and whatever api they are trying to access) is a great idea considering the way we associated oAuth proxy with products at this point of time.

You can hook into the Developer App save process & always have oAuth product associated with the app. Let user pick the remaining products that he would like to access. It needs little bit of customization which can be done quickly. Having the same as a configurable option (which products are auto associated) in the Developer Portal will be really awesome.

Hope it helps. Keep us posted if any.

@Dino , @sudheendra , Any other better way you can think of ?

Do we really have to put the OAuth proxy inside a product? I understand that it's a recommended approach, but does it apply to token generation proxy as well? If the details of /token endpoint are published on to the portal, applications can access the proxy directly. That way you don't have to give explicit grant to access the OAuth proxy to all Apps. Also there is no need for customization or automation.

When the App calls /token endpoint, App credentials will get validated by the "OAuth2.0" policy before it generates the access-token. Also reports can be created around this OAuth proxy to see which application is invoking, frequency etc. I don't think we miss anything by not including OAuth proxy inside a product. Right?

Thanks @Anil Sagar . We ended up with just manually including the oauth2 proxy in the various products that we have. I know it's not ideal, but I didn't want to put special logic in Drupal with the new non-Drupal developer portal being around. My guess is that the Drupal based developer portal will eventually be phased out and users would be encouraged to migrate to the other developer portal.

@jose.cedeno , I don't think Drupal based developer portal will be phased out. Not as far as i know. It's very powerful & it's going to stay. We can never build all the custom modules out there in Drupal world from scratch. There will be non-drupal portal & drupal based portal.