Hello Dan,
I cannot comment too much on what you have to do on the CloudFoundry
(CF) side of things but I might be able to give some advice from the
Qpid Broker for Java side.
For authentication, the broker supports OAuth2 [1] which is also
supported by CF [2]. Qpid uses the implicit grant flow. In the
OAuth2 AuthenticationProvider you need to specify the
authorizationEndpointURI, tokenEndpointURI, clientId, clientSecret.
These align with the OAuth2 specification. Not part of the OAuth2
spec are the identityResolverEndpointURI and identityResolverType
attributes. You will want to set the type to
CloudFoundryIdentityResolver and the EndpointURI to the check token
service [3]. This is responsible to turn an access token into a
username which will be used for logging and a UserPrincipal using this
name will be added to the Subject.
For authorization the scenario envisioned is that you use the
CloudFoundryDashboardManagement GroupProvider in conjunction with a
AccessControlProvider. In the GroupProvider you configure a
serviceToManagementGroupMapping containing a JSON map from CF
serviceInstanceId to Qpid management group name. When a user logs in
this GroupProvider will query the configured cloudFoundryEndpointURI
using this [4] API to figure out whether the user has permissions to
manage any of the serviceInstances in the map. For each
serviceInstance that the user has permissions to manage a
GroupPrincipal with the name from the map will be added to the
Subject. You can then write ACLs in terms of these management groups
to limit access to certain parts of the broker. For example you could
limit access to a specific VirtualHost.
I'll attach a text file with a ASCII diagram showing the login process.
I hope this helps to illuminate how we envision the broker being used
in a CloudFoundry scenario.
Kind regards,
Lorenz
[1]
https://qpid.apache.org/releases/qpid-java-6.1.1/java-broker/book/Java-Broker-Security.html#Java-Broker-Security-OAuth2-Provider
[2] https://docs.cloudfoundry.org/api/uaa/
[3] https://docs.cloudfoundry.org/api/uaa/#check-token
[4]
https://apidocs.cloudfoundry.org/252/apps/retrieving_permissions_on_a_app.html
On 01/03/17 05:29, Dan Langford wrote:
On the IRC channel last week rgodfrey mentioned that some of you may be
deploying Qpid via Cloud Foundry. I am exploring some of those ideas for
use at my place of employment and was wondering if I could pick your brain
a little bit on what that setup might look like. Please forgive me if my
questions sound a bit obvious or naive im a bit new to some of these
concepts.
Initially I had not considered deploying Qpid via CloudFoundry. I was just
planning an integration with our on-prem CF. I need a service broker for
Qpid. Have any of you set up Qpid as a service in your CF setup? Did you
write the service broker layer? Or is there an open source one already
available? I have never written a service broker before so if you have any
tips in regards to Qpid and a service broker they would be welcome.
What is your pattern for a Qpid service in CF? Do you have a CF service
representing a single Queue? Or representing a VirtualHost? or does a new
service spin up an independent instance of Qpid? Would it be feasible for a
service to represent a Vhost and be associated ~1:1 to a CF "space", making
it so a "space" named "project-a-non-prod" would have a VHost named the
same?
So with the recent addition of a GroupProvider that backed by a CF Service
dashboard could somebody explain how that flow works? Does CF provide a URL
to manage the service and that URL has an accessToken in it? Or does
accessing the web admin redirect over to another url for authorization and
then redirect the user back to the web admin? Does/Can this groupProvider
be used for system-to-system access? We call those "service accounts" at
work. Or is it more appropriate for mainly User access to the web admin
area?
How are you granting users access to a queue? I assume you are using the
HTTP api around RuleBased access control provider? or is that not needed
with proper use of the aforementioned GroupProvider?
Are you spinning up single instances of Qpid as apps in CF to be used in
isolation and for specific purposes? Or do you have many Qpid CF instances
forming a large HA network of brokers accessed via Dispatch Routers?
Are you using CF TCP Routing or strictly HTTP/WS access or just connecting
directly to the host or a Dispatch Router?
Thank you so much for taking the time to glance over this and offer any
help you can in my understanding. I apologize if it seems that i have not
done my homework yet. I will have more throughput in the coming weeks to
start playing with it more hands on I was just hoping to get an idea of a
good direction to get headed off in, one that already had proven success.
Dan '8bagels' Langford
UTC-0700
browser #################### broker #####################
######################### CloudFoundry #############################
| # redirector oauth2 provider group provider # # auth
server token endpoint check token verification #
| # | | | # # |
| | | #
| # | | | # # |
| | | #
+------request----->| | | # # |
| | | #
| # | | | # # |
| | | #
|<-----redirect-----+ | | # # |
| | | #
| # | | | # # |
| | | #
+--------------------------login----------------------------------------->|
| | | #
| # | | | # # |
| | | #
|<--------------------redirect & grant------------------------------------+
| | | #
| # | | | # # |
| | | #
+-request & grant-->| | | # # |
| | | #
| # | | | # # |
| | | #
| # +-reqst & grant->| | # # |
| | | #
| # | | | # # |
| | | #
| # | +---------------------auth grant &
client secret---------->| | | #
| # | | | # # |
| | | #
| # | |<------------------------access
token*--------------------+ | | #
| # | | | # # |
| | | #
| # |
+---------------------------------access token----------------------------->|
| #
| # | | | # # |
| | | #
| # |
|<-----------------------------------------user id--------------------------+
| #
| # | | | # # |
| | | #
| # | +-------------->| # # |
| | | #
| # | | | # # |
| | | #
| # | |
+----------------------access token & service id----------------------->|
#
| # | | | # # |
| | | #
| # | |
|<------------------------true/false------------------------------------+
#
| # | | | # # |
| | | #
| # | |<--principal---+ # # |
| | | #
| # | | | # # |
| | | #
| # | set session | # # |
| | | #
| # | | | # # |
| | | #
|<--------redirect w/o grant---------+ | # # |
| | | #
| # | | | # # |
| | | #
|--request---># | | | # # |
| | | #
| # | | | # # |
| | | #
* This includes expiry time and refresh token. Their handling is not shown in
this diagram.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
