Hey Adam, Hey David<br><br>I am very interested in the solution designed by the university of kent to add identity federation in keystone.<br>On this subject I have some questions : <br><br>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. <br>
<br>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.<br>
<br>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 ?<br>
<br>Thanks in advance for your response<br><br>Romain <br><br><br><div class="gmail_quote">2012/8/24 David Chadwick <span dir="ltr"><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 24/08/2012 01:49, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/23/2012 03:41 PM, David Chadwick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 23/08/2012 19:59, Adam Young wrote:<br>
<br>
CUT<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If two users have identical attributes, with the exception of their<br>
username and userId number, and only one of them should get access to<br>
MomAndPopsLaundry,  then the Admin at MomAndPopsLaundry  has to grant<br>
the permissions to that userid.<br>
</blockquote>
<br>
correct. Username and userID are simply attributes such as role and<br>
favouriteDrink. The only difference is that each uniquely identifies<br>
the user in the domain whereas the others do not. So they are<br>
identifiers. The Admin can select another differentiating attribute<br>
such as email address (which is also an identifier). It is unlikely<br>
that two users will have all their attributes identical.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This works, but it doesn't scale.<br>
</blockquote>
<br>
If MomAndPop want to give different permissions to each individual<br>
user, then it is their model that does not scale. Its not the FIM model.<br>
If MomAndPop want to select individual users from different IDPs then<br>
of course they will need to use attributes that are identifiers,<br>
otherwise they will select a group of users with each attribute. I am<br>
pretty sure that all IDP protocols can send a unique PID for each user<br>
with the attribute assertions, so there is always a way to uniquely<br>
identify each individual user.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Instead, the user should be put into a grouping from the<br>
MomAndPopsLaundry's IdP that then provides the roles.<br>
</blockquote>
<br>
But this may not uniquely identify a single user<br>
</blockquote>
<br>
Right.  What I would assume is that they would have some grouping, say<br>
"contract_administrators"  and each user would get listed in<br>
there...<br>
</blockquote>
<br></div></div>
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.<div class="im">
<br>
<br>
.but perhaps that is really no different than<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
what you are sugggesting:  the policy engine would just have a list of<br>
userids instead of storing them inside the IdM database.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
 But seems like<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it should go in IdM, and be served by IdP, instead of being maintained<br>
as part of the policy.  Typically, you don't want to deploy new policy<br>
rules just because a user was added to or removed from a group.<br>
</blockquote>
<br></div>
Exactly<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
In a Kerberized system, this would be done via a service ticket issued<br>
using a cross domain trust.  I think that is the right model:  you have<br>
to go to the other IdP in order to get a credential for their<br>
resources.<br>
</blockquote>
<br></div>
I still dont think you have the right model in mind.<br>
Resources are owned by SPs, not IdPs.<br>
IdPs give attributes to users, and SPs give permissions (to their resources) to attributes.<br>
Its the classic ANSI RBAC model.<div class="im"><br>
<br>
 Then the other IdM maintains a list of remote users, from<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
multiple domains.<br>
</blockquote>
<br></div>
Not necessary.<br>
<br>
regards<span class="HOEnZb"><font color="#888888"><br>
<br>
David</font></span><div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
regards<br>
<br>
David<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'll take a look at the demos above and see if they meet my concerns.<br>
<br>
<br>
</blockquote></blockquote>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br>