…yes, yes it can. And let me show you how.
I get asked this in different ways. It usually boils down to someone asking to integrate some application, infrastructure, etc. with their chosen authentication / SSO provider (e.g. Ping, Okta, ForgeRock, Microsoft, etc.). When you look at the website / documentation of the selected target (e.g. an API gateway), it will probably not specifically list the authentication provider but will have examples for the local / cloud / built-in provider (e.g. AWS / Cognito). And, in a lot of cases, people I work with, will use those since that is what is documented. This leads to the proliferation of identities across applications and providers leading to poor user experience and ‘hacks’ to get disparate environments to trust / work together.
But, there is a better approach. Most of the time when I get asked this, the first thing I look for is what protocols / standards are supported. Most providers support either SAML or OIDC. Which, if that is the cases, you can use these standards to integrate cross platform.
To highlight this point, I was recently asked to provide a proof of concept integrating Oracle OCI API gateway with ForgeRock Identity Cloud (now Ping Advanced Identity Cloud). Looking at the documentation, immediately you can see they support JWT tokens and also support custom Authorizer Functions (similar to AWS Lambdas and Azure Functions). So, I set off to build out the POC to show this could work and ensure my customer could use their infrastructure of choice with their authentication provider of choice.
The diagram below outlines what I built out.
What we have here is an OCI API gateway with a custom authorizer function attached that will use the ForgeRock discovery endpoint to validate Bearer tokens that are provided. To do this, I used a node function (see below) that will get the token and go introspect the token to ensure it is valid. To add more, given the standard has an expiration assigned to it, I set the cache interval for the token validation to the expiration time of the token so you do not need to continuously validate the token. (if you want the full code, just reach out to me).
Once this was completed, I deployed this to Oracle OCI and attached it to my API gateway.
Then this is the function that is deployed from the source code.
With this all deployed, I can launch my handy Postman and get a token from my ForgeRock cloud environment.
Then submit this to my API endpoint which will send me back my sample response once my token has been validated.
So, now we have two different cloud platforms, talking and validating users to ensure a unified user experience and ensure security across infrastructure providers.
Now, this was a POC to show it could be done, to mature and complete this setup, you would want to add some additional token endpoints to the API gateway that can get a token for a caller along with validate the incoming Bearer tokens. This would give a complete solution for the infrastructure and integration.
So, next time you are looking to integrate disparate infrastructure, applications, and authentication providers, do not look solely at the vendors supported in each, but look at the standards / protocols and options for building out the integrations. This will give you a much richer experience going forward and also ensure you are centralizing capabilities and enforcement points.
Further Reading / Research:
Oracle API Functions: https://docs.oracle.com/en-us/iaas/Content/Functions/Tasks/functionsuploading.htm
AWS API Gateway Lambdas: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-lambda-integration.html
Azure APIM Functions: https://learn.microsoft.com/en-us/azure/api-management/import-function-app-as-api
