uaa

Backwards Compatibility for ID_Token Response

During the invocation of the /oauth/authorize URL, the normal process is to specify response_type=code
Some libraries have been specifying response_type=code+id_token
This is a OpenID Connect extension. Previously the UAA ignored the id_token response_type, but now we have added support. This changes the response of the /oauth/authorize. The main change is that the Location header will have a Fragment (#) and not a Query String (?)

This is a hot-fix release which addresses the backwards compatibility issue with handling of id_token in response.
The properties is exposed in the UAA YML:
oauth:
id_token:
disable:

Features

• Support for OpenID hybrid flow code + id_token response type
• Add the ability to disable authenticating against internal user store
• Filter the user results from the ids/users endpoint based on active identity providers
• Expose Logout Redirect URI per client

Bug Fixes

• CORS filter blocks same origin requests

Non-Browser Authorization Code Flow Support

Authorize endpoint now supports token based authentication in addition to the regular web based authentication flow. API Details can be found here

Features

• Moved UAA to Java 8 only support
• Work in Progress - Support for Allowed Domains on Identity Providers to enable discovery
  • Associate an Identity Provider with One or More allowed domains via YML/Manifest
  • Allow one or more email domains to be associated with an Identity provider via API
• Enable log rotation for UAA Logs via Bosh
• Respect nonce authorization
• Added origin in JWT token and refresh token.
• New "token_keys" endpoint (JWKS Set Format)

Bug Fixes

• Users who haven't modified their password see the sad cloud page after login.
• Inviting an existing user causes "Uh oh Something went amiss"
• Zone users can't see the groups they create
• Reject duplicate entityID when creating SAML providers
• Migration logic to zonefied groups

Features

• Added multi-tenant support for scim groups, group memberships and external group mappings
  • SCIM Groups should be zone aware
• Enable scopes for finer grained administration of Identity Providers, Users, Groups & Clients in an Identity Zone
  • Expose new scope for reading identity providers in a zone
  • Add finer grained scope for reading a single identity zone
  • Extend /Groups/zones endpoint to allow zone management scopes
  • Add an endpoint for deleting members from zone management groups.
• Support for email notifications to be sent out via the notification service for user creation, password management & account management for users in an identity zone.
  • Use the emails endpoint for sending all UAA email notifications
• Modified CORS filter so that allowed headers for XHR requests is configurable

Bug Fixes

• When creating a Zone specific User Account, Pivotal ID Branding is being displayed
• Email for Zone Specific Create Account shows Pivotal ID wording and branding
• Invitations flow requires a user to be logged in when accepting invite

Features

• Update the Identity Provider End Point to save and retrieve Lockout policy per zone
• Show relevant message after user lockout
• Updated SAML identity provider configuration to accept an addShadowUser property to govern shadow account creating during SAML Authentication
• Expose Managing /Users & /Groups to a Zone Admin
• New Scope for Creating Clients in a Zone
• Allow to build uaa with Java 8

Bug Fixes

• UAADB Housekeeping: Clean up unused/expired oauth_codes and one time passcodes
• Querying users with pagination will return duplicate users
• Serialization/deserialization issues of Java Objects stored in UAADB

Features

• Bootstrap password policy under default UAA Zone
• Enforce password policy for default zone on a reset password and change password request
• Expire User password after X months
• Expose Managing (Add/Update/Read) password policy for the Identity Zone
• Revert default password policies to lenient for UAA Zone and other Identity Zones
• Password History: New Password should not be the same as Old Password
• Adjust cf-release password policy config

Bug Fixes

• Restarting the UAA invalidates all tokens
• New Account created for an exiting user logging in via Passcode into CF CLI
• Create Account (both default and identity zone)not functional when Require_HTPS is turned on
• uaac client is not able to set "autoapprove true" for client ids
• Remove Pivotal references from OSS login server style
• uaac target results "invalid status response: 404"
• Turning on password validation breaks shadow user creation
• Zone Specific Self Service Links not functional if custom create account /reset password link is specified in the YML file
• Leading & Trailing Whitespace Characters in Group DN should be truncated during mapping/unmapping of Groups()
• SAML SP metadata generation produces incorrect ID attribute in multi-tenant scenarios
• Missing indexes for lower(id) on users table on postgresql

2.3.1 added in the ability to revoke a token if a client secret changed, or a user password changed.
When the UAA restarts, it was regenerating the hash to bootstrapped (defined in uaa.yml) users and clients, thus a restart automatically revoked tokens. This has been fixed.

Features

• Added CSRF checks for form submits in UAA eb40d76d104289cb48931214ace407f722ecc44d
• Improved unit testing speed for MockMvc tests a6109f14bf945486d38b2c65b956b90da871a881
• Added DB index to users.email and not using LOWER function for MySQL (introduced the database.caseinsensitive variable) 781fba0fb749617f4354b8a84e48b18a745474b4
• Updated README to include information on how to run UAA standalone as a CF app 32955a10f2e1bfaa4eade6f09daa3fea79697c7b
• Implement a revokable, stateless token strategies. Token can be manually revoked for a client or a user, and are automatically revoked if user's email,username or password changes. Tokens for a client are automatically revoked if the client's secret changes. 7b58aacc6e8ffd689f1b894d25fabc23c8ab1a92
• Upgraded to MariaDB 1.1.8 JDBC driver 574eae09a8de234e90067d8035c888d7b9f2ffdb
• Sample SAML Sign key has 10 year expiry 7c7a82cfd3b4b164b5d5178aa25492037db63908

Bug Fixes

• uaa doesn't update the correct client ee06e1e03e37e1a7ef81513b6f76a127554e89b8

Features

• Updated Spring Versions:
  Spring 4.1.6.RELEASE,
  Spring Security 4.0.1.RELEASE,
  Spring Security OAuth 2.0.7.RELEASE,
  Apache Tomcat tomcat-jdbc artifact 7.0.61
• Both LDAP and internal user store authentication should be allowed to be set in an enabled state in an Identity Zone
• Hide Create Account and Reset Password link if client is not associated with internal user store authentication

Features

• More lenient SAML metadata in XML format
• Improve internalHostname's configuration
• Expose new UAA properties through CF release

Bug Fixes

• The User Approvals page doesn't displays the OAuth Client Guid instead of the Application Name
• Move new uaa java sources under common subproject

Features

• As an End User I should be able to perform an LDAP login into an Identity Zone
• As a developer I should be able to create the LDAP Provider configuration in an Identity Zone via protected API
• As a developer I should be able to update a LDAP provider in an Identity Zone via Protected API
• As an End User I can login when the LDAP connection is over SSL with self signed cert
• Perform LDAP validation before saving the LDAP Configuration
• The approval authorization page should display the Client Name if available
• Enforce Client-IDP relationship for Password grant
• API for creating a limited client in an identity zone via identity client credentials
• Added documentation for sample apps for each OAuth grant types: Authorization Code, Password, Implicit, Client Credentials
• Add an optional parameter to /identity-providers GET to filter out disabled Identity Providers
• Add last modified field for OAuth Clients

Bug Fixes

• RedirectUri's that include fragments throw IllegalArgumentException
• KeyUri in spring-cloud-security fails when token_key is protected
• Client autoapprove should be configurable via the API
• Bootstrap of internal user store in 'uaa' zone inconsistent with the /identity-zones endpoint
• System property java.util.logging.config.file is evaluated wrong
• SAML IDPs that have been disabled are visible
• Redirect to Sample App not working after completion of a SAML authentication
• Not able to view Git commit metadata for the UAA release on the login page.

Features

• As an End User I should be able to perform an LDAP login into an Identity Zone
• As a developer I should be able to create the LDAP Provider configuration in an Identity Zone via protected API
• As a developer I should be able to update a LDAP provider in an Identity Zone via Protected API
• As an End User I can login when the LDAP connection is over SSL with self signed cert
• Perform LDAP validation before saving the LDAP Configuration
• The approval authorization page should display the Client Name if available
• Enforce Client-IDP relationship for Password grant
• API for creating a limited client in an identity zone via identity client credentials

Bug Fixes
Client autoapprove should be configurable via the API
Bootstrap of internal user store in 'uaa' zone inconsistent with the /identity-zones endpoint
System property java.util.logging.config.file is evaluated wrong
SAML IDPs that have been disabled are visible
Redirect to Sample App not working after completion of a SAML authentication
Not able to view Git commit metadata for the UAA release on the login page.

Multi-tenant UAA
This release adds the much awaited support for UAA Multi-tenancy. A Tenant in your System could map to an entire Organization, Business unit or Geographical Location, Employees or Consumers, Development or Production Environments. In UAA multi-tenancy is achieved via the concept of Identity Zones. Each Identity Zone is representative of a Tenant and is accessible via an unique sub-domain.

Multi-Tenancy allows for segregation of User Store, Identity Providers, OAuth Clients etc. Existing UAA End Points for SCIM, OAuth Client Management can now be accessed in a multi-tenant fashion by using the right Identity Zone subdomain as part of the access URI.

This release is fully backwards compatible. All of the bootstrapped configuration from login.yml and uaa.yml becomes part of the Default UAA Zone. Accessing the UAA URL without any subdomain connects to the default UAA Identity Zone.

Documentation
New API end point for managing Identity Zones
Adding Limited Clients in an Identity Zone
New API end point for managing Identity Providers

Login Server and UAA Merger
This release introduces the merger of Login Server and UAA into a single project. The main benefits and impact of this merger are explained below:

Benefits
Simplified Development
The main driver behind the merger is development. The cost of maintaining two separate projects and the HTTP APIs between these two is too high. For each Login Server feature there is usually development required in both projects, implying that a careful version dependency has to be maintained between the two projects.

Flexibility with Test Frameworks
The Spring Framework provides an incredible powerful unit test framework called MockMvc. Allowing a full Spring bean context to be loaded without the need of a Servlet engine. The Login Server is today not enjoying such ability of testing because of its separation from the UAA. The Login Server has to be tested in a running servlet engine in order for HTTP requests to properly propagate. If the login server became a module in the UAA project, MockMvc would become a powerful test driven development tool for the projects team members.

Additional levels of redundancy
In a deployed CF environment, the UAA would enjoy additional levels of redundancy by running the same process in 4 VMs instead of a 2+2 configuration as it is today. For a minimal high availability, we could remove two VMs from the equation thus reducing the footprint of a CF deployment.

Impact
All UAA endpoints (including the endpoints for external login-servers) remain intact.
For time being, the idea is that the UAA would serve both uaa. and login. hostnames to maintain backwards compatibility.

OpenID Connect Updates
We have improved our OpenID Connect support in this release. This includes support for:

• Response type id_token
• Signature verification for id_token

User Sign Up Updates
The user sign up flow (Create Account) has been updated to collect the user's password upfront rather than after the user email verification. This greatly simplifies the user sign up flow. Now post email verification the users are automatically logged in.

Invitations
End users who are authenticated to UAA can now invite others users via email. Invited users are sent an email. After accepting the invitation in the email, the users are allowed to set their password followed by automatically being logged in. This is an optional feature and can be turned on via the invitationsEnabled flag in login.yml

User Verification
The UAA now checks the verified flag when authenticating users if the allowUnverifiedUsers flag is set to false in the uaa.yml. Unverified users are allowed to authenticate successfully by default.

Externalization of Scope Descriptions
The Cloud Foundry specific scope messages can now be controlled via CLOUD_FOUNDRY_CONFIG_PATH/messages in addition to loading them from message.properties of Login Server

This is a hotfix-only release. It adds a flag to the configuration to let OAuth clients that are not allowed the "implicit" grant type to continue to use the hybrid code+id_token OpenID flow from the Authorization endpoint without receiving an error response. This way they can still receive the authorization code and continue with the authorization_code grant flow.

The flag is called fallbackToAuthcode and defaults to false, meaning clients that do not have the ability to do implicit grants will get an unauthorized exception for the whole request.

This release is necessary to provide a workaround to a breaking change in UAA 1.10, which added the provision of the OpenId id_token but locked out clients without the implicit grant in the process.

/ids/Users endpoint protected by a scope

Previously, any valid token was allowed access to translate a username to a id or vice versa. It is now protected by the scim.userids scope. Security is further tightened by checking the scope as well limiting filtering possibilities.

Externalize default scopes

Non UAA scopes, were previously defined in the oauth-endpoints.xml. Client scopes can now be configured in the uaa.yml instead of relying on our XML file.

Refactor /Groups/External APIs

Endpoints that are more RESTful have been added for listing, updating and deleting external group mappings.

Stories Completed
Features
Externalize default scopes
Protect /ids/Users by scope
Refactor API

Scope wildcards
In UAA we now support client scopes to have a wildcard. Imagine this scenario

Client Scopes

• cloud_controller.*

User Joe

• cloud_controller.read
• cloud_controller.write

User Mary

• cloud_controller.read
• cloud_controller.write
• cloud_controller.admin

When respective user requests a token, Joe will receive cloud_controller.read/write and Mary will receive cloud_controller.read/write/admin scopes.

To receive these scopes, the token/authorize request

• may not contain any scopes to receive the default intersection of scopes between client and user
• can include a wild card scope, cloud_controller.*, but it has to match the scope of the client
• can include a specific scope, cloud_controller.read, that matches a user assigned scope

The wildcard matching is very simple. An asterisks, *, character represents a wild card. The wild card will never reach beyond a dot, ., that is considered a scope delimiting character.

For matching examples, take a look at the following tests

• Wild card matching by the UaaAuthorizationRequestManager
• Wildcard to Regular Expression translation
• Token mock tests

Limitations

User scopes may not contain wild cards. In a user scope, a wildcard will not be treated as a special character.

Extract Mail Attribute from LDAP user
A very simple feature has been implemented to extract the LDAP mail attribute from a user's record when a user is authenticated against LDAP
This feature simply looks at the LDAP record, extracts the 'mail' field and picks the first address on file. Currently we have not implemented a more advanced feature to select a specific email address if multiple exist. However, from the authentication, we do get all the email addresses and populate them into the Ldap User Details object.
When the user gets converted to a UAA record, it selects the first email address on file.

Ldap Documentation
Read it now

Gradle

UAA now builds with gradle instead of maven. This simplifies the build process, as one can now build from scratch, and run the uaa, app, and api apps with a simple

./gradlew run

Unit tests can be run with ./gradlew test, and integration tests with ./gradlew integrationTest

War and Jar files can be built with ./gradlew assemble

Tigthen security around /token endpoints
We have tightened security in the /oauth/token endpoint. Previously a token with a scope of oauth.<anything>, essentially having audience=oauth, was allowed to issue tokens without requiring user password or client secrets. We believe this scope is too broad to be allowed. Currently the login-server uses a scope of oauth.login for trusted endpoints, and even then, client_secret is required to issue a password grant token.

Stories Completed
Features
Allow client scopes/authorities to have wildcards
Expand oauth_client_details scope and authorities columns
Extract mail attribute from an LDAP user when user stored in UAA
Group memberships are tracked by origin
Email address is updated each time an LDAP user authenticates
Security tightened around token endpoints
External group map endpoint

Move all LDAP Authentication to UAA
https://github.com/cloudfoundry/uaa/commit/1c400c2eaadb1fb3be54f412ff4a9399feb6a770

Make the UAA multi tenant
Two columns have been added to the UAA.users table

• origin - the source of the users
• external_id - if the user has a unique ID in the other repository, like LDAP DN

This means that the user_id should be used as the identifier for a user, not the username
https://github.com/cloudfoundry/uaa/commit/1a63add4b36f9967d7d7cffe0d2f5fd24be402c7

Implement correct SCIM filtering according to the spec
http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resources
https://github.com/cloudfoundry/uaa/commit/af4860a771eb93cfb1ce53f216e504ea31c8f9b1
Backwards compatibility for filters surrounded with single quotes "userName eq 'marissa'" have been retained

Support for LDAP groups
LDAP Groups can be mapped to scopes as

• group name is the scope name
• group DN maps to a scope(group_id) in the external_group mapping

Nested LDAP groups are supported
https://github.com/cloudfoundry/uaa/commit/e5345127021ccc5d691ba602b14883dc47cc8258

Stories Completed
Bugs
Remove test classes from src/main/java
SCIM Filter should be backwards compatible, support single quote
Change password link should only be available if the user origin=UAA
Username should not be case sensitive
Fix pagination of the SCIM user endpoint
Proper SCIM parsing to support single quotes

Features
Keystone authentication support
LDAP Authentication in CF is part of the UAA job
Move external authentication is part of the UAA instead of Login server
Support multi tenancy for users