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
Access Proxy
Access Proxy

Version management

Difference between version and

At line 1 added 38 lines
!!! 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' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop