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:
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.