!!! Overview
[{$pagename}] is a [Proxy] which provides [Access Control Service]

An [API-Gateway] is often an [Access Proxy]

!! [BeyondCorp] [{$pagename}] [User] [Authentication]
[{$pagename}] that requires [Digital Identity] [Authentication] is referred to as a [Identity Aware Proxy] ([IAP]) allows [Access Control] by [Digital Identity] and is simpler and safer than [VPN] and is a building block for [BeyondCorp]

In order to properly authorize a request, the [{$pagename}] needs to [Digital Identity] the user and the device's [Digital Identity] making the request. [Authentication] of the [device] poses a number of challenges in a multi-platform [context], which we address in a later section, "Challenges with Multi-Platform Authentication." 

[BeyondCorp]'s [{$pagename}] verifies user identities by integrating with [Google]’s [Identity Provider (IDP)]. Because it isn’t scalable to require back-end services to change their [authentication] mechanisms in order to use the [{$pagename}] mechanism, the [{$pagename}] needs to support a range of [authentication] options: [OpenID Connect], [OAuth], and some custom [protocols].

The [BeyondCorp]'s [{$pagename}] also needs to handle [requests] made without user [credentials], e.g., a software management system attempting to download the latest security updates. In these cases, the [Access Proxy] can disable user [authentication].

When the [{$pagename}] [authenticates] the [user], it strips the [credential] before sending the request to the back end. Doing so is essential for two reasons:
* The back end can’t replay the request (or the [credential]) through the [{$pagename}].
* The [{$pagename}] is transparent to the back ends. As a result, the back ends can implement their own [authentication] flows on top of the [{$pagename}]’s flow, and won’t observe any unexpected [cookies] or [credentials].


!! [BeyondCorp]'s [{$pagename}] [Authorization]
Two design choices drove our implementation of the [authorization] mechanism in a [BeyondCorp] world:
* A centralized [Access Control List] ([ACL]) Engine queryable via [Remote Procedure Calls] ([RPCs])
* A domain specific language to express the [ACLs] that is both readable and extensible ????

Providing [ACL] evaluation as a service enables us to guarantee consistency across multiple front-end gateways (e.g., the [RADIUS] network access control infrastructure, the AP, and [SSH] proxies).

Providing centralized [authorization] has both benefits and drawbacks. On the one hand, an authorizing front end frees [back-end] developers from dealing with the details of [authorization] by promoting consistency and a centralized [Policy Enforcement Point]. 

On the other hand, the proxy might not be able to enforce fine-grained policies that are better handled at the [back-end] (e.g., user "A is authorized to modify resource B").

In our experience, combining coarse-grained, centralized [authorization] at the AP with fine-grained authorization at the [back-end] provides the best of both worlds. This approach doesn't result in much duplication of effort, since the [application]-specific fine-grained policies tend to be largely orthogonal to the enterprise-wide policies enforced by the front-end infrastructure.

!! Category
%%category [BeyondCorp]%%

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]