11 Replies Latest reply on Jul 11, 2014 8:00 PM by eric.wittmann

API Management: Identity Management

eric.wittmann Oct 16, 2013 9:15 AM

An important concept in Overlord API Management is the distinction between an API Manager user and an Application User. Here is a quick overview.

First, we have this web application called Overlord API Manager, which allows users to log into it and perform API Management related actions. The actions available depend on the roles associated with the logged-in user, but include things like "Create API", "Create Application", and "Request API Key (for Application XYZ)". This is the web application that Service/API Managers and Application Developers use to connect with each other. Think of it as the github for APIs. The API Manager application could be connected to an LDAP directory to handle authentication/authorization, or to a database, or some other source of identity. Basically it's a typical web app.

Once APIs are being managed in this application, those APIs can be configured in various ways that relate to identity management. It's very dependent on the API being managed, and the capabilities desired for it. There are a number of possible Identity Management related scenarios. Here are a few:

Public API - No Authentication or Authorization

Obviously this is uncommon and not very interesting. Here neither the API Management Gateway *nor* the back-end service care who is invoking it. Nothing to do here.

All authentication and authorization is handled by the back-end API implementation.

In this scenario, the API Management Gateway simply passes through any authentication related information and lets the back-end implementation do whatever it would have done if invoked directly. For example, a REST call with BASIC authentication information passed via the Authorization HTTP header would simply pass through the Authorization header to the back-end service. The back-end service is responsible for managing users and privileges. Thus, the API management Gateway must support being configured as a pass-through.

Authentication and Role Lookup is performed by the Gateway

In this scenario, the Gateway is configured to authenticate inbound invokes against some source of identity. The specific API being managed should be configurable as to what source of identity is used for authentication and role lookup. Some examples include:

LDAP
Database
OpenID

The inbound credentials (BASIC auth, Bearer Token, etc...) can be validated against the source of identity. The source of identity can then be used to lookup detailed user information and role information. This data is then passed to the back-end service, which makes authorization decisions based on the roles.

Authentication and Authorization are both performed by the Gateway

In this scenario, the Gateway is configured to authentication inbound invokes against some source of identity and also verify that the user is authorized to perform the specific API operation. This scenario may be fairly complicated to configure, especially if fine-grained authorization is supported (e.g. authorization based on request context). Again, the source of identity should be configurable and support the usual suspects such as LDAP and OpenID. Once authentication and authorization are complete, the user's credentials may or may not be passed through to the backend service (since it may or may not care).

It is important to note that the source of identity used to authenticate users into the API Manager web app may or may not be the same source of identity used to manage access to APIs being managed.

1. Re: API Management: Identity Management

objectiser Oct 16, 2013 4:39 AM (in response to eric.wittmann)

Eric Wittmann wrote:

All authentication and authorization is handled by the back-end API implementation.

In this scenario, the API Management Gateway simply passes through any authentication related information and lets the back-end implementation do whatever it would have done if invoked directly. For example, a REST call with BASIC authentication information passed via the Authorization HTTP header would simply pass through the Authorization header to the back-end service. The back-end service is responsible for managing users and privileges. Thus, the API management Gateway must support being configured as a pass-through.

In this scenario, the gateway still needs to be able to track who the user is, to be able to record usage metrics on their behalf. Although when handling the request, it won't necessarily know whether the authentication details are valid for use in (for example) recording metrics - I guess we can assume the service will return a 401 (or equivalent) if they are not valid, which can be used by the gateway to determine whether/how the metrics should be recorded.

So in terms of the requirements for metric recording, or recording activity events in general, we need to consider whether this should be postponed until the forwarded request has been handled.

Eric Wittmann wrote:

Authentication and Role Lookup is performed by the Gateway

....

The inbound credentials (BASIC auth, Bearer Token, etc...) can be validated against the source of identity. The source of identity can then be used to lookup detailed user information and role information. This data is then passed to the back-end service, which makes authorization decisions based on the roles.

Minor point - whether the credentials should be passed to the backend service should be configurable - the service may not care.
Actions
2. Re: API Management: Identity Management

eric.wittmann Oct 16, 2013 7:54 AM (in response to objectiser)

I think we would always want the metrics to be recorded after the request has been handled, since metrics likely involves more than just the number of requests performed. It likely also includes other metrics such as response time, which is obviously only available after the response is received from the back end service.

As for your point about credentials not being passed to the backend service - I agree. Although that particular scenario assumes that the backend service is doing some sort of authorization logic, so at least the user's roles would need to be passed to the backend. This may be a fabricated scenario (hybrid solution where the Gateway does authentication but the backend service does authorization) - I'm unaware of any protocol designed to only pass role information to a service.
Actions
3. Re: API Management: Identity Management

objectiser Oct 16, 2013 8:47 AM (in response to eric.wittmann)

