uaa

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

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

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

This is a security release which addresses CVE-2016-4468 UAA SQL Injection

This is a security release which addresses CVE-2016-4468 UAA SQL Injection

This is a security release which addresses CVE-2016-4468 UAA SQL Injection

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

This is a security release which addresses CVE-2016-3084 UAA Password Reset Vulnerability

New Features

Generic OpenID Connect Relying Party Support

UAA now supports federating to an OpenID Connect 1.0 compliant Identity Provider in addition to SAML 2.0 providers.
The OpenID Connect IDP can be bootstrapped from the manifest by setting the properties below. The Identity Provider API can also be used to manage the provider. Please refer to the docs here

login.oauth.providers:
    description: "Contains a hash of OpenID Connect/Oauth Identity Providers, the key will be used as the origin key for that provider, followed by key/value pairs. Presence of the userInfoUrl will mark it as an OpenID provider instead of OAuth."
    example:
      my-oauth-provider:
        type: oidc1.0
        authUrl: <URL to the authorize endpoint of the provider>
        tokenUrl: <URL to the token endpoint of the provider>
        tokenKey: <Token verification key>
        tokenKeyUrl: <URL for token verification. Will be used if tokenKey is not specified.>
        scopes:
          - openid
          - <other scope>
        linkText: My Oauth Provider
        showLinkText: true
        addShadowUserOnLogin: true
        relyingPartyId: <OIDC Client ID>
        relyingPartySecret: <OIDC Client secret>
        skipSslValidation: false
        attributeMappings:
          given_name: <Attribute holding given name in the OIDC ID Token>
          family_name: <Attribute holding family name in the OIDC ID Token>
          user_name: <Attribute holding username in the OIDC ID Token>
          external_groups:
            - <attribute holding roles or group memberships in the OIDC id_token>
            - <other attribute holding roles or group memberships in the OIDC id_token>
          user:
            attribute:
              name-of-attribute-in-uaa-id-token: name-of-attribute-in-provider-token
              name-of-other-attribute-in-uaa-id-token: name-of-other-attribute-in-provider-token

Related Stories

• Register OpenID Connect/OAuth Provider
• Provision the shadow user after authentication
• Add support for skip ssl validation on OpenID Connect provider
• OIDC Perform Authentication Flow after link click on login page
• OpenID Connect add support for requesting scopes mentioned in the provider configuration
• Validate openID/OAuth provider created/updated via API
• Validate the OpenID connect id_token based on token_key provided
• Provide the ability to disable shadow user creation for OIDC
• Add support for propagating external roles as scopes in the oauth access token for SAML IDP
• Propagate Access Token with OAuth Provider Roles

Revocable Tokens

UAA now supports revocable tokens. A new token type of opaque has been added in addition to JWT tokens.
Both JWT and Opaque tokens are revocable. The revocability of the JWT tokens is configurable per Identity Zone and is turned off by default.

 uaa.jwt.revocable:
    default: false

Related Stories

• Implement JDBC dao to revocable token storage
• support token_format=opaque for access tokens
• Enable jwt.token.revocable token to force all JWT tokens to be revocable.
• Implement revoke my tokens API

JWT Key Rotation

UAA now supports specifying multiple signing and verification keys as part of the Identity Zone configuration. We have introduced the mechanism to pass Key ID in the JWT Token Header. The token_key endpoint reflects the active signing key and the token_keys end-point reflects all the verification keys. Please refer to the corresponding APIs here

Related Stories

• /token_keys endpoint should return all the keys
• Utilize the Signing & Verification Key set Per Identity Zone
• Spring REST docs for token_key(s)
• Support rotation of JWT Signing/Verification Key per zone

Spring REST Documentation for UAA APIs

We have begun the work to migrate the UAA API docs to Spring REST docs. The new documentation can be found here

Related Stories

• Generate Spring Docs for /oauth/authorize
• Generate Spring Docs for /oauth/token
• Documentation Updates for check_token
• Generate docs for Identity Zone API
• Add restdocs for refresh_token grant type
• Document openid connect flow for /oauth/authorize and /oauth/token

Other minor features

• Get rid of the SAML MetadataProvider cache
• uaa.admin should be allowed to manage clients
• Remove the uaa.resource restriction
• Utilize the SAML Signing Key Set per Zone
• Add HttpOnly and Secure (if https) to CSRF cookie on GET /login
• uaa.scim.external_groups should support origin key
• uaa.admin` should be allowed to manage users

Bugs Fixes

• Key ID is missing from /token_key and /token_keys
• Document email change, password resets, and verification/code api endpoints
• Fix backward-incompatible change in TokenPolicy
• Backwards incompatibility with TokenPolicy deserialization
• ConcurrentModificationException in CachingPasswordEncoder
• Setting UAA session timeout (backend) in config
• Registered redirect ending with wildcard doesn't match naked path
• Failure to parse JWT token_key response when using Ruby Library
• Login Page for CF sends unencrypted form data
• When running 3.2.1, get errors reading uaa.yml distributed with 3.2.1
• Differentiate invalid passcode error
• Bubble up OpenID connect error properly
• Client Auth Success - Audit message missing client_id
• When deleting a group - delete children
• Default Zone Branding properties should apply to all zones
• Users listing not functional with disableInternalUserStoreManagement
• Automatic redirect to the OIDC provider doesn't work if all other provider including internal are disabled
• Token key not being put in the resulting yaml properly
• If User Account is locked because of unsuccessful attempts, we should propagate the error back
• user_id present in client token
• NullPointerException occurs if tokenKeyUrl is not specified for OIDC provider
• POSTing a zone without token validity results in missing EXP claim
• /token_keys is not documented in UAA-API.rst
• UAA fails to fetch SAML IDP metadata when traffic is restricted behind an HTTP proxy
• /check_token endpoint should work with opaque token
• UAA to be able to accept opaque tokens
• Change the messaging for disabled Shadow user creation
• Client ID being added in user_id field in database for opaque client tokens

This is a security release which addresses CVE-2016-0781 UAA Persistent XSS Vulnerability

New Features

• JDK Update to 1.8.0_73
• Clicking on the App under where to in the Dashboard should open a new tab
• Merged UAA as SAML IDP contributed by GE
• Enforce the WantSignedAssertion and signedRequests in SAML for all Identity Zones
• Implement Session Cookie Config
• Support filter by Member & Requesting specified attributes for Groups
• Expose UAA properties per Identity Zone
• Allow /check_token to perform authorization

Features In Progress

• Revocable Tokens
  • Create revocable token storage
• JWT & SAML Key Persistence & Rotation
  • Changes to secure private key information for SAML & JWT in the Zone
  • Bootstrap legacy jwt keys as part of keypair list for default zone config
  • Generate the verification key based on the Signing key
  • Add validation for SAML Key Pair and Passphrase

Bugs Fixes

• UAA fails to start when upgrading to v2.7.2 & above if LDAP is configured
• SAML Logout does not send a SAML logout request to the IDP (SSO2)
• SiteMinder Login Redirects to /favicon.ico
• SAML IDP Roles Mapping doesn't work
• Deleting a zone should create an audit log
• Accessing any of the client metadata end points without the accept header throws 500
• autocomplete=false does not work, it needs to be autocomplete=off
• Authentication to UAA after disable of internal auth throws 500 instead of 401
• /login with Accept="application/json" redirects to saml provider if there is only one provider and internal user store is disabled.
• Logout Redirect properties are being applied to the zone
• Ignore verificationKey during json serialization/deserialization of TokenPolicy
• Remove implicit grant and autoapprove true from cf client in cf-properties.yml

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

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

This is a security release which addresses CVE-2016-0732 Privilege Escalation

This is a security release which addresses CVE-2016-0732 Privilege Escalation

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

1. cloudfoundry-identity-model - data objects that are used as arguments for the API controllers on the UAA
2. cloudfoundry-identity-client-lib - module to hold future client side API libraries for administering a UAA
   • Token retrieval API completed Supplement 1 Supplement 2
3. cloudfoundry-identity-server - all server side code
4. 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 option zones.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 the zones.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.

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.

Features

• The password_resets endpoint now takes optional client_id and redirect_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.
  • attributeMappings (map UAA scopes to LDAP roles) and externalGroupsWhitelist (external groups allowed to populate token) properties added
• 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.
  • SAML
  • LDAP
• 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 and wantAssertionSigned SAML properties exposed per zone in SamlConfig.

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 of authorities.
  • Note: uaa.admin or clients.admin scope must be requested if clients wish to be able to change other client's secrets.

Backwards Incompatible

• Disabling self-service links doesn't remove links from /info or /login JSON responses.
  • /info endpoint now returns Map<String,String[]> prompt instead of List<Map<String,String[]>>

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

• Upgrade Flyway plugin in Gradle build
• Clarify external config file usage
• Refactor the UAA zone LDAP provider to be identical configuration as any other zone LDAP IDP

This release adds support for Client IDs longer than 36 Characters.

UaaTokenStore doesn't support client_ids longer than 36 chars