Releases: cloudfoundry/uaa
UAA 3.3.0.4 - Security Release (CVE-2016-5007)
This is a security release which addresses CVE-2016-5007 Spring Security / MVC Path Matching Inconsistency
This following dependencies have been updated
- Spring Security 4.1.1
- Spring Framework 4.3.1
- Spring Security Oauth 2.0.10
- Spring Security LDAP 2.1.0
- Spring Security SAML 1.0.2
- Apache Tomcat 8.0.36
- Apache Tomcat jdbc-pool 7.0.70
UAA 3.6.0 Release Notes
This is a security release which addresses CVE-2016-5007 Spring Security / MVC Path Matching Inconsistency
This following dependencies have been updated
- Spring Security 4.1.1
- Spring Framework 4.3.1
- Spring Security Oauth 2.0.10
- Spring Security LDAP 2.1.0
- Spring Security SAML 1.0.2
- Apache Tomcat 8.0.36
- Apache Tomcat jdbc-pool 7.0.70
UAA 3.5.0 Release Notes
IMPORTANT: Deprecation Notice
This releases marks the deprecation of the UAA properties listed here
Please make sure that you have update your UAA & LOGIN YAML configurations accordingly.
New Features
- UI Templates utf-8 support
- Add interface UaaTokenEnhancer
- Introduce new refresh token grant type restriction
- Introduce the mechanism for scope-based user approval of refresh token grant
- Allow disabling shadow user creation at the time of authentication for ldap and oauth/oidc
- Bootstrap UAA system scopes in all identity zones by default
- Allow setting of mail.smtp.auth and mail.smtp.starttls.enable props
- Prohibit ScimUsers from entering more than one email address in the API
- Upgrade to Flyway 4.0
- User account locked error is not propagated to CF CLI
- Allow users to be updated without the need to specify a password in the manifest
- Password endpoints should allow uaa.admin to access them
Bug Fixes
- clients.admin can't change client secret
- Fix refresh of service providers for non-default zones.
- Updating user with empty email puts the account in invalid state
- Setting autoapprove to true with the /check_token endpoint doesn't work with autoapprove list
- External login server users should throw error if origin is uaa
- Inconsistent UAA user experience in case of invalid route and wildcard route mapping
- Entity base url always populated by replacing uaa. with login.
- Erbs populating invalid saml metadata
- Ldap properties not there in yaml file after refactor
- scopes with prefix uaa. do not show up on app approvals page
- Test multiple LDAP Servers with UAA
- UAA fails to start up if there are line breaks in the product logo or the square logo
- Invitations endpoint should return an invalid email in the "failed invites" array
- Where to? page not showing applications for Identity Zones
-External Identity Providers issuer validation issue - Setting autoapprove to true via client api does not work
- Suppress the Login Prompts in Info endpoint if Internal Auth and LDAP Auth are disabled.
- Setting phoneNumber to null on ScimUser causes deserialization issues
- 500 error for invalid request
UAA 3.4.2 - Security Release (CVE-2016-5016)
This is a security release which addresses CVE-2016-5016 UAA Accepts Expired Certificates
UAA 3.3.0.3 - Security Release (CVE-2016-5016)
This is a security release which addresses CVE-2016-5016 UAA Accepts Expired Certificates
UAA 2.7.4.5 - DO NOT USE
Please use UAA 2.7.4.6 instead for CVE-2016-5016 UAA Accepts Expired Certificates
UAA 3.4.1 - Security Release (CVE-2016-4468)
This is a security release which addresses CVE-2016-4468 UAA SQL Injection
UAA 3.3.0.2 - Security Release (CVE-2016-4468)
This is a security release which addresses CVE-2016-4468 UAA SQL Injection
UAA 2.7.4.4 - Security Release (CVE-2016-4468)
This is a security release which addresses CVE-2016-4468 UAA SQL Injection
UAA 3.4.0 Release Notes
New Features
Permanent home for API Docs @ http://docs.cloudfoundry.org/api/uaa/
Identity Provider Discovery
UAA now supports Identity Provider discovery when multiple SAML or OpenID Connect Identity Providers are enabled for any given Identity Zone. The right identity provider is discovered based on the email domain associated with the provider. The login experience has been updated to prompt the user for the email based on which the right identity provider is discovered and the user is redirected to the same.
The discovery flow can also be used for OAuth Clients which are associated with more than one allowed providers. The OAuth enabled application can also send a login hint containing the email domain so that the right Identity Provider can be discovered without the user having to enter the email address on the login page.
In order to enable IDP discovery for the default zone , you can set the property below.
login.idpDiscoveryEnabled:
description: "IDP Discovery should be set to true if you have configured more than one identity provider for UAA. The discovery relies on email domain being set for each additional provider"
default: false
For other identity zones, this property can be updated via the Identity Zone API. The property is config.idpDiscoveryEnabled and the default is false.
Related Stories
- Redirect to IDP Discovery Login Page if IDP Discovery is enabled
- Support login_hint as specified in the OpenID Spec
- https://www.pivotaltracker.com/story/show/118684341
- Zonify idp discovery
Other minor features
- Support MySQL 5.5.7
- Optimize authz authentication query
- Support Allowed Providers Policy for External OIDC Provider per OAuth Client
- Implement invitation acceptance flow with external OIDC provider
- Remove need for admin to have old client secret in order to change the password
Bugs Fixes
- Email should not exposed on any UAA URL's
- Restrict the One Time Code usage depending on the user flow
- Unable to call /oauth/token/revoke using opaque token
- password prompt now says "Email>"
- Include timestamp on response from client create
- Zone Name not displayed under the Password entry page for IDP Discovery
- /Groups/External null pointer exception on trim()
- Fix is user token condition
- Support chinese characters in LDAP user name
- Incorrect error message during client credentials