Understanding UAAC Clients vs. Users and shadow users in Tanzu Application Service (TAS)

Products

• VMware Tanzu Platform Core

Issue/Introduction

In TAS, both user and client exist within the UAA (User Account and Authentication) server, they serve distinct purposes and have different "rules of engagement."

UAAC User is a human, using username and password credentials and permissions are defined by scope.

UAAC Client is a software service (e.g jenkins-pipeline) which uses Client ID and Secret credential type, and its permissions are defined by authorities.

Environment

TAS/EAR

Cause

UAAC User

Users represent people. They are usually managed via external identity providers like LDAP, SAML, or Okta. You use a User when you are manually running commands in your terminal.

UAAC Client 

Clients are "Service Accounts." They are managed internally by UAA. You use a Client when you want a script, a CI/CD pipeline, or an automated tool to interact with TAS without needing a human to type a password.

 

The setting in TAS tile --> Cloud Controller

Enable Admins and Org Managers to create UAA shadow users
Allow Admins and Org Managers to assign roles to external identity provider users that are not yet known to UAA. Users can be explicitly created users through /v3/users and implicitly through /v3/roles.

Means the system handles the creation of the user record automatically in the background as part of the role assignment. This means that when a setting Enable Admins and Org Managers to create UAA shadow users is enabled in TAS. This allows system to create a record in the UAA for a user which it found in the external identity provider.  For example consider the scenario below.

Resolution

To create a client, you must first authenticate with UAA as an admin, then register the client with specific Authorities.

Create a client as below

uaac target uaa.system.domain.com

uaac token client get admin -s <admin-secret>

uaac client add my-automation-client  --secret "my-secure-secret"  --authorized_grant_types client_credentials --authorities "cloud_controller.read,cloud_controller.write,scim.read"

Even if you are an admin, you must explicitly give the client a role within an Org using the --client flag:

cf set-org-role my-automation-client demo-org OrgManager --client

 

Role vs. Authority

A common mistake is assuming that a Client with cloud_controller.write can do anything. In TAS, permissions are split into two layers:

1. Global Authorities (UAA): Set via uaac. Tells the system what the client is allowed to do (e.g., "Can write to the API").

2. Scoped Roles (Cloud Foundry): Set via cf. Tells the system where the client can do it (e.g., "Only inside demo-org").

 

If your client tries to run cf create-user [email protected], you will likely see a 403 Forbidden. Instead of trying to "create" a user, an Org Manager should simply assign a role. If the user exists in your LDAP/SAML provider, TAS will automatically "shadow" (sync) the user into the org for you.

The create-user command is a Global Admin action. It involves writing a new identity into the global database.

• Admins can create users anywhere.

• Org Managers can only manage users already existing in the system.