qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorenz Quack <quack.lor...@gmail.com>
Subject Re: deploying Qpid via Cloud Foundry
Date Wed, 01 Mar 2017 12:35:07 GMT
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
>


Mime
View raw message