Authorization for APIs with XACML and OAuth 2.0
Authorization for APIs with XACML and OAuth 2.0
Join the DZone community and get the full member experience.Join For Free
The Future of Enterprise Integration: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
In this blog post, let see how we can implement XACML to authorize the APIs. I wish you are familiar with OAuth 2.0 and lets directly go through the diagram
- OAuth access token is granted to the application from OAuth Authorization Server. Application can use the Access Token to access the API resources in the gateway.
- When request is received with Access Token, API Gateway can validate OAuth access token by calling to the OAuth Authorization server.
- If Access Token is verification successful, API Gateway can forward request to desired bank end Web service.
So, if we want to provide fine-grained authorization for API, The best way is to use XACML based Authorization approach.
Where authorization must happened
According to the diagram above, you can see that XACML authorization can be done in two places.
1. Within OAuth Authorization Server. After OAuth Authorization server verifies the OAuth access token, It can creates XACML request.
XACML request could contain following
- End user name
- Application name or Id
- API that is going to access
- HTTP verb
- Token scope
Most of use case, API Gateway wants to know whether this access token (end user) or application can access the given API or not. Therefore XACML request can be created with;
- Dnd user name (or application id/key) as the XACML subject
- API name and version as XACML resource
- HTTP verb as XACML action
XACML request is sen tto the PDP for authorization decision
2. Within API Gateway. After validation decision is received to the gateway, It can further validate for the authorization before request is forwarded to back end service.
XACML request can contain the relevant things that are mentioned above. It can be generated at API gateway and can be sent to the PDP for authorization decision.
I think, The best place to do the authorization (to keep the PEP) is within the OAuth Authorization Server not within the API gateway.
- In proper development, API gateway is in DMZ. OAuth Authorization server and PDP would be in the LAN as Enterprise user store must be exposed to them. Therefore, It is only required one service call from API gateway to LAN. If XACML PEP was within the API Gateway there can be two requests to LAN.
- Mostly OAuth Authorization server and PDP can be embedded in to on server. This would create good performance gain as it could avoid the service call for PEP-PDP. But API gateway and PDP can not be embedded, because API gateway is normally in DMZ and Enterprise user store can not be exposed to it. Also, API gateway it fully optimized to do the message mediation and message processing. Therefore, it may be hard to balance resource utilization properly once PDP is within same server.
API Authorization with WSO2 Identity Server and API Manager
Identity Server can acts an OAuth Authorization Server. Also It is a well know XACML PDP.
API Manager is fully API solution with consists of API Gateway, publisher, store and key manager. More details about architecture can be found at here. In API manager, Key manager acts as an OAuth Authorization server and Identity Server can be replaced with it as well.
Identity Server and API Manager provide extensible architecture where you can plug extension point. Therefore we can extend to support for XACML based Authorization. Let see how we can do it.
We assume that XACML engine has been embedded in to the OAuth Authorization server. You can use Key Manager as the Identity Server or you can install XACML features in API manager, Please find more details from here.
1. Lets extend the default scope handler of OAuth2 component and implement the new scope handler that supports to call XACML PDP. Please find the project from here. You can go through project and modify it as you wish.
2. Deploy the custom scope handler by copying org.xacmlinfo.xacml.oauth.scope-1.0.0.jar OSGI bundle file in to <HOME>/repository/components/dropins directory
3. Register custom scope handler by updating following element under <OAuth> element in identity.xml file which can be found at <HOME>/repository/conf
If you need implement the scope handler to call remote XACML PDP, you need to modify the scope handler with an entitlement client that calls the Entitlement Service. You can find more details about Entitlement Service from here.
Lets build some XACML sample with OAuth in next blog post…!
Published at DZone with permission of Asela Pathberiya , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.