Releases: cloudfoundry/uaa
UAA 2.7.4.1 - Hot-fix Release
This release addresses a UAA startup issue for customers using the LDAP user store when they upgrade from UAA 2.X.X to 2.7.4
UAA 3.1.0 Release Notes
Branding & White-labeling
We have introduced properties for branding the UAA UI Pages. The default branding is Cloud Foundry. We have also updated the Cloud Foundry brand to the latest. All Pivotal specific assets & stylesheets have been removed from the UAA repository.
Below is the branding snippet from UAA.yml for setting the branding properties. These properties can be bootstrapped from UAA.yml & UAA Release Manifest (if using the UAA Bosh Release)
branding:
companyName: <Company Name>
productLogo: <Enter base64 Encoded Image>
squareLogo: <Enter base64 Encoded Image>
footerLegalText: <This legal text will show up in the footer.>
footerLinks:
Terms: /exampleTerms
Privacy Agreement: privacy_example.html
Licensing: http://example.com/
Related Stories
- Apply White-Label Logo to all UAA Screens
- Apply White Label Fav Icon to All UAA Pages
- Apply White-Label Footer to All UAA Screens
- Update the Email Templates to use the Company Name from the White - Label Properties
- Update CF branding
Dynamic Home Page for UAA
This release drops support for login.tile
property which has a static list of tiles displayed under the "Where To"page.
We have added the ability for the "Where To" Page in UAA to be created dynamically based on OAuth Clients registered with UAA and configured to be displayed on the home page. This serves as a dynamic SSO Dashboard for all Identity Zones.
New end-points (oauth/clients/meta) have been introduced to set Launch URL, Display Icon and Show On Home Page property. These properties can be bootstrapped from the UAA.yml file & UAA Release Manifest (if using the UAA Bosh Release)
# Clients
uaa.clients:
description: "List of OAuth2 clients that the UAA will be bootstrapped with"
example:
login:
id: <test-client>
name: <display_name>
override: true
secret: some-secret
authorized-grant-types: authorization_code,client_credentials,refresh_token
authorities: test_resource.test_action
scope: test_resource.test_action
redirect-uri: http://myapp.com/oauth
app-launch-url: http://myapp.com
show-on-homepage: true
app-icon: <Enter base64 encoded image>
Related Stories
- Provide the ability to have a Configurable Home Page for UAA
(https://www.pivotaltracker.com/story/show/109742870) - Build the UAA Home Page based on applications with showonHomePage property set to true
- Show Client Name along with Logo on the Where To Page
- oauth/clients/meta needs client name field
Descriptions for SCIM Groups & Identity Providers
We have added support for setting user friendly display names for SCIM groups & Identity Providers. The API's have been updated to support this operation. The behavior earlier was to set the description for SCIM groups aka OAuth Scopes in message.properties file. This can now be bootstrapped from UAA.yml & UAA-Release Manifest (if using the UAA Bosh Release)
Below is a snippet from UAA.yml
scim:
groups:
zones.read: Read identity zones
zones.write: Create and update identity zones
idps.read: Retrieve identity providers
idps.write: Create and update identity providers
clients.admin: Create, modify and delete OAuth clients
clients.write: Create and modify OAuth clients
clients.read: Read information about OAuth clients
clients.secret: Change the password of an OAuth client
Related Stories
- Provide the ability to set and retrieve description for an Identity Provider
- Display scope descriptions from db
- Provide the ability to add & retrieve descriptions for SCIM Groups
- bootstrap all scope descriptions listed in the UAA documentation into UAA DB. Right now only 4 are being bootstrapped
Other Minor Features
- Support Wildcards for OAuth Client Redirect URI
- Hide username/password boxes if internal user store is disabled and there is no ldap provider/ldap provider active.
- Make the IdentityProvider.config a generic
- Introduce a dynamic mechanism to derive which properties are displayed on the home page
Bug Fixes
- Indirect group memberships in a zone are not allowed in tokens
- uaa-release login.yml.erb does not populate the saml private key
- reating duplicate identity provider should return 409 instead of 500
- /Groups/zones should allow creation of zones.zoneid.scim.read/write/create groups
- Deleting a zone doesn't delete the cross zone scopes like zones.{zoneid}..
- Excluding Authorities from a access token cause load configuration error
- LoginInfoEndpoint should return login.url
- /passcode link should be based on entityBaseURL
- LoginInfoEndpoint 'uaa' and 'login' (if local) - should be zonified
- LDAP certificate issue
UAA 3.0.1 - Security Release (CVE-2016-0732)
This is a security release which addresses CVE-2016-0732 Privilege Escalation
UAA 2.7.4 - Security Release (CVE-2016-0732)
This is a security release which addresses CVE-2016-0732 Privilege Escalation
UAA 3.0.0
UAA 3.0.0 introduces breaking changes in form of restructuring of the code base, updating dependencies producing new module libraries.
Objects that are payload entities for rest controllers have been moved to the cloudfoundry-identity-model
module.
The server side modules have been combined into cloudfoundry-identity-server
.
Overview of our modules
- cloudfoundry-identity-model - data objects that are used as arguments for the API controllers on the UAA
- cloudfoundry-identity-client-lib - module to hold future client side API libraries for administering a UAA
- Token retrieval API completed Supplement 1 Supplement 2
- cloudfoundry-identity-server - all server side code
- cloudfoundry-identity-uaa - web application archive, WAR module for the UAA server
List of Deleted Classes
common/src/main/java/org/cloudfoundry/identity/uaa/error/JsonAwareAccessDeniedHandler.java
common/src/main/java/org/cloudfoundry/identity/uaa/error/JsonAwareAuthenticationEntryPoint.java
common/src/main/java/org/cloudfoundry/identity/uaa/login/util/FileLocator.java
common/src/main/java/org/cloudfoundry/identity/uaa/oauth/JitClientDetailsService.java
common/src/main/java/org/cloudfoundry/identity/uaa/oauth/NoSuchTokenException.java
common/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaAuthenticationKeyGenerator.java
common/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaUserTokenConverter.java
common/src/main/java/org/cloudfoundry/identity/uaa/oauth/UserTokenConverter.java
common/src/test/java/org/cloudfoundry/identity/uaa/authentication/login/PromptEditorTests.java
common/src/test/java/org/cloudfoundry/identity/uaa/authentication/login/PromptTests.java
common/src/test/java/org/cloudfoundry/identity/uaa/error/JsonAwareAccessDeniedHandlerTests.java
common/src/test/java/org/cloudfoundry/identity/uaa/error/JsonAwareAuthenticationEntryPointTests.java
common/src/test/java/org/cloudfoundry/identity/uaa/oauth/UaaAuthenticationKeyGeneratorTests.java
common/src/test/java/org/cloudfoundry/identity/uaa/oauth/UaaUserTokenConverterTests.java
login/src/main/java/org/cloudfoundry/identity/uaa/login/AbstractControllerInfo.java
login/src/main/java/org/cloudfoundry/identity/uaa/login/AnalyticsInterceptor.java
login/src/main/java/org/cloudfoundry/identity/uaa/login/ClientInfoAuthenticationFilter.java
login/src/main/java/org/cloudfoundry/identity/uaa/login/LinkedMaskingMultiValueMap.java
login/src/main/java/org/cloudfoundry/identity/uaa/login/util/IndirectBeanCreator.java
login/src/main/java/org/cloudfoundry/identity/web/Prompt.java
login/src/test/java/org/cloudfoundry/identity/uaa/login/LinkedMaskingMultiValueMapTests.java
login/src/test/java/org/cloudfoundry/identity/web/PromptTest.java
New Features
- Deleting zones is now supported. Supplemented
- Deleting providers is now supported.
- Provide support for user account verification:
New users are automatically verified by default. Unverified users can be created by specifying their verified: false property in the request body of the POST to /Users, as shown in the example below. Unverified users must then go through the verification process. Obtaining a verification link (to send to the user) is outlined in the section Verify User Links: GET /Users/{id}/verify-link. - Support client id/secret authentication from form parameters
- syslog enhancement Add in the ability to tag each log line using a layout.
- Enhance logging for zone resolution and similar story
- New
/Groups
end points to manage memberships - [Expose the scim scopes (read, write, create) as cross zone scopes similar to zones.{zoneid}.clients.admin](Expose the scim scopes %28read, write, create%29 as cross zone scopes similar to zones.{zoneid}.clients.admin)
- The UAA will accept any hostname - Previously the UAA would only accept requests on
localhost
or on hostnames derived from the configuration optionzones.internal.hostnames
. This made it a bit tricky to get started when trying to access the fresh, non configured UAA instance by IP address or other hostname, If thezones.internal.hostnames
is configured, only those will be used as base hostnames. - Build is using Jacoco for coverage reports. Cobertura development seemed to have stalled and was having issues with Java 8
- 512M Minimum memory requirement confirmed
- Ability to supply complete Yaml configuration when deploying standalone UAA on cloud foundry
- Provide the ability to set, retrieve & display OAuth Client Name
Bug Fixes
- Only one valid passcode at any given time - When requesting passcodes to use for user assertion, if a new passcode is requested on the endpoint
/passcode
previously issued passcodes will be invalidated. /Groups
endpoint no longer filters groups for the logged in user. More intuitive results when retrieving groups. [Supplement story(https://www.pivotaltracker.com/story/show/109107468)- Unable to retrieve SAML user attribute values when NameFormat="...:unspecified" Support non string attributes SAML user attribute
- Invited LDAP users get the correct user_id if authenticating without accepting invitation.
- Invited SAML users get the correct user_id if authenticating without accepting invitation.
- Show SAML alias on the login page if link text is missing
- Consolidate configuration file and zone default for SAML
- Configure key passphrases - This story only allows the configuration of the passphrase. It is not yet read by the UAA server.
- Invalid redirect_uri leaves too few clues for troubleshooting.
- /check_token is including null authorities list in response
- CORS configuration format has changed to support both XHR and non XHR requests.
2.7.3 Release Notes
This release fixes a backwards incompatibility issue with the allowUnverifiedUsers
flag. As part of the previous release, unverified users in any zone other than the default (uaa) zone would not be allowed to log in irrespective of what the flag was set to. This change has now been reverted and the allowUnverifiedUsers
applies to all zones again.
UAA 2.7.2
Features
- The
password_resets
endpoint now takes optionalclient_id
andredirect_uri
parameters and returns the user id and verification code in the response. - SAML authentication failures now show error messages instead of losing all context.
- UAA SAML Auth now supports NameIDs other than email.
- LDAP role/group memberships exposed in OpenID Connect JWT.
allowUnverifiedUsers
flag only affects default zone. Other zones do not allow unverified users and are not affected by the flag.- Retain client context when user clicks on "Reset password", as long as their browser session remains intact.
/password_change
endpoint now returns an autologin code. This code can be used to hit/autologin
which logs the user in and redirects to the saved request (if any).- Introduced a
uaa.jwt.claims.exclude
property that allows excluding claims from the JWT obtained via client credentials. - Users in the default zone can manage other zones using the subdomain, using the
X-Identity-Zone-Subdomain
header. - The
/check_token
endpoint now makes sure that the scopes and authorities in the token are still valid. - Add support for inviting users whose username is not the same as their email in an external user store.
- UAA doesn't require SAML cert and key if SAML is not being used.
- Access token and refresh token expiry configurable globally per zone.
- will be used if client does not have these properties set
requestsSigned
andwantAssertionSigned
SAML properties exposed per zone inSamlConfig
.
Bug Fixes
- Hitting the
/password_change
API endpoint with an invalid/expired code now returns an error message instead of a 500. - If an unverified user tries to log in and unverified users are not allowed, a verification email is not resent. Instead, users are expected to create a new account or reset their password.
- Token permissions are now validated by checking the
scopes
instead ofauthorities
.- Note:
uaa.admin
orclients.admin
scope must be requested if clients wish to be able to change other client's secrets.
- Note:
Backwards Incompatible
- Disabling self-service links doesn't remove links from
/info
or /login
JSON responses./info
endpoint now returnsMap<String,String[]>
prompt instead ofList<Map<String,String[]>>
UAA 2.7.1
Features
- CORS Filter improvements - do not enforce on same origin requests
- Store SAML user information in UAA shadow account
- Store LDAP user information in UAA shadow account
- OpenID Connect token can contain external SAML user groups when using
roles
scope - Add ability to map SAML groups to UAA scopes
- Serialize authentication origin details during authorization_code/implicit flow
- Populate id_token with custom user claims
- Update user attributes when SAML/LDAP users authenticate
- Support LDAP referrals and don't throw exception during partial results
- Add API for user verification link generation
- Store all zone subdomains as lowercase, and subdomains are case insensitive
- Add ability to map LDAP attributes to custom claims in id_token
Bug Fixes
- Remove unused invitations response segment
- Autlogin uses context sensitive redirect to avoid domain name change
- Zone resolver should not throw an error if zone is not found
Misc
UAA 2.7.0.3 Release Notes
This release adds support for Client IDs longer than 36 Characters.
UaaTokenStore doesn't support client_ids longer than 36 chars
UAA Release 2.7.0.2
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: