Layer7 API Management

Expand all | Collapse all

Is there any way to do role based access management in CA API Gateway (restrict a user from accessing one policy and allowing another), with Oauth2 Token in Authorization header?

  • 1.  Is there any way to do role based access management in CA API Gateway (restrict a user from accessing one policy and allowing another), with Oauth2 Token in Authorization header?

    Posted Jun 29, 2018 12:35 AM

    I have 10 API Gateway "service call policies" all using the same template (Oauth2 Token check -> Json Request -> Route to backend Middleware system -> Response).

    I have 2 LDAP groups with some common users across two groups. All the users within one group has same level of permission.

    Both the Group's users are using the same client_Id & Secret for generating Oauth2 token using a common "Login" policy.

     

    Is there any restriction or policy/assertion which can be implemented In the "service call policy" to prevent a user from accessing one "service call policy" but not the other ?

     

    Thanks



  • 2.  Re: Is there any way to do role based access management in CA API Gateway (restrict a user from accessing one policy and allowing another), with Oauth2 Token in Authorization header?

    Posted Dec 18, 2018 04:30 PM

    Hello!

    There are a few things, assuming users are also authenticated via OTK:

    - the policy 'OTK User Attribute Look Up' sets the role of the current user. That policy can be modified to retrieve the role (and other attributes) via and LDAP call

    - the assertion 'OTK Require OAuth 2.0 Token', used at an API (service call policy), sets a variable '${session.subscriber_id}' which is the username of the user who granted the access_token

    - that variables can be used with 'OTK User Attribute Look Up' to retrieve the current role '${current.user.role}'

     

    If you have a look at the default implementation of '/userinfo' you can see how it is used.

     

    With that, you are able to grant or deny access to certain APIs. The assertion also sets '${current.user.attributes}' which can be used to make decisions.

     

    I hope that helps,

    Sascha