Open Stack

Hey Adam, Hey David

I am very interested in the solution designed by the university of kent to
add identity federation in keystone.
On this subject I have some questions :

1 - Firstly, after reading the document realized by David and his team, I
understand that keystone will act as a service provider. But in an
integrated cloud solution, many others components are present with
openstack. You could find for example a billing service, service usage
metering, a portal .............). And all of these services need to
authenticate the end-user. In this context; I supposed that the entity
responsible to authenticate the user will be probably the portal or maybe
an authentication system in front of the portal. This authenticatin system
will support identity federation and will act as a service provider.

In this context, keystone need only to validate the SAML token that will be
forwarded by the portal to authenticate the user and not responsible for
example to discover the IDP endpoint that the user has to use. Does your
solution plans to simply validate a saml token ? I supposed that it will be
possible but to be sure I ask you.

2 - Concerning authorization, do you plans to simply implement a RBAC
system or more. What do you think about providing a XACML policy driver
that allow to integrate a XACML PDP instead of a proprietary policy engine ?

Thanks in advance for your response

Romain


2012/8/24 David Chadwick <d.w.chadwick at kent.ac.uk>

> On 24/08/2012 01:49, Adam Young 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...
>>
>
> The issue is this. Keystone and the cloud service providers do not know
> who these administrators are. So they cannot be listed in Keystone. Only
> the IDP knows which current users have this role. And this set of users can
> dynamically change as people are hired and fired, promoted and demoted. So
> at the time of using the cloud, the IDP issues an assertion to Keystone
> saying that the current user, PID=12344565, has the role of
> contract_administrator. Since contract_administrator is already set up as a
> tenant in Keystone, then this user gets all the rights of this tenant.
> However, for audit purposes, the logs record that it is user PID=12344565
> who performed the current actions, so there is full accountability. If this
> user is subsequently fired, his PID will never appear in the Keystone logs
> again. Another PID will appear next time, denoting it is a different
> person. If Keystone wants to know the real world identity of an
> administrator, then it must contact the IDP (with which it has a contract)
> informing it that it was user with PID=12344565 who performed a certain
> action. So there is joint responsibility for applying sanctions.
>
>
> .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.
>>
>
> No, there is no need for userids in the policy engine if permissions are
> given to the group of administrators. If however, you want to give
> different permissions to different administrators, then you have to
> differentiate these users based on one their unique identifying attributes.
>
>
>  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.
>>
>
> Exactly
>
>
>
>>
>> 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.
>>
>
> I still dont think you have the right model in mind.
> Resources are owned by SPs, not IdPs.
> IdPs give attributes to users, and SPs give permissions (to their
> resources) to attributes.
> Its the classic ANSI RBAC model.
>
>
>  Then the other IdM maintains a list of remote users, from
>
>> multiple domains.
>>
>
> Not necessary.
>
> regards
>
> David
>
>
>>
>>
>>
>>
>>
>>> 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/20120824/2cb36166/attachment-0001.html>