API HTTP methods granularity within Products

banto_78
Participant III

Hi,

i know that a Product contains API proxies. But what is not clear to me is the granularity level for the API HTTP methods. We all know that in REST an API URI can be executed through multiple HTTP methods. But i believe that in Apigee there is no way to distinguish them within a Product when an API proxy is added within it. I mean, there you are adding that proxy and ALL HTTP methods too. If this is the case i see limitation with regard to security implementations (OAuth) and REST...

Any hitns?

thanks lot.

Solved Solved
2 13 2,649
1 ACCEPTED SOLUTION

@bantobanto ,

Myself came across similar Query a few days back when I was working on API Product,

Yes, You are right, In Apigee API Product you can define scopes at product level like READ, WRITE, UPDATE, DELETE, SCOPEX, SCOPEY which will be applicable to all resources defined in API Product. While creating API Product you can only add resources but not exactly resource + methods combination. I think it's as per design. Find out why below.

I believe there is a solution to your Issue,

Confusion starts when you start thinking scopes are restricted to READ, WRITE, UPDATE, DELETE. Scopes are just strings. You can also have a scope like SCOPEX, SCOPEY etc. Just by defining scopes in API Product doesn't enforce any restriction. You need to enforce scopes on API Proxy - Method (Conditional Flow) level using VerifyOAuthToken policy. For more details, refer Working with OAuth2 scopes here.

By just defining scope in API Product you don't enforce anything on API Resource, You actually need to enforce scopes on API Proxy - Method level ( Conditional flows ) using Verify OAuth Token policy which support scope condition.

To make it clear,

Let's take an example:

API Proxy: PetStore

/pet (Proxy Resource) - GET, POST, PUT, DELETE operations as different conditional flows.

/petOwner (Proxy Resource) - GET, POST, PUT,DELETE operations as different conditional flows.

Let' say,

  • I would like to give GET access to all resources to an APP - A , I will define API Product- petStoreRead & I will add both resources /pet & /petOwner to API Product & mention SCOPE as "READ"
  • I would like to give READ, WRITE access to all resources to an APP - B, I will define API Product - petStoreReadWrite & I will add both resources /pet & /petOwner to API Product & mention SCOPE as "READ, WRITE"
  • I would like to give READ access to /pet resource , WRITE access to /petOwner resource to APP - C, I will define a product like petStoreCustom1 & I will add both resources /pet & /petOwner to API Product & mention SCOPE as "SCOPECUSTOM1"

By doing above, Actually, you didn't enforce any restriction on API Proxy / Resources / Resource Methods yet. Let's come to Scope Enforcement now,

You will enforce scopes using OAuth policy using operation "verify access token" by mentioning scopes allowed, which you will attach to flows / conditional flows. Now let's see how enforcement is done.

  • You will Attach verifyAccessToken Policy like below to Conditional Flow - GET - /pet
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>READ SCOPECUSTOM1</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>
  • You will Attach verifyAccessToken Policy like below to Conditional Flow - POST - /pet
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>WRITE</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>
  • You will Attach verifyAccessToken Policy like below to Conditional Flow - GET - /petOwner
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>READ</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>
  • You will Attach verifyAccessToken Policy like below to Conditional Flow - POST - /petOwner
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>WRITE SCOPECUSTOM1</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>

You don't need a policy for each resource - method, you can create conditional flows based on your need & use some common policy.

Hope it helps 🙂

View solution in original post

13 REPLIES 13

Not applicable

Hello @bantobanto,

We can allow the API Proxies to be consumed only by specific methods, by keeping the method name in the condition of the conditional flow.

In this way, we make sure that a particular resource path is consumed only by certain verbs.

Additionally, we can associate the scopes with the product and can make sure that the requesting consumer can only consume the API if the scope is matching with the access token.

Does it make sense ?

Hi @MEGHDEEP BASU thanks for the reply.

But if i understand, you are saying that is not possible to give a scope to an API Proxy verbs separately. As i said, API Proxy scope comprise ALL methods on that API. What you mentioned about keeping the method name in the condition of the conditional flow for me happens later and not in the definition of the API Porxy scopes.

Correct?

Hello @bantobanto,

What I said is as follows:

1. You specify scope A in the product A which has Proxy A.

2. You get an access token with scope A.

3. In the flow, you check if the method GET, only then enter the flow.

4. In the flow, you check the access token scope and the scope associated with the product via the developer app, which is consuming the API.

Hi @MEGHDEEP BASU i understood that.

But still does not answer. Let's make an example:

API Proxy:

/petstore

with a Product to which I give a scope.

Now /petstore has operations:

"/pet/*" and "GET" (read)

"/pet/*" and "POST" (write)

