Cloud Foundry User Account and Authentication (UAA) is an open-source identity server project under the Cloud Foundry Foundation.
UAA provides enterprise-scale identity management features. It is used by these commercial services, for example:
Single sign-on for VMware Tanzu: Identity services for apps and APIs running on VMware Tanzu Application Service (TAS for VMs)
UAA provides identity-based security for apps and APIs. It supports open standards for authentication and authorization, including:
The major features of UAA include:
The diagram below illustrates the architecture of UAA:
The table below describes the protocols UAA can use:
Protocol | Purpose | Profiles |
---|---|---|
OAuth 2.0 | Authorizes apps and APIs | Authorization Server, Relying Party |
OpenID Connect 1.0 | Federates to external identity providers (IDPs) and acts as an IDP for SSO | Identity Provider, Relying Party |
SAML 2.0 | Federates to external IDPs | Service Provider |
LDAP | Authenticates users in external user store | LDAP Client |
SCIM 1.0 | Manages users and groups | Identity Provisioning |
The table below describes the client-side tools and libraries UAA uses:
Name | Language |
---|---|
UAAC CF-UAA-LIB |
Ruby |
Spring Security OAuth | Java |
CF Java Client | Java |
UAA Javascript SDK (Singular) | JS |
TAS for VMs relies on UAA for identity and access management requirements. UAA secures user and system access to TAS for VMs installations.
Since TAS for VMs is primarily used in the enterprise context, UAA supports enterprise SSO workflows. If a user has already authenticated against the enterprise IDP, they can access TAS for VMs without re-entering credentials.
Some of the major components of TAS for VMs that use UAA include:
Each of these components expose APIs for user and system interaction. UAA uses OAuth to secure the APIs exposed by core TAS for VMs components.
UAA secures many different TAS for VMs components, including:
After authenticating, client apps access resources and services using tokens rather than account authentication credentials. UAA generates, manages, distributes, and validates these tokens. UAA provides new tokens only to client apps with valid authentication credentials.
Once granted, token validity is unchallenged until the token expires due to timeout.
UAA distributes two types of tokens: access tokens and refresh tokens.
Client apps use UAA-provided access tokens to request access to API endpoints, resources, and services. The access token presented by a client app must be valid in order to access a resource.
Access tokens are valid for a short period of time.
After a UAA-provided access token has expired, a client app can request UAA provide a replacement. To request a replacement access token from UAA, a client app must present a valid refresh token.
Client apps use UAA-provided refresh tokens to request replacements for expired access tokens. The refresh token presented by a client app must be valid in order to replace an expired access token.
Refresh tokens are valid for a long period of time.
UAA does not provide replacement refresh tokens. To obtain a new refresh token, a client app must re-authenticate.
The token interactions listed above produce certain end results.
Authenticated client apps are running and interacting with services using tokens, not the service account’s authentication. An admin can revoke a service account’s access and privileges, but a client app running under that service account can continue to interact with the environment, unchallenged, as long as its token is valid. Therefore:
The access token timeout is the maximum period during which an already running app can continue to access services after an admin has revoked privileges from the service account the app is running under.
The refresh token timeout is the maximum period during which a client app can access services without re-authentication.
The default access and refresh token timeout values are the UAA token timeout values VMware recommends. Before altering token timeout settings, consider:
Short default token timeout periods create overhead within your system.
Setting a short token timeout period, such as 0
, can render all associated services and resources inaccessible.
Long timeout periods represent a security risk.
Setting a long timeout period, such as one lasting days, can result in a client app running unchallenged for days.