Role based access Restriction for APIs exposed from API Gateway

[Suneelthota]

We have published APIs using swagger document from API Portal EE to API gateway servers. Our Application team developed a code using OAuth Scope to support "Role-based access to all published APIs on Gateway. We want to implement this functionality in API Gateway to reduce development and maintenance effort on backend applications.  

 

So, I want to know how to implement Role-based access restriction for APIs exposed from gateway using OAuth Scope? Currently OAuth token is working for all users without any type of access restriction in resource path.

 

Ex:

 

API Resource path:  /session/api/v1/{ID} -> GET POST DELETE

 

User1 -> GET

User2 -> GET POST

User3 -> DELETE

User4 -> GET POST DELETE

 

Hope this functionality supports in API Developer Portal & API Gateway server. Appreciate, any quick response and help to implement this functionality.

[saspr02]

Hello!

 

In OTK you would not use OAuth SCOPE for user based access control. SCOPE is meant for clients (applications). Instead, you would add attributes about your users in your LDAP. Once done, you can then use this knowledge in an API to restrict access.

 

For example:

- LDAP, user: Sascha, attribute: 'methods_supported = POST GET'

- In OTK configure 'OTK User Attribute Look Up' to connect to your LDAP

- in your API use these assertions:

 ....

 .... OTK Require OAuth 2.0 Token --> this will set '${session.subscriber_id}' which is the username of the current oauth session

 .... OTK User Attribute Look Up --> use '${session.subscriber_id}' as input. The output will be whatever you have configured for it to expose

 ... compare(required method, methods valid for user)) --> if successful, continue, otherwise fail

 

Of course, the LDAP does not need to be used, it could also be a table in a database.

 

I hope this helps!

[Zhijun He]

Dear Suneel,

In theory, if your user/role was bound to the oauth client, then you might use SCOPE.

But that means you may need 4 apps for 4 users/roles.

 

Therefore, Sascha's solution should be a better solution.

 

Regards,

Mark