Using a central authorization endpoint for all api proxies to rely on

Not applicable

Apigee is really good at providing central logging, security, limits, quota, etc for the various API proxies. Using oauth2 is fairly simple with Apigee. One of the ares where we are running into problem is having a consistent manner to do authorization and fine grained authorization for the various APIs.

With oauth2 3-legged we can tie attributes such as username to oauth2 tokens. Instead of having each API backend knowledge on what operations a user can perform on a given endpoint, we want to have a central /authorization endpoint that could receive as parameters: user, endpoint and operation. This authorization endpoint would then specify if the user is allowed to perform that operation or not. Rather than building something from scratch, I wanted to reach out to this community to find out what people are using. Do people have any best practices to share? The oauth2 spec doesn't really cover this area. OIDC using JWT can provide claims / attributes of the user. That doesn't really cover what operation the user is allowed to perform.

Can you share what you have learned in this authorization space? How do you leverage Apigee to perform authorization?

Solved Solved
1 3 699
1 ACCEPTED SOLUTION

See also, this Q&A.

There are products that satisfy this requirement. Back in the day of XML Web Services, there was a standard that emerged called "XACML" : extensible Access Control Markup Language. It provided a standard way to describe tuples of {subject, resource, action} with allow or deny semantics for those tuples. The subject identified the person or party requesting access, and the resource was... what you think of as a REST resource (perhaps identified by a path in the REST model), and finally the action would map to the http verb.

The idea behind the standard was that you'd be able to author rules in this XACML format and then move them into various products that would ingest XACML.

Then, at runtime, systems could send queries into the authorization server, containing that tuple, and get an "allow" or "deny" back from the server.

Though XACML provided the standard for authoring rules, there was no standard runtime query interface defined for these "authorization servers". In other words, the way to send in a query to the IBM XACML server (I think it was called Tivoli Security Policy Manager) was entirely different from the way you'd send a query into the Oracle/Weblogic XACML server, which was called WebLogic Entitlements Server, I think. These names may have been changed by now. .

And then finally there was the Microsoft option, which was called AzMan and was part of Windows. (Deprecated since WS2012). It was not XACML compliant, but basically did the same thing as the above.

And anyway, the whole idea behind XACML was not very complicated, and moving from one way to describe those simple rules to another, was not very difficult.

Today there are more modern options like Axiomatics and others. Search on community.apigee.com for these terms and you may find some hints.

And you could even encode the authorization rules into a BaaS collection, and just query BaaS. If your requirements for authoring, auditing, reporting, and editing those authorization rules is pretty simple, something "quick and dirty" like BaaS might be acceptable. If you have requirements to show an audit trail for every change of the authorization rule set, or you need more complex ingest options, or you want to be able to stage changes, then you might want to look into a mature third party authorization control product like Axiomatics.

The key thing you need is to model the {subject, resource, action} tuple.

For example, these might be some rules:

Subject Resource Action Result
Bob /xyz GET allow
Bob /xyz POST deny
Bob /abc GET allow
Bob /abc POST allow
Alice /xyz POST allow
Alice /abc POST allow

If you are using OAuthV2 and you have tokens with scopes attached, you might want to replace the "subject" in that tuple with something like "scopeset", which the authorization server would treat the same way as "subject".

Some cases extend that tuple to include "environment" or "context" which might include stuff like the time of day, the number of calls made over the past hour, and so on . So a rule could deny Bob GET access to /xyz if it is past 20:00.

And then each proxy would call a ServiceCallout to the authorization server, passing the appropriate tuple, and then reject or allow the call based on the response.

Wrap that call with some caching, and you're set for a high-throughput system.

View solution in original post

3 REPLIES 3

See also, this Q&A.

There are products that satisfy this requirement. Back in the day of XML Web Services, there was a standard that emerged called "XACML" : extensible Access Control Markup Language. It provided a standard way to describe tuples of {subject, resource, action} with allow or deny semantics for those tuples. The subject identified the person or party requesting access, and the resource was... what you think of as a REST resource (perhaps identified by a path in the REST model), and finally the action would map to the http verb.

The idea behind the standard was that you'd be able to author rules in this XACML format and then move them into various products that would ingest XACML.

Then, at runtime, systems could send queries into the authorization server, containing that tuple, and get an "allow" or "deny" back from the server.

Though XACML provided the standard for authoring rules, there was no standard runtime query interface defined for these "authorization servers". In other words, the way to send in a query to the IBM XACML server (I think it was called Tivoli Security Policy Manager) was entirely different from the way you'd send a query into the Oracle/Weblogic XACML server, which was called WebLogic Entitlements Server, I think. These names may have been changed by now. .

And then finally there was the Microsoft option, which was called AzMan and was part of Windows. (Deprecated since WS2012). It was not XACML compliant, but basically did the same thing as the above.

And anyway, the whole idea behind XACML was not very complicated, and moving from one way to describe those simple rules to another, was not very difficult.

Today there are more modern options like Axiomatics and others. Search on community.apigee.com for these terms and you may find some hints.

And you could even encode the authorization rules into a BaaS collection, and just query BaaS. If your requirements for authoring, auditing, reporting, and editing those authorization rules is pretty simple, something "quick and dirty" like BaaS might be acceptable. If you have requirements to show an audit trail for every change of the authorization rule set, or you need more complex ingest options, or you want to be able to stage changes, then you might want to look into a mature third party authorization control product like Axiomatics.

The key thing you need is to model the {subject, resource, action} tuple.

For example, these might be some rules:

Subject Resource Action Result
Bob /xyz GET allow
Bob /xyz POST deny
Bob /abc GET allow
Bob /abc POST allow
Alice /xyz POST allow
Alice /abc POST allow

If you are using OAuthV2 and you have tokens with scopes attached, you might want to replace the "subject" in that tuple with something like "scopeset", which the authorization server would treat the same way as "subject".

Some cases extend that tuple to include "environment" or "context" which might include stuff like the time of day, the number of calls made over the past hour, and so on . So a rule could deny Bob GET access to /xyz if it is past 20:00.

And then each proxy would call a ServiceCallout to the authorization server, passing the appropriate tuple, and then reject or allow the call based on the response.

Wrap that call with some caching, and you're set for a high-throughput system.

Thanks for the detailed answer. I appreciate it. I did a search for the terms as you suggested and I was able to dig up more threads from the apigee community forums.

@Dino and @jose.cedeno Just wanted to add a note regarding a standard runtime query for XACML systems. The standard added REST and JSON profiles a while ago, which makes it much easier to integrate (proprietary SDK no longer needed) and interoperability with any XACML/ABAC system that supports the latest profiles. Further, you can also use the ABAC policies to implement field filtering when you need to redact PII or other sensitive data when returning records to a client