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 Thu, 02 Mar 2017 09:12:33 GMT
Hi Dan,

Yes, I think that flow sounds about right.
I haven't done it myself but that is essentially the approach I would take.
Feel free to let us know if you run into problems with the Qpid side.

Sorry, that I cannot help you more with the CF side.

Kind regards,
Lorenz


On 01/03/17 15:05, Dan Langford wrote:
> 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
> access
> 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
>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message