Is there a way to integrate APIGee hybrid with OIDC? We have few front end applications which should call Apigee proxies. Since the proxies are OAuth protected I am wondering if we can use OIDC for communication between front end and Apigee Hybrid. Most of the articles we found online are related to google cloud + Apigee. I am specifically looking for solutions involving Apigee Hybrid. We are using PING for OAuth.
Solved! Go to Solution.
One of my colleague(earlier place) - @naseerm made a very good series across Apigee & Ping integration. hope you follow thru.
Credits @naseerm
https://www.youtube.com/watch?v=JJBZBhoXN4I
https://www.youtube.com/watch?v=2YuU90EprUQ
The challenge I see with JWT token is the Client ID and other claims are signed with the token and sent back to the client. While the consumer cannot modify the token to add a different client Id, I am wondering if we can keep it abstract.
By my way of thinking the JWT is already abstract. The claims are visible to anyone that possesses the token, but the meaning of those claims is defined by the token verifier. For example, imagine a "scope" claim in the JWT payload. The meaning or semantics of any value in that claim would be determined by the server.
I like Access Tokens as they store the claims in server. I am wondering if there is a way to make access tokens common across all Apigee Organizations in Hybrid setup. That is, if Apigee GW1 generates an Access token and shared with the client, can another Apigee GW (GW2 - different Organization) accept the token and authorize user to access API, as long as Client ID is valid in this Org as well?
I think I understand what you're saying. It seems like an over-constrained problem. Here's what I mean. There are two types of access tokens we are discussing here, I think: opaque and JWT. Both are access tokens, both can have expiry, a client id, custom claims (like scope), issue time, issuer, and so on. The difference: the opaque token is really just a random string of characters that acts as a reference to information that is held by the token issuer, in its token database. The JWT holds the information itself.
In Apigee, a single organization can have many many distributed gateways, and they all share the same token database. So an opaque token issued by "GW1" can be later verified by "GW2", as long as both of these gateways are running in the same organization. Your scenario is different: GW1 and GW2 are in different organizations, which means they have distinct token databases, which means a token known by, and issued by, one organization, will not be known by or verifiable in, a second organization.
It sounds like you want the benefits of the federated token, but without the "visibility" that is implicit with the JWT format. What can you do?
One option is to... intercede an API facade between the client and the IdP, so that when the IDP generates a JWT, the API facade can intercept it, and ... *do something with it*... before sending back a different JWT access token to the original client. One simplistic option would be to ENCRYPT the original signed JWT and embed that as a claim into a new signed JWT. And then send back the second JWT to the client. This would obscure any claims in the original JWT.
The client could then present this new JWT to any gateway in any Apigee organization. Assuming the gateway has access to the PRIVATE or SECRET key that can decrypt the original signed JWT, then the Apigee gateway would be able to see all the claims in the original JWT, and would be able to grant authorization based on those claims.
Another option. Again use a facade, and have the Apigee facade issue an opaque token, store the original signed JWT as a hidden attribute, and embed the opaque token into a new signed JWT, along with a claim for "issuer", send that to client. Then the client can present that signed token to any Apigee gateway. The Apigee gateway can crack open the JWT, find the issuer, and connect to the issuer directly, to validate the token that is embedded in the JWT. This is similar to the first idea, except, it replaces the encryption with a synchronous connection to a gateway in the originating organization.
There are other options too, I'm sure.
You can use a GenerateJWT policy (builtin) to generate an encrypted JWT.
Hi ven
I answered this question in your other post: https://www.googlecloudcommunity.com/gc/Apigee/Ping-in-Apigee-Hybrid/m-p/479783#M72577
Hi dchiesa,
I am inclined towards the following solution since we have multiple Apigee organizations, one per each line of business and the front end application may call APIs deployed to all the Orgs. I want to keep one token to interact with all Apigee GWs. The challenge I see with JWT token is the Client ID and other claims are signed with the token and sent back to the client. While the consumer cannot modify the token to add a different client Id, I am wondering if we can keep it abstract. I like Access Tokens as they store the claims in server. I am wondering if there is a way to make access tokens common across all Apigee Organizations in Hybrid setup. That is, if Apigee GW1 generates an Access token and shared with the client, can another Apigee GW (GW2 - different Organization) accept the token and authorize user to access API, as long as Client ID is valid in this Org as well?
The challenge I see with JWT token is the Client ID and other claims are signed with the token and sent back to the client. While the consumer cannot modify the token to add a different client Id, I am wondering if we can keep it abstract.
By my way of thinking the JWT is already abstract. The claims are visible to anyone that possesses the token, but the meaning of those claims is defined by the token verifier. For example, imagine a "scope" claim in the JWT payload. The meaning or semantics of any value in that claim would be determined by the server.
I like Access Tokens as they store the claims in server. I am wondering if there is a way to make access tokens common across all Apigee Organizations in Hybrid setup. That is, if Apigee GW1 generates an Access token and shared with the client, can another Apigee GW (GW2 - different Organization) accept the token and authorize user to access API, as long as Client ID is valid in this Org as well?
I think I understand what you're saying. It seems like an over-constrained problem. Here's what I mean. There are two types of access tokens we are discussing here, I think: opaque and JWT. Both are access tokens, both can have expiry, a client id, custom claims (like scope), issue time, issuer, and so on. The difference: the opaque token is really just a random string of characters that acts as a reference to information that is held by the token issuer, in its token database. The JWT holds the information itself.
In Apigee, a single organization can have many many distributed gateways, and they all share the same token database. So an opaque token issued by "GW1" can be later verified by "GW2", as long as both of these gateways are running in the same organization. Your scenario is different: GW1 and GW2 are in different organizations, which means they have distinct token databases, which means a token known by, and issued by, one organization, will not be known by or verifiable in, a second organization.
It sounds like you want the benefits of the federated token, but without the "visibility" that is implicit with the JWT format. What can you do?
One option is to... intercede an API facade between the client and the IdP, so that when the IDP generates a JWT, the API facade can intercept it, and ... *do something with it*... before sending back a different JWT access token to the original client. One simplistic option would be to ENCRYPT the original signed JWT and embed that as a claim into a new signed JWT. And then send back the second JWT to the client. This would obscure any claims in the original JWT.
The client could then present this new JWT to any gateway in any Apigee organization. Assuming the gateway has access to the PRIVATE or SECRET key that can decrypt the original signed JWT, then the Apigee gateway would be able to see all the claims in the original JWT, and would be able to grant authorization based on those claims.
Another option. Again use a facade, and have the Apigee facade issue an opaque token, store the original signed JWT as a hidden attribute, and embed the opaque token into a new signed JWT, along with a claim for "issuer", send that to client. Then the client can present that signed token to any Apigee gateway. The Apigee gateway can crack open the JWT, find the issuer, and connect to the issuer directly, to validate the token that is embedded in the JWT. This is similar to the first idea, except, it replaces the encryption with a synchronous connection to a gateway in the originating organization.
There are other options too, I'm sure.
Thanks dchiesa1 for sharing the options. Is there a policy in Apigee Hybrid which we can use to encrypt and decrypt.
You can use a GenerateJWT policy (builtin) to generate an encrypted JWT.
One of my colleague(earlier place) - @naseerm made a very good series across Apigee & Ping integration. hope you follow thru.
Credits @naseerm
https://www.youtube.com/watch?v=JJBZBhoXN4I
https://www.youtube.com/watch?v=2YuU90EprUQ