There are numerous ways to communicate that information from an API Gateway like Apigee Edge into a backend system like Firebase or Google Cloud Functions. (or AppEngine, or etc)
First, the information is knowable in the API Proxy.
if the inbound call is carrying an access token, then the API Proxy should call VerifyAccessToken. After successful verification, there will be context variables populated including
- developer.id
- developer.app.name
- client_id
(see the doc for full details)
That perhaps isn't quite the information that you seek when you say "Organization X". But take heart, there is more power here.
- any access token can have "custom attributes" associated to it at the time it is issued. If you use a password grant or a authorization code grant, then at the time you use GenerateAccessToken policy, you can attach user-oriented attributes including "Organization" or "team" or "user role" or whatever is appropriate for your scenario. Presumably this information is knowable at the time you are generating the token, because you've used an IdP that stores such information. After VerifyAccessToken, these custom attributes are available in context variables with names like accesstoken.{custom_attribute}.
- If you don't want or need an attribute associated to the authenticated _user_, you also have the option of attaching custom attributes to the API Product. These attributes will also be available in context variables after VerifyAccessToken, but the context variables will hold the same information for all tokens issued for that API product.
- You can also attach attributes to the developer. (Works the same way)
Second, you can augment the request.
The easiest way to attach the information about "organiztion X" to a request that the proxy sends to the backend is sometimes known as "header injection". The API Gateway can simply add a new header to the request that is sent to the backend, and this header can contain whatever you like. Do this with AssignMEssage and a Set element.
<AssignMessage name="AM-InjectHeader'>
<Set>
<Headers>
<Header name='my-new-header'>{variable_name_from_the_token}</Header>
</Headers>
</Set>
</AssignMessage>
If you want additional information in the header, the "text value" in the XML config is a Message Template. This means you can refer to multiple distinct variables within curly braces and the value of the header is then derived from all those referenced variables.
If the API proxy receives a request like this:
POST /v1/foo/bar
Content-Type: application/json
Accept: */*
Authorization: Beadrer ABC12345
The backend will see something like this:
POST /v1/foo/bar
Content-Type: application/json
Accept: */*
Authorization: Bearer ABC12345
My-New-Header: value-of-referenced-variable-here
You can also (probably should) remove the token before invoking the backend. You can o this with assignMEssage also:
<AssignMessage name="AM-RemoveAuthzHeader'>
<Remove>
<Headers>
<Header name='authorization'/>
</Headers>
</Remove>
</AssignMessage>
And optionally you can combine those AssignMessage policies into one:
<AssignMessage name="AM-AdjustHeaders'>
<Remove>
<Headers>
<Header name='authorization'/>
</Headers>
</Remove>
<Set>
<Headers>
<Header name='my-new-header'>{variable_name_from_the_token}</Header>
</Headers>
</Set>
</AssignMessage>
Third, you can embed the information in a signed JWT
You mentioned a JWT. The value of "my-new-header' can just as easily be a JWT, generated within the Apigee Edge proxy via the GenerateJWT policy, asserting various claims. You would do this if you wanted an extra level of security in the backend; it can verify the signature on the JWT before trusting the claims within it.
In my experience, this is more than is necessary, unless you have a somewhat complex dependency graph in your services mesh, in which service A calls B, which calls C, which calls D and E and F, and some of those call G and H and so on. And each service may wish to assert some claims. In that case a receiving service might want to understand which of the previous services has asserted claims, and you could use a signed JWT to verify the integrity and issuer of claims, at any point in the graph, in a zero-trust environment.
But often that is more than you need. Often a simple text header saying "Organization X" is suitable and satisfactory.
LinkedIn
Twitter
