Open Stack

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.