We have an in-house security token service (working with standard OpenId Connect/OAuth 2.0) federated with several different IdPs that manages the security of all our web apps and APIs. It emits user access tokens with custom metadata and most of our backend's security is based on that custom metadata. At the moment, all the security applications (client ids, secrets) defined in the STS are simply stored in a XML file deployed with it. It's not ideal, but it's simple and since it's only managing our internal applications, it's been working just fine so far.
We are at a point now where we'd like to give access to our APIs to external customers and we need a platform to manage subscriptions/licences to our APIs and provide a developper portal to our custsomers. The problem we have is that we can't stop using our STS because most of our APIs rely on our custom user tokens to work. We don't want to change that, as it would be very expensive to change course now and it has allowed us to greatly improve the performance of our backend over the last few months.
What we would like to do, is use Apigee to manage our customers' secucrity applications, and access all its data (client ids, secrets, redirect uris, etc.) through APIs during runtime with our STS to allow us to use Apigee's data as a second security application store. This way, we'd still be able to use our custom tokens, we'd get an application management module (UI) for our customers without having to build one ourselves, and we would still be able to use Apigee's features to manage subscriptions/licences and access rights to our APIs based on access tokens instead of API keys (as API keys would force our customers to "wrap" our APIs to secure the key, instead of just building javascript single page apps). Is that scenario possible?
LinkedIn
Twitter
