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 <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
