How to use same client credentials in multiple organisations

[#1]

Hi All,

I am working on Migration of client credentials from Layer 7 to Apigee.

In Apigee I have Dev and ptest organization sharing same Cassandra. When I created client credentials in Dev, I am not able to create same credentials in ptest organization. Is there anyway to use the same credentials in ptest?

[brites]

I don't know if there is a clean, simple way to do this.

You could possible do periodic exports and account creation using the management API:

https://docs.apigee.com/api-platform/security/oauth/obtaining-developer-keys

Or, as this is an private cloud deployment, if it's a dev/test deployment, you could do a copy within Cassandra itself. It might take a bit of trial an error to ensure the appropriate records are properly copied to the appropriate places between organizations.

Or finally, you could possibly use proxy chaining, having one org call the other for authentication - but this could get really convoluted/complicated.

[#3]

The client id is same but password for orgs are different. So, I cannot do proxy call another org to verify.

[Feroz_Mahammad]

@Priyadarshi Ajitav Jena, consumer key should be unique in a planet. Hence you can't have same consumer key under same or different organization in the planet.

[#5]

Yes, I understand that. But I have the requirement, so searching for any workaround if anyone tried.

[dchiesa1 · Accepted solution]

There is not a direct way, but there is a sort of hacky way, to do as you wish: use the same creds in dev as in ptest.

Suppse your keys are key1, key2, etc.

You would need to "import" keys into the various orgs, appending the org name to the root value of the key. Resulting in like key1-dev in dev, key1-ptest in ptest, etc.

Clients always use the same key but when any proxies that make use of that key (VerifyApiKey or GenerateAccessToken, etc) they must first add the suffix, via AssignMessage, relying on the "organization.name" context variable.

This works if you aren't exposing the dev apps directly to developers. If you have a devportal you might need to do the reverse on the devportal when displaying the credentials (remove the suffix).

It's sort of hacky, but it might satsify.

Outside of this I know of no other workaround, aside from: MOVE TO APIGEE CLOUD, which does not have this limitation.

🙂

[#7]

I liked the answer. Nice thought. Will implement the suffix one. That resolves my problem.