Closed bparees closed 6 years ago
I suspect this it meant to be an admin thing, not a normal end user thing since most users don't actually see the output of the /v2/catalog request - just the platform does. So I'm guessing this URL is meant to be used by platform admins to do some kind of admin action on all of the instances/services that are related to the platform.
But perhaps @avade can weigh-in here.
@bparees , this explains what it is for. You're right though that servicebrokerapi should itself contain some information about what it's meant for.
I think some of that CF content could be added to the spec.
@bparees if the link @mcelep provided answers your question, then I will PR an update to the spec.
I find that explanation to be confusing - are those creds really meant to be shared with ALL CF users?
@shalako or @zrob - can you clarify the use case?
CF specific answer:
This value is how the broker requests to have an oauth client added to UAA. That client is used to allow service broker dashboards to use SSO with the UAA.
Given a broker has a UAA client and each service instance has an individualized service dashboard url. When a user goes to that dashboard url they can be redirected to the UAA login page for SSO to the dashboard. Now the user is signed in within the platform context and based on the permissions the user granted to the dashboard at sign in, the dashboard can apply permissions within the platform context. Remember that brokers don't have a concept of space/org, so it must ask CF for information regarding user permissions on a service instance.
thanks @zrob. So effectively it's information related to the configuration of service instance dashboard SSO via UAA.
@zrob so the CC currently takes the dashboard_client
in the response and creates a UAA client that the broker can use to verify tokens provided in the SSO flow? Does the token also contain the scopes of the CF user?
Think of the SSO flow you see when you use google or facebook to sign into some third party. The first time you sign in it asks you what things you'll allow the third party to see: ie email address, home address, make posts on user behalf. The same thing is true here, the dashboard can ask for the user to allow certain things, the user can say yes or no, then based on those choices the dashboard can act as the user up to the level of granted permission.
dashboard_client
has been moved to the CF Catalog Extensions section of the profile doc, so closing this
It's not entirely clear to me how https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#dashboard-client-object- is intended to be used.
Since it is part of the catalog entry, and not a specific service instance, it would seem to assume that all service instances for a given catalog entry are going to share the same dashboard infrastructure, but that doesn't seem like a valid assumption.
Am I understanding the field(and implied limitations) correctly?
@pmorie