There is no way for me to say App_A with read access can only call /pet/*" and "GET"

There is no way for me to say App_B with read, write access can call both

because the API Proxy "/petstore" has one only scope.

Unless i create 2 API Proxies "/petstore" like "/petstore_post" and /petstore_get" within 2 distinct products. Against REST!

Right?

Not really. We can still do it in this way:

1. Create Proxy A with 2 resource paths "Read" and "Write".

2. Create Product "Read" with the proxy A and Resource path as "Read" and assign Scope "Read"

2. Create Product "All" with the proxy and Resource path as "Read Write" and assign Scope "Read Write".

3. Assign App A to Product "Read" and B to "All".

4. In the generate access token oauth V2, make sure that the <Scope> tag contains the scope that comes in the request. With this App A would only be able to generate Token with scope "Read".

5. In the preflow of the Proxy A, do verify access token.

6. The condition of the condtional flow should contain the accesstoken.scope and verb. So, when the request comes from App A in GET call, only then the "READ" would be executed.

Does it make sense ?

I would love to create a demo proxy for you once I get some time.

so you are suggesting to use "read" and "Write" as resource path (i.e. in the URL)? Again as i said this is not REST!

I said the Conditional flow (API Resource) name to be READ and WRITE, not the URI. Its up to you to suggest a suitable name for the same.

@bantobanto ,

Myself came across similar Query a few days back when I was working on API Product,

Yes, You are right, In Apigee API Product you can define scopes at product level like READ, WRITE, UPDATE, DELETE, SCOPEX, SCOPEY which will be applicable to all resources defined in API Product. While creating API Product you can only add resources but not exactly resource + methods combination. I think it's as per design. Find out why below.

I believe there is a solution to your Issue,

Confusion starts when you start thinking scopes are restricted to READ, WRITE, UPDATE, DELETE. Scopes are just strings. You can also have a scope like SCOPEX, SCOPEY etc. Just by defining scopes in API Product doesn't enforce any restriction. You need to enforce scopes on API Proxy - Method (Conditional Flow) level using VerifyOAuthToken policy. For more details, refer Working with OAuth2 scopes here.

By just defining scope in API Product you don't enforce anything on API Resource, You actually need to enforce scopes on API Proxy - Method level ( Conditional flows ) using Verify OAuth Token policy which support scope condition.

To make it clear,

Let's take an example:

API Proxy: PetStore

/pet (Proxy Resource) - GET, POST, PUT, DELETE operations as different conditional flows.

/petOwner (Proxy Resource) - GET, POST, PUT,DELETE operations as different conditional flows.

Let' say,

  • I would like to give GET access to all resources to an APP - A , I will define API Product- petStoreRead & I will add both resources /pet & /petOwner to API Product & mention SCOPE as "READ"
  • I would like to give READ, WRITE access to all resources to an APP - B, I will define API Product - petStoreReadWrite & I will add both resources /pet & /petOwner to API Product & mention SCOPE as "READ, WRITE"
  • I would like to give READ access to /pet resource , WRITE access to /petOwner resource to APP - C, I will define a product like petStoreCustom1 & I will add both resources /pet & /petOwner to API Product & mention SCOPE as "SCOPECUSTOM1"

By doing above, Actually, you didn't enforce any restriction on API Proxy / Resources / Resource Methods yet. Let's come to Scope Enforcement now,

You will enforce scopes using OAuth policy using operation "verify access token" by mentioning scopes allowed, which you will attach to flows / conditional flows. Now let's see how enforcement is done.

  • You will Attach verifyAccessToken Policy like below to Conditional Flow - GET - /pet
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>READ SCOPECUSTOM1</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>
  • You will Attach verifyAccessToken Policy like below to Conditional Flow - POST - /pet
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>WRITE</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>
  • You will Attach verifyAccessToken Policy like below to Conditional Flow - GET - /petOwner
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>READ</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>
  • You will Attach verifyAccessToken Policy like below to Conditional Flow - POST - /petOwner
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>WRITE SCOPECUSTOM1</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>

You don't need a policy for each resource - method, you can create conditional flows based on your need & use some common policy.

Hope it helps 🙂

Hi @Anil Sagar. Your example is very clear. So a product is required per each combination of proxy resource - operation(s) to which (combination) i want to give different scopes.

thanks lot that helped.

@bantobanto , Yes, That's correct. If your query is resolved, Please click on accept link below the answer to mark it as resolved so that it will be helpful for others too. Keep us posted moving forward.

What If Im not Using Oauth , I just use verify_apikey , how can I implement the same functionality

@Anil Sagar @ Google the above information was very useful.If I'm not wrong we have to attach the verifyAccessToken policy to each Conditional flows.

Is it possible to club all the different verifyAccessToken policies in a single shared flow and then use this shared flow in the conditional flow?

What If Im not Using Oauth , I just use verify_apikey , how can I implement the same functionality