qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Langford <danlangf...@gmail.com>
Subject Re: deploying Qpid via Cloud Foundry
Date Wed, 01 Mar 2017 15:05:30 GMT
Thank you for the explanation. It is very helpful to understand the
combination of Authentication Provider and Group Provider. I think we use
LDAP and / or SAML so I am interested in the fact that the UAA is an OAuth2
server in front of other authentication sources. I figured out what URLs I
need so it looks like I just need to work with the CF team here and procure
a clientId.

Now I just need to wrap my head around that service to group mapping. I'll
dive into the API today to see if I can programmatically change that
mapping via HTTP API. Then try to add acl rules over HTTP as well. I think
I am headed towards a flow like this:

1) in CF user creates Qpid service
2) service broker creates virtual host
3) service broker adds serviceId to the Service-to-Group mapping
4) service broker adds rule to the rule based Access Control Provider

Then later...

5) user logs into Qpid interface
6) login done via oauth2 to cf uaa
7) group Provider determines what groups a user is in based on CF service
8) access control provider enforces the rules based on user group limiting
the user to see just his new Virtual Host

All that service broker work is one reason I was wondering if somebody has
already done some of it.

Thanks again
On Wed, Mar 1, 2017 at 5:35 AM Lorenz Quack <quack.lorenz@gmail.com> wrote:

> 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
> > 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
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message