This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
API-Gateway
API-Gateway

Version management

Difference between version and

At line 1 added 73 lines
!!! Overview[1]
An [{$pagename}] is a [Proxy Server] built on the [facade pattern] that is the single entry point into the system.
[{$pagename}] is an [Access Proxy] and typically an [Identity Aware Proxy]
[API]-Gateway is similar to the Facade pattern from [object-oriented] design. The [{$pagename}] encapsulates the internal system architecture and provides an [API] that is tailored to each client type.
An [{$pagename}] might have other responsibilities such as [authentication], [monitoring], load balancing, caching, request shaping and management, and static response handling.
!! [Microservices]
For [Microservices] publication, a [Microservices] [{$pagename}] provides a static address for [end-User], and dynamically route requests to the appropriate service address. In addition, providing [authentication] and often [TLS] termination for security are typical considerations in exposing a service to other [End-Users].
!! [{$pagename}] [Architecture]
The following diagram shows how an [{$pagename}] typically fits into the [Architecture]:
[{Image src='API-Gateway/api-gate-way-arch.png' caption='API Gateway Architecture' align=left style='font-size: 120%}]\\
!! [API Service Delivery] [2]
[{$pagename}] is where the [API Service Delivery] happens as it is the component responsible for exposing the organization’s [APIs] to the [Consumer of services] (which can of course be internal or external).
In brief, the [{$pagename}] covers the following key areas (for a detailed discussion of the capabilities of the API Gateway please refer to our previous blog post on the subject.):
* Manifestation - Exposes the organization’s APIs to the outside world, acting like a proxy to route requests from external consumers to the [API] itself (as an aside, many API management solutions can also support backendless APIs, implementing the entirety of the API on the Gateway itself
* [Security] - is the a [Policy Enforcement Point] for the [API], applying [Access Control Models] on behalf of the [API]. Applying [Access Control] at this outer perimeter is consistent with the cyber security principle of “defensive in depth” and is an important feature of the [{$pagename}]’s capabilities
* Entitlement - Allows access to [APIs] at the agreed upon rates and either limiting or managing traffic;
* Standardization - Presents a uniform suite of [APIs] to consumers (according to any [API] standards an organization might have);
* [Logging] and [Metrics] capture - Captures the information required to understand [API] utilization.
In order to expose, secure, and manage an organization’s APIs the [{$pagename}] clearly needs to be in collaboration with the [API Registry], ingesting information about the [APIs] and how they should be exposed. The [{$pagename}] should also establish a feedback loop, supplying the [API Registry] with management-level [metrics] on API utilization, in order to help maintain an accurate picture of how the organizations [APIs] are used and thus their relative importance for future capacity and investment decisions.
Finally, [metrics] captured by the [{$pagename}] should be available for ingestion by any other system that requires it, for purposes such as [monitoring], [monetization], [Metric Analysis].
Generally, [{$pagename}] is a [Policy Enforcement Point] which uses [Policy Based Management System] typically using a [Identity Provider (IDP)] for [Authentication] and a the [Policy Decision Point] to determine [Authorization] to a resource.
Most modern [{$pagename}] utilize a form of [OAuth 2.0] for determining [Access Control]
\\ [API Gateway.png].
\\
!! [{$pagename}], [OAuth 2.0], [OpenID Connect], [Microservices][3]
[KuppingerCole] implies that Real-life deployment patterns can be complex:
* [{$pagename}] patterns depend on integrations with [Container] orchestration platforms like [Kubernetes], cloud [PaaS] platforms like [Cloud Foundry], [serverless] computing platforms like [AWS Lambda], etc.
* API gateways offer extensive support for identity federation, SSO, token transformation (SAML to JWT, etc.) and provide integrations with popular IAM platforms
* Choosing the right [{$pagename}] solution may be the most important decision for your [microservices]-based project
* You must think beyond [security] and [Access Control]. [Monitoring], [Metrics] and [Governance] are equally crucial.
This diagram shows an [example] of an architecture for guarding [Personally Identifiable Information] ([PII]):
[API-Gateway/OAuth_diagrams-04-768x1065.png]
Let’s assume that the [OAuth Client] already has an [Authorization Code] and is acting on behalf of [Alice]. The [OAuth Client] is issued an [access_token] using its [Authorization Code], [client_id] & [Client Secret], typically. The client then makes a business [API] call with the [access_token]. The [Resource Server], typically an [{$pagename}] acting as an intermediary for the Business Service, validates the [access_token] against the [Authorization Server]. The [OAuth 2.0] [Authorization Server] may return attributes about [Alice] to the [{$pagename}]. Once verified, the Gateway brokers the business [API] call.
[OAuth 2.0] uses the term [Authorization Server] to describe the role of an actor in the various [OAuth 2.0 Protocol Flows] that [authenticates] the [Digital Identity] of the [Resource Owner], and issues and validates [tokens] for the [API] Clients. While the [Authorization Server] can perform some [authorization] tasks, let’s assume for this article that the [Authorization Server] just issues [tokens] and provides [context]. We will go into the various scenarios where the [Authorization Server] may play a bigger role in the next portion of this series. [XACML] terms will be used to describe the various components of the “Externalized Dynamic Authorization service”.
[OpenID Connect] like [OAuth 2.0], does not however, define how [authorization] decisions are to be made. The [context] provided by the [id_token] and [Userinfo_endpoint] can be used by the [Policy Enforcement Point] to formulate a request to a Externalized [Dynamic Authorization Management] systems.
The [Resource Server] can act as the [Policy Decision Point] for binary [authorization] decisions. The OAuth [Authorization Server] can pull [OAuth Scope] from the [Policy Decision Point] and include within [access_token], once approved by the [Resource Owner]. [OAuth 2.0] provides [authentication] and [contextual] [attributes] that can leveraged in policy decisions in both cases. While [OAuth 2.0] and [OpenID Connect] also provide [authorization] capabilities, there may still be a case for supplementing with a more Externalized [Dynamic Authorization Management] service.
!! Scalable [Microservices|Microservice] with the [Phantom Token Flow]
[Token Service Provider] enables consistent security across [Microservices|Microservice]. Each [microservice] expects an [Access Token] in [JSON Web Token] ([JWT]) Format. On the [Internet] [Opaque tokens] are used and traded for [JWTs] in the [{$pagename}] or the Ingress Service for internal use. Keeping the information safe, whilst ensuring access internally.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Using an API Gateway|https://www.nginx.com/blog/building-microservices-using-an-api-gateway//|target='_blank'] - based on information obtained 2016-02-25
* [#2] - [The Core Principles of API Management|http://nordicapis.com/core-principles-api-management/|target='_blank'] - based on information obtained 2016-12-19
* [#3] - [OAuth and OpenID Connect Come Together with Externalized Dynamic Authorization|https://www.axiomatics.com/blog/externalized-dynamic-authorization-in-a-micro-services-world/|target='_blank'] - based on information obtained 2016-12-19
* [#4] - [Scalable Microservices with the Phantom Token Flow|https://curity.io/product/token-service/|target='_blank'] - based on information obtained 2020-10-06
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop