Layer7 API Management

Hello,

I'd like to get some guidance from the community on how to deal with internal clients.  In our organization, we have a number of legacy, internal, APIs that I'd like to get provisioned under API management.  My motivation for this is to establish a portfolio of managed services and to gain visibility of consumption.  However, I have a couple of questions:

1. Does it make sense to register API clients for every consumer when APIs are internal?  I see pros/cons to doing this.  The primary advantage is that I can tell who is calling.  However, the disadvantage is that I have a proliferation of API Keys to manage.  Does anyone deal with internal clients differently than external? 
2. How granular do you go with issuing API Keys?  I'm looking for guidance in situations where logical clients have multiple components that participate in consumption.  For example, I might have a web application that consumes services which may have a separately deployed component that also consumes.  I was leaning towards issuing one key per "logical" client.  I just wanted to check my thinking.
3. Is there any guidance on partitioning gateways - For example - one gateway for internal use, one gateway for external use.
4. What patterns exist for establishing trust relationships between gateways and backend services?  I'm interested in prohibiting direct access to services, but I can see arguments for allowing access (e.g. - testing, monitoring).  What have you done if you could share?

Appreciate any feedback.

Thanks!

Al

Hello!

These are heavy duty questions .... I will try.

Response to 1.:

I would suggest to use oauth instead of API Keys. There is more control with oauth clients than there is with API Keys. For example, when registering oauth clients in OAuth Manager, the value for 'Environment' could be used to mark this client as an 'internal' one. The client custom fields can be leveraged to express details of an oauth client in a JSON structure. That JSON message is then available at runtime and services can be configured to respect the message and details of it

Response to 2.:

In OTK you can register one single client but with multiple client_id's! Let's say 'MyFancyClient', one client_id for the web application, one for the mobile app and one for the server-2-server client (grant_type client_credentials). That allows you to have one client but with different access rules. Each client_id can be configured with different, valid SCOPE's, for example

Response to 3.:

I think this is more a question of available resources, maintenance, upgrades. On the other hand, you have to decide if it is acceptable to manage internal and external client through the same OTK instance (or gateway in general)

Response to 4.:

Trust can be created via user credentials (as in 'technical user that represents another machine), mutual SSL or via JWT. Those should be the most common solutions.

Maybe the list can be used as a starting point.

Regards,

Sascha