With Apigee, A typical technical use case is to enforce authorization policies for inbound calls, before proxying to an upstream system. A good pattern is:
1. Externalize the authorization decisions, perhaps in an external authorization database table, service, or rules engine.
- Each rule can be modeled as a tuple of {subject, object, action}, related to a binary allow/deny decision. In an HTTP REST API, the subject is the client and the end user (if any); the object is the resource, represented by the url path; and the action is the HTTP verb: GET, PUT, POST, DELETE.
- applying the rules is as simple as finding a match for the tuple, and selecting the allow/deny result.
2. Configure the Apigee API Proxy to call out to that external system to obtain the authorization decision.
3. Enforce the authorization decision within the API Proxy.
This is really straightforward to do, with Apigee, relying on such capabilities as:
- OAuthV2 token verification to obtain client and user identity
- Calls to external services within the scope of a request, via the ServiceCallout policy.
- Conditional flows, allowing different responses based on context.
I put together a quick screencast showing you how to do this, using a Google sheet as a store for the authorization rules. Check it out!
github repo: https://github.com/DinoChiesa/Apigee-External-Authorization-1
Contributors
80 People are following this .
