Open Stack

On 24/08/2012 10:37, romain guignard wrote:
> 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.

I guess Keystone is really a proxy, acting as an SP to the IDP, and an 
IDP to the cloud service.

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.

Agreed. Our model is general purpose, it does not say what the cloud 
service is (nor does it care). However each cloud service client does 
have to be modified to perform federated authn via Keystone.

  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.

Its the IDP in our model.

  This
> authenticatin system will support identity federation and will act as a
> service provider.

Well everything is a service provider of some sort. But in the FIM 
world, the authenticating service is usually known as an IDP (identity 
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.

Our model contains a Discovery service which determines the IDP endpoint 
and creates the correctly formatted request message. (This is actually 
two separate functionalities, so maybe it ought to be split into two 
services, a Disco service and a Request Creation Service).

  Does
> your solution plans to simply validate a saml token ? I supposed that it
> will be possible but to be sure I ask you.

Yes it already does this. We call this component the Credential 
Validation Service.

>
> 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 ?

We already have an authz service that talks the XACMLv2-SAML 
request/response protocol (as per the OASIS spec), and our next step is 
to integrate this into Keystone.
The XACML group are currently working on a JSON version of this protocol 
I believe, so in the longer term JSON could be used.

regards

David

>
> Thanks in advance for your response
>
> Romain
>
>
> 2012/8/24 David Chadwick <d.w.chadwick at kent.ac.uk
> <mailto: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
>     <mailto: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>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>