UAA 2.4.1 Release Notes

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

UAA 2.4.0 Release Notes

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

Hotfix

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.

UAA 2.3.1 Release Notes

Features

• Added CSRF checks for form submits in UAA eb40d76
• Improved unit testing speed for MockMvc tests a6109f1
• Added DB index to users.email and not using LOWER function for MySQL (introduced the database.caseinsensitive variable) 781fba0
• Updated README to include information on how to run UAA standalone as a CF app 32955a1
• 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. 7b58aac
• Upgraded to MariaDB 1.1.8 JDBC driver 574eae0
• Sample SAML Sign key has 10 year expiry 7c7a82c

Bug Fixes

• uaa doesn't update the correct client ee06e1e

UAA 2.3.0 Release Notes

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

UAA 2.2.6 Release Notes

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

UAA 2.2.5 Release Notes

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.

UAA 2.2.4 Release Notes

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.

UAA 2.1.0 Release Notes

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

UAA 2.0 Release Notes

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.