The case I am more thinking about is where the internal service does not deal with authentication/authorization at all, and the API manager is being used as a substitute to provide that functionality. In this situation I don't think credentials or role need to be passed to the service.
Actions
4. Re: API Management: Identity Management

eric.wittmann Oct 16, 2013 9:15 AM (in response to objectiser)

Agreed. I have updated the Authentication and Authorization are both performed by the Gateway section to call out this point.
Actions
5. Re: API Management: Identity Management

david.valtorta Mar 4, 2014 3:42 AM (in response to eric.wittmann)

What is your recommendation as a secure API Management platform? im actually using 3scale and never had a problem about this, should i take care?
Actions
6. Re: API Management: Identity Management

eric.wittmann Mar 4, 2014 7:42 AM (in response to david.valtorta)

I think it is really more a matter of Security features that we're discussing in this thread, vs. the actual security of the API Management solution itself. What I mean is that an API Management solution is (ultimately) just something that proxies requests to one or more back-end systems. The question is what sort of security options does the API Management system have when performing that function? It's entirely possible that it has none. In that case the back end system would be responsible for handling whatever security (authentication and authorization) features are necessary. But it's also possible that the API Management system can actually perform the authentication and/or authorization responsibilities prior to ever sending the request to the back end system. This would require that the service being managed by the API Management system be configured to include this sort of security functionality.

So I guess it depends a lot on the services that the API Management system is being used to manage. Security at the proxy/gateway layer may be important or not.
Actions
7. Re: API Management: Identity Management

msavy Jul 10, 2014 1:34 PM (in response to eric.wittmann)

A suggestion I would have is that it would be nice to offer some sort of gateway <-> client authentication (perhaps only gateway -> client?).

I can imagine scenarios where users want to avoid clients bypassing the gateway and calling directly onto their services, but aren't able to configure a firewall (or other similar mechanism) to prevent unauthorised direct access.

For example, imagine a user has a federated cloud setup where their nodes need to communicate amongst each other, with other clouds, and with multiple gateways (e.g. when clustered) with rapid node expansion/contraction. It may be much more convenient to provide them an identity/authentication mechanism rather than relying on network configuration. I realise we'd probably be pushing some gateway logic into the applications, which may be less than desirable, but it could be a nice option to provide for such use-cases.

It'd certainly need to be lightweight after its initial negotiation phase, and easy to use; for instance, a special header that maintains the authenticated/secured session info (perhaps KeyCloak could be of some use here?).
Actions
8. Re: API Management: Identity Management

eric.wittmann Jul 11, 2014 8:23 AM (in response to msavy)

Can you explain a little bit more what you mean here? I think one of the things you're addressing is the idea that only the Gateway should be allowed to access the back-end services. If the applications try to go direct to the services they shouldn't be allowed to do so. I agree we should consider what Policies we might be able to implement to support this. Digital signatures come to mind here - we could (for example) create and sign a NONCE in a Policy so that it can be confirmed by the back end service. We could also simply support BASIC authentication, or x509 or something else like that. I think there are a lot of possible solutions.

I'm not clear on what else you are discussing here though, regarding pushing gateway logic into applications... can you clarify that point?
Actions
9. Re: API Management: Identity Management

msavy Jul 11, 2014 9:53 AM (in response to eric.wittmann)

I think I explained this very badly, but you got to the core of it. I'll try to explain it a bit more clearly (I kept saying 'client' when I meant 'service'): the user of APIMan may wish to ensure only the gateway can access the services and vice-versa, i.e: The gateway and services mutually establish identity and authenticity, and make it easy to ignore 'bypassers'.

There are definitely a whole load of interesting lightweight approaches here, I agree.

My only concern is that certain approaches risk being APIMan-specific in nature and pushing some of our authentication and/or validation logic into the services (where my understanding was that we were trying to remain as transparent as possible).

That's where I was thinking something such as KeyCloak may be attractive; given it provides a whole raft of standardised auth/validation protocols out of the box (where REST is applicable, anyway!).
Actions
10. Re: API Management: Identity Management

msavy Jul 11, 2014 11:37 AM (in response to msavy)

Ah, I see you've already mocked out KeyCloak in a couple of areas :-).
Actions
11. Re: API Management: Identity Management

eric.wittmann Jul 11, 2014 8:00 PM (in response to msavy)

I think KeyCloak has a big future in this space and we need to figure out the various ways we want to leverage it. The two obvious places are:

1) Use KeyCloak as the authentication provider for the APIMan Management UI
2) Use KeyCloak as one of the authentication providers for the Authentication Policy (which provides authentication functionality to services managed by APIMan)

There are other areas, as you point out. One of them is perhaps ensuring that the only valid client of the back-end services is the APIMan Gateway.
Actions

Go to original post