anchor.diff:  
   1. UAA authenticates the dashboard client, validates the authorization code, and ensures that the redirect URI received matches the URI used to redirect the client when the authorization code was issues.  If valid, UAA responds back with an access token and a refresh token.
   
  -### <a id='checking-user-permissions'></a>Checking User Permissions ###
  +### <a name='checking-user-permissions'></a>Checking User Permissions ###
   
   UAA is responsible for authenticating a user and providing the service with an access token with the requested permissions. However, after the user has been logged in, it is the responsibility of the service dashboard to verify that the user making the request to manage an instance currently has access to that service instance.
   
  
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:
  
  