Open Stack

Great, so we are moving towards an ABAC model. The reason I wanted each 
attribute to be flagged as organisational or workflow was so that it is 
clear which of them can be used in access control. (I dont care what the 
name of the flag actually is, it could be "used in access control" if 
you want)

regards

David


On 23/01/2013 21:06, Adam Young wrote:
> On 01/23/2013 03:54 PM, David Chadwick wrote:
>> Two points. First you meant authz not authn, which threw me.
> Yep. Sorry for the confusion.  Authorization, not authentication.
>> Secondly you must surely use tenants/projects for authz as well as
>> roles. And surely the CSPs make use of this attribute as well do they
>> not?
> Yes.  Specifically, a role assignment is an attribute of a user that
> links them to a project.  All the other organizational and workflow
> containers come down to specifying this.
>
> So if the user has to have the "master" role in the "dojo" project, the
> attribute for access control would be specified  something like
> "role=master,project=dojo"
>
>
>
>
>>
>> David
>>
>> On 23/01/2013 20:46, Adam Young wrote:
>>> On 01/23/2013 03:33 PM, David Chadwick wrote:
>>>>
>>>>
>>>> On 23/01/2013 20:23, Adam Young wrote:
>>>>> the dominant attribute for authN is named roles
>>>>
>>>> Can you please explain this to me
>>>
>>> I see the term "Attribute"  like "property" in object oriented
>>> programming.  It is a term about the form of the meta data.  In
>>> Keystone, we have "attributes".  The only attribute we use for policy
>>> enforcement today is role assignments, but we can expand on that in the
>>> future.
>>>
>>>
>>>
>>>>
>>>> thanks
>>>>
>>>> David
>>>
>