On 14/05/15 23:38, Adam Young wrote:
So the mechanisms are there. In the short term we'd need some
cross-project co-operation to define a system through which we can do
this across projects (i.e. Murano or any other service can create a
user and have Zaqar authorise it for listening on a particular queue).
Maybe this is an extra parameter when creating a queue in Zaqar to
also create a user account in a separate domain (the way Heat does)
with permission to send and/or receive only on that particular queue
and return its credentials. That would be easier to secure and easier
to implement than having other services create the user accounts
themselves.
I think the user accounts (or consumers as oauth calls them) should be
cheap, and easy to create . I see no reason to try to limit them.
Ideally, we would use something like X509 in order for them to talk to
Keystone; that work is under way in Keystone already. Kerberos works
for those who want to use it with a Keytab.
I was talking about a short term solution to follow Heat's existing
practices, without any changes in Keystone. It'd be much easier for
Zaqar to say 'here is your queue, and here is the user I created that is
already correctly authorised for it' than it would be for every service
to have its own separate Keystone domain to set up and for them all to
have to learn how to create users in it and then to pass the user to
Zaqar when creating the queue to set up the authorisation.
If you're saying that Keystone already supports, or will soon support,
what we need to do by using OAuth then I'm *more* than happy to dump
this idea and move straight to that.
In the medium term hopefully we'll be able to come up with a less
hacky solution that uses Oslo libraries to manage all of the user
creation and authorisation.
Why Oslo oand not Keystone? Why do we need a new abstraction?
Again, if Keystone does everything we need then I agree there's no
problem to solve here.
It will be interesting to discuss this with Keystone team. What is it is
possible to have a token which is restricted to be authenticated to
specific API URL like GET /v1/queues/<queue-id>/
Yes, we should definitely discuss this with the Keystone team and make
sure they're getting feedback from all of the many groups who need it
so that they can prioritise the work appropriately :)
Endpoint binding of tokens is proposed already. I have a spec out for
more constraints. We need a way to annotate them in the token, and then
policy can certainly be enforced on any data in the token.
This is OAuth tokens?
In the existing world of expiring bearer tokens I think we'd probably
need application servers to hold their own auth credentials, not just a
token, so they can keep refreshing it. Which implies that the scoping
should be on the user, not the token. It's kind of unfortunate IMHO that
the default policy.json files tend to give all users access to non-admin
APIs, rather than requiring a specific role (like "Member"). Although
that's kind of counterbalanced by the fact that when you create users,
it has to be in a separate domain with its own separate tenant anyway,
and right now the application has to do its own mapping between tenants
in different domains to know whom to trust (at least, this is how Heat
currently does it).
If OAuth makes all of these problems go away, then +1000 from me :)
I suspect that what we will have is a two pass policy check; the first
will be all global options (endpoint binding, etc) and the second will
be API specific checks.
That makes sense to me.
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
