Re: Do your service brokers leverage the Org and Space fields in the broker API?
We also use the org and space guids in some brokers:toggle quoted message Show quoted text
1- In autosleep , as to opt in for space level features (as an
alternative to the usual app or route level opt-in provided through current
2- In sec-group-broker-filter  to dynamically open security groups in
the associated space in order to allow consumption of the returned
credentials by the broker.
3- In db-dumper-service , as a work around the lack of authentication
support in the current service broker API: from the space_id field securely
provided by the CC we infer the requester as SpaceDeveloper permission on
the space, and hence is allowed to access other services in that same
space, in this particular example to dump them.
Use-cases 1) and 2) are pretty specific to CF and would be hard to provide
in a portable way to other platform such as K8S, so preserving the
organization_guid and space_guid fields as CF-specific extensions is useful
and important to us. This is a better alternative than an opaque platform
independent string that could be a normalized low denominator: we would not
be able to trust its semantics (i.e. that CC is indeed garanteeing that
request originated from this space and org guids).
Use-case #3 might be more generic: authenticating users both in dashboards
and in [un]provision/[un]bind/update request could be made generic and
enable brokers to interact with users from multiple platforms in the same
way. I hope we can resume the related proposals discussions initiated at
as part of the Open Service Broker API work and find ways to make it
applicable to other platforms (e.g. leveraging openId connect protocol)
On Fri, Nov 4, 2016 at 1:25 AM, Dubois, Jan <jan.dubois(a)hpe.com> wrote:
We also use these fields in a credentials broker that hands out separate