Normalizing auth using shared flows and flow hooks

Former Community Member
Not applicable

Hello!

Due to inconsistent support by our targeted API consumers, we're obliged to offer OIDC/OAuth2 (the preferred choice), SAML, and (when absolutely necessary) Basic Auth as parallel options. We would like to marshal these separate authentication methods into a common JWT format before passing the JWT on to the individual proxies for mediation to the backends they surface. Further, we plan to set the headers X-Mediated-From (in the pre-proxy), X-Mediated-To (in the proxies themselves), and an altered WWW-Authenticate (in the response). The ultimate goal being to minimize the amount of specialized proxy development required and to permit the direct passing of the token to the backend whenever and wherever a JWT is supported.

Do you have any advice on how to execute this properly? Any pitfalls we should be aware of? Must we have (as I assume) an app (and therefore a client ID) for each API in order to facilitate authentication?

I have only just started piecing together the pre-proxy component, and the line between functionality I must "manually" provide and what happens automagically is still a bit unclear to me (mostly owing to the apparent uniqueness of our use case).

Any constructive insight is appreciated.

Thanks in advance!

2 4 223
4 REPLIES 4

Lots to unpack here....

When you say "parallel options" are you saying that an api must support more than one authentication method at the same time? Implying "APIx" needs Basic Auth, JWT and OAuth support concurrently? OR are you saying any given API will support 1 and only one of many options the platform supports. Ultimately whatever inbound authentication is provided gets exchanged for JWT to target?

As for how to attack this problem, if you subscribe to the idea that some folks in your organization would be designated as "Gateway Developers" and they would be responsible for creating the shared flows that execute your described required logic. Ideally these shared flows become flowhooks which implies they are injected into every api per your governance team directives. Because they are injected without fail they then become transparent to the proxy developers who are charged with the care and feeding of api proxies as opposed to the gateway itself. Teaser is a KVM entry per api could determine what security model is required for a given api along with other useful externalizations like target url, spike arrest settings and the like.

Basic idea here is the more you can push to shared flows and flowhooks the more consistent (and defensible) your api behavior becomes and lightens the load on the proxy developers.

Depending on your answers... more to come.

Former Community Member
Not applicable

Thanks for your response. Right, option 2: What I mean is that the Apigee Edge platform must support multiple authentication options at one time and that we want to normalize whatever the inbound authentication mechanism is so that all proxies can be written in as consistent a manner as possible. Therefore, when any given consumer connects to any given API they will authenticate in the manner required by that API and the pre-proxy flowhooks will transform/mediate that authentication into an Apigee JWT to be processed by the proxy corresponding to the API. If the API in question is back-ended by something that supports JWTs, the token will "pass through" to the backend unmodified. If, however, the API surfaces a backend which does not support a JWT it will be up to the API's supporting proxy to marshal the JWT into something the backend CAN consume. Is that clearer? Sorry, I know it's a bit dense.

What you're describing as a proposed solution is precisely what I'm trying to figure out how to do properly. We're at the inception point for all of this so we don't have the division of teams and responsibilities referenced in your response. For this particular effort, it is just me... trying to get in front of this before we open it up to the rest of our organization.

Hmmm, interesting use case.

I'd start off with a "Marshal" Shared Flow, with an Extract Variables, then Conditionally execute other Shared Flows based on what you got (e.g. Bearer, Basic, SAML) each setting variables, then one final Shared Flow to set the JWT.

And Bob's your uncle!

Former Community Member
Not applicable

Thanks for your response. This is more or less what I am trying to do, there's still the matter of marshalling the response and the subsequent WWW-Authenticate header, but first I need to successfully build out and implement the pre-proxy components.