Open Stack

Reiterating old point.  I'd love if I could get kerberos tickets passed via
keystone API.

-Matt

On Thu, Aug 23, 2012 at 5:49 PM, Adam Young <ayoung at redhat.com> wrote:

> On 08/23/2012 03:41 PM, David Chadwick wrote:
>
>>
>>
>> On 23/08/2012 19:59, Adam Young wrote:
>>
>> CUT
>>
>>
>>> If two users have identical attributes, with the exception of their
>>> username and userId number, and only one of them should get access to
>>> MomAndPopsLaundry,  then the Admin at MomAndPopsLaundry  has to grant
>>> the permissions to that userid.
>>>
>>
>> correct. Username and userID are simply attributes such as role and
>> favouriteDrink. The only difference is that each uniquely identifies the
>> user in the domain whereas the others do not. So they are identifiers. The
>> Admin can select another differentiating attribute such as email address
>> (which is also an identifier). It is unlikely that two users will have all
>> their attributes identical.
>>
>>  This works, but it doesn't scale.
>>>
>>
>> If MomAndPop want to give different permissions to each individual user,
>> then it is their model that does not scale. Its not the FIM model.
>> If MomAndPop want to select individual users from different IDPs then of
>> course they will need to use attributes that are identifiers, otherwise
>> they will select a group of users with each attribute. I am pretty sure
>> that all IDP protocols can send a unique PID for each user with the
>> attribute assertions, so there is always a way to uniquely identify each
>> individual user.
>>
>>
>>  Instead, the user should be put into a grouping from the
>>> MomAndPopsLaundry's IdP that then provides the roles.
>>>
>>
>> But this may not uniquely identify a single user
>>
>
> Right.  What I would assume is that they would have some grouping, say
> "contract_administrators"  and each user would get listed in there....but
> perhaps that is really no different than
> what you are sugggesting:  the policy engine would just have a list of
> userids instead of storing them inside the IdM database.  But seems like it
> should go in IdM, and be served by IdP, instead of being maintained as part
> of the policy.  Typically, you don't want to deploy new policy rules just
> because a user was added to or removed from a group.
>
>
> In a Kerberized system, this would be done via a service ticket issued
> using a cross domain trust.  I think that is the right model:  you have to
> go to the other IdP in order to get a credential for their resources.  Then
> the other IdM maintains a list of remote users, from multiple domains.
>
>
>
>
>
>
>
>> regards
>>
>> David
>>
>>>
>>> I'll take a look at the demos above and see if they meet my concerns.
>>>
>>>
>>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120823/5fb0a7c7/attachment.html>