Identity and Access Considerations for Public & Private Clouds
Srinandan Sridhar
Sarthak Ganguly
Solutions Engineer, Google Maps Platform
APIs are everywhere. With organizations of all sizes connecting their customers, partners, and developers through APIs, identity and access management becomes a key consideration. But different use cases have different requirements.
Some organizations rely on SAML, while others might employ OAuth, OpenID Connect (OIDC), or JSON Web Tokens (JWT).
Apigee’s API platform, which can be deployed as a private cloud in a customer’s own data centers or can be leveraged from the Apigee Cloud, incorporates several different components, each with different security capabilities:
- Apigee Edge admin UI The admin UI used by API team.
- Apigee Developer Portal The web portal to expose your APIs, educate developers about your APIs, sign up developers, and let developers register apps.
- Apigee Management API Used primarily for CI/CD processes
- Apigee runtime APIs These are the customer APIs proxied by Apigee Edge
Enabling SSO for users logging in to Apigee Edge
Many enterprises need to support single sign on (SSO) for their employees to log in to vendor applications. The SSO providers are typically connected to the enterprise directory services, so that they’re kept in sync when employees join or leave the organization.
How SSO can be enabled on different Apigee components
* Direct LDAP connectivity from Apigee Edge is not supported for Apigee public cloud. It’s generally considered a security risk to expose LDAP services over the internet, so Apigee recommends a SAML SSO provider (like Okta, Ping Identity, or SiteMinder, for example) for integration.
Leveraging Apigee to implement OAuth for APIs
OAuth has become the de facto standard for securing APIs. Apigee Edge provides a fully compliant OAuth 2.0 authorization server (AS). Apigee Edge also acts as a resource server.In addition to managing the lifecycle of access tokens (generate, expire, and revoke), Apigee Edge also provides the ability to manage application credentials (client IDs and secrets).
Users can generate (and rotate) client IDs, set expirations, and revoke and approve access to APIs.
There are several capabilities provided for OAuth across public, private, and hybrid cloud scenarios. Microgateway is a lightweight gateway which can be deployed within a trusted network in close proximity to back-end target services.
This helps to achieve a hybrid deployment model by leveraging the Apigee Cloud for all public APIs and managing private APIs using the microgateway, while maintaining a single point of control.
Capabilities provided for OAuth across public, private, and hybrid cloud scenarios
Access an external identity provider for APIs
API access often requires integration with identity providers for authentication (and sometimes authorization) of users. As part of an OAuth flow (Auth code, password, or implicit grant types), Edge often needs to integrate with external identity providers.Edge comes with an OAuth authorization server and requires the user to integrate with an existing identity provider. For example, before completing an “auth code” or “password” grant OAuth flow, the user (the resource owner) must be authenticated against an identity provider.
There are multiple ways for Apigee Edge to integrate with an external identity provider. The first step is to establish a trusted and secure communication between Apigee Edge and the identity provider.
This is generally achieved using mutual trasnport layer security (TLS). The second step is for the identity provider to communicate the identity of the end-user in a trusted format. This trusted format is generally a SAML assertion or a JWT claim, signed by he identity provider. Apigee Edge has the public key to verify the assertion or claim, then extract the identity from the identity token.
Apigee can integrate with external identity providers (like Okta, Ping Identity, CA SiteMinder, and Active Directory, for example) for user authentication via one of the following options:
- A signed token (SAML or JWT) containing the identity assertion, issued by the identity provider Apigee validates the token and extracts the identity.
- An API call If mutual trust can be established between the identity provider and Apigee Edge (two-way TLS, for example), then Apigee can make a REST/API call to the identity provider for authentication.
- Custom libraries If the identity provider provides custom libraries in Java or JavaScript, then those libraries can be leveraged to communicate with the identity provider within Apigee.
- LDAP Apigee can communicate with identity providers directly via LDAPs.
Leverage external OAuth authorization server for APIs
Some enterprises already have an OAuth AS, like Active Directory Federation Services (ADFS) or Okta. These businesses might want to continue to leverage these authorization servers with Apigee Edge.Apigee Edge supports a couple of integration patterns that involve an external AS.
In the first pattern, the external AS also acts as the identity provider. Apigee Edge acts only as the resource server. Access token generation and life cycle management is performed by the AS. Client IDs and secrets are managed by the AS.
The advantages of this integration pattern include:
- Token (web and API) lifecycle management happens in a centralized AS
- Integration with existing solutions
- Performance impact (gateway makes sideways calls to validate token for each API call)
- Requires developer portal customization; the application registration process (a developer portal capability) must integrate with the external AS.
- Does not work with Apigee API products.
- Loss of application-based analytics; Apigee analytics is based on client ID, and because this is managed/maintained only externally, analytics will be limited.
- Functionality of out-of-the-box developer and app lifecycle management is restricted.
Access token generation and lifecycle management is handled by the external AS and Apigee. Client IDs and secrets are managed by the external AS and a copy is imported into and stored in Edge.
The advantages of this integration pattern include:
- Performance (No sideway calls to validate tokens)
- Integrates with existing solutions/landscape
- No loss of functionality from Apigee.
- Developer portal customization is required
- Token lifecycle is required in Apigee and the external AS
Implement lightweight security
Apigee manages API programs of all sizes and of all kinds of enterprises. In some cases API programs are run by small teams inside large organizations. In other cases, the platform might belong to startups or small and medium-sized businesses. In these cases, if the data isn’t very sensitive, customers might initially want to adopt a lightweight security model to get the API program rolling.Customers can start implementing basic authentication or API key-based security mechanisms on the runtime. The out-of-the-box username:password mechanism for developers to log into developer portals or for an API team to log into the management UI/APIs makes it easy to get started. This enables customers to rapidly launch their API program and add advanced security features later on.
Apigee is widely used by organizations of all sizes, with a variety of security requirements, so the platform has evolved to provide a wide variety of choices and options. Our documentation contains a wealth of details on the topics covered in this post, including using OAuth with the Apigee Edge management UI, enabling SAML authentication for Edge, configuring TLS on Edge
https://docs.apigee.com/api-platform/system-administration/ssl
, and defining user roles.
