Overview#Access Proxy is a Proxy which provides Access Control Service
BeyondCorp Access Proxy User Authentication#Access Proxy 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 Access Proxy 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 Access Proxy 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 Access Proxy mechanism, the Access Proxy needs to support a range of authentication options: OpenID Connect, OAuth, and some custom protocols.
The BeyondCorp's Access Proxy 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.
- The back end can’t replay the request (or the credential) through the Access Proxy.
- The Access Proxy is transparent to the back ends. As a result, the back ends can implement their own authentication flows on top of the Access Proxy’s flow, and won’t observe any unexpected cookies or credentials.
BeyondCorp's Access Proxy 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 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.