Heh. Though I am not an expert on the topic, I can recommend a few things. First, there are three directions the industry is heading with "zero trust" thing.
(1) Zero trust access (like BeyondCorp, protects application and services when a user, user credentials, user devices are compromised)
(2) Network micro-segmentation (contain impact when one network segment is compromised, dynamic network assignment)
(3) Zero trust browsing (protection for users from getting infected with malicious contents served by trusted but compromised websites)
Honestly, I am only more familiar with zero trust access, and for this, I can recommend you first read -> BeyondCorp A New Approach to Enterprise Security [0] by Google. The trend was kickstarted from that paper
You are correct. The solution presented is not a BeyondCorp but rather an SSO implementation that adds authentication to the internal application.
For BeyondCorp, it essentially:
* Must be Layer 7 protocol, access privilege aware (achieved by an identity-aware access proxy).
* Promotes authorization as opposed to authentication only.
* Should be able to enforce security policies (time, location, context, 2fa).
* Must be aware of the security state of the user device.
Shameless plug: Check out our zero trust service access project TRASA (https://github.com/seknox/trasa). It's free and opensource and addresses many of the requirements outlined by BeyondCorp.
Since you mentioned you're a contributor to a similar project, I invite you to check our recently released zero trust service access control solution: https://github.com/seknox/trasa
It's a BeyondCorp like a user identity and layer 7 aware access proxy for RDP, SSH, Web, and Database protocols with privileged access management, native two-factor auth agents, and device trust policies.
Disclaimer: I am a core maintainer of this project.
Since you mentioned AWS, in a typical AWS organization, you will have services which fall into two categories; 1) external services that are used by your customers (let's say a web application) and 2) internal services that are used by your internal team, i.e., developers, DevOps team, administrators (let's say SSH, RDP, database, hosted GitLab). Most probably, you are protecting customer-facing services with web application firewalls, DDOS prevention. But how do you safeguard access to internal services?
Weak access to internal services are often overlooked and are one of the primary vectors of system compromise and data breach. With features such as agentless two-factor authentication, privilege access security(protecting keys to your kingdom), device authentication (verify user devices along with passwords), TRASA ensures that access to internal services is well protected.
TRASA compliments systems like Keycloak with additional security features, and you should use both; Keycloak to manage user and service identities and TRASA to ensure that those identities are not misused, compromised credentials do not lead to data breach and achieve compliance.
Think of Keycloak as human resource admin, which enrolls an employee and applications in an organization, and assign them a badge for security clearance to access those applications. TRASA is a system that polices misuse of their security clearance (malicious insider) and protects applications and services from compromised accounts threats (stolen credentials).
TRASA is a unified access control project with identity-aware access proxy, privileged access management, two-factor authentication, device trust, and access policy features that enable secure remote access to Web, SSH, RDP, and Database services.
It's an opensource and self-hostable alternative to Duo Beyond, Cloudflare Access, Okta Access, and other similar services.
Disclosure: I am one of the core contributors to this project.