<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/23/2012 09:14 PM, Matt Joyce
wrote:<br>
</div>
<blockquote
cite="mid:CAGYSk8fp63iS1vW2L0v6yr8qN5dSit3cTPd+vGFVwCh1OaBx+g@mail.gmail.com"
type="cite">Reiterating old point. I'd love if I could get
kerberos tickets passed via keystone API. <br>
</blockquote>
<br>
Here's the plan for that:<br>
<br>
Stage 1: Keystone only<br>
<br>
1. Set up Apache HTTPD with Keystone. <br>
2. Get external auth working in Keystone. This will pass the
REMOTE_USER value in to the authenticate. IN this case, REMOTE_USER
will be your Kerberos principal<br>
3. Extend the Keystone authenticate call to use REMOTE_USER if
there is no token<br>
4. Tokens work as before elsewhere.<br>
<br>
Stage 2: extend Eventlet to support Kerberos<br>
<br>
<br>
<br>
Stage 1 is relatively simple. Stage 2 is a lot harder.<br>
<br>
<br>
<blockquote
cite="mid:CAGYSk8fp63iS1vW2L0v6yr8qN5dSit3cTPd+vGFVwCh1OaBx+g@mail.gmail.com"
type="cite"><br>
-Matt<br>
<br>
<div class="gmail_quote">On Thu, Aug 23, 2012 at 5:49 PM, Adam
Young <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">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 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.<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 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 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.<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>
</div>
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<br>
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.<br>
<br>
<br>
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.
<div class="HOEnZb">
<div class="h5"><br>
<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>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>