anchor.diff:  "allow_debug":true}
   ```
   
  -<p class='note'>To enable service dashboards to support SSO for service instances created from different Cloud Foundry instances, the /v2/info url is sent to service brokers in the `X-Api-Info-Location` header of every API call. A service dashboard should be able to discover this URL from the broker, and enabling the dashboard to contact the appropriate UAA for a particular service instance.</p>
  +<p class='note'>To enable service dashboards to support SSO for service instances created from different <%= vars.product_name %> instances, the /v2/info url is sent to service brokers in the `X-Api-Info-Location` header of every API call. A service dashboard should be able to discover this URL from the broker, and enabling the dashboard to contact the appropriate UAA for a particular service instance.</p>
   
   A service dashboard should implement the OAuth Authorization Code Grant type ([UAA docs](https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#authorization-code-grant), [RFC docs](http://tools.ietf.org/html/rfc6749#section-4.1)).
   
  
positive.code: | `cloud_controller.read`                          | Allows read access to all resources the user is authorized to read |
  | `cloud_controller.write`                         | Allows write access to all resources the user is authorized to update / create / delete |
  
  ## <a id='reference-implementation'></a>Reference Implementation ##
  
  The [MySQL Service Broker][example-broker] is an example of a broker that also implements a SSO dashboard. The login flow is implemented using the [OmniAuth library](https://github.com/intridea/omniauth) and a custom [UAA OmniAuth Strategy](https://github.com/cloudfoundry/omniauth-uaa-oauth2). See this [OmniAuth wiki page](https://github.com/intridea/omniauth/wiki/Strategy-Contribution-Guide) for instructions on how to create your own strategy.
  
  The UAA OmniAuth strategy is used to first get an authorization code, as documented in [this section](https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#authorization-code-grant) of the UAA documentation. The user is redirected back to the service (as specified by the `callback_path` option or the default `auth/cloudfoundry/callback` path) with the authorization code. Before the application / action is dispatched, the OmniAuth strategy uses the authorization code to [get a token](https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#client-obtains-token-post-oauth-token) and uses the token to request information from UAA to fill the `omniauth.auth` environment variable. When OmniAuth returns control to the application, the `omniauth.auth` environment variable hash will be filled with the token and user information obtained from UAA as seen in the [Auth Controller](https://github.com/cloudfoundry/cf-mysql-broker/blob/master/app/controllers/manage/auth_controller.rb).
  
  ## <a id='restrictions'></a>Restrictions ##
  
   * UAA clients are scoped to services.  There must be a `dashboard_client` entry for each service that uses SSO integration.
   * Each `dashboard_client id` must be unique across the CloudFoundry deployment.
  
  ## <a id="resources"></a>Resources ##
  
    * [OAuth](http://oauth.net/2/)
    * [Example broker with SSO implementation][example-broker]
  
negative.code:   ```
  
  When this client is not present in the cf-release manifest, Cloud Controller cannot manage UAA clients and an operator will receive a warning when creating or updating service brokers that advertise the `dashboard_client` properties discussed below.
  <% end  %>
  
  ## <a name='broker-responsibilities'></a>Service Broker Responsibilities ##
  
  ### <a name='registering-dashboard-client'></a>Registering the Dashboard Client ###
  
  1.  A service broker must include the `dashboard_client` field in the JSON response from its [catalog endpoint](api.html#catalog-mgmt) for each service implementing this feature. A valid response would appear as follows:
  
  