Open Stack

On 08/23/2012 09:14 PM, Matt Joyce wrote:
> Reiterating old point.  I'd love if I could get kerberos tickets 
> passed via keystone API.

Here's the plan for that:

Stage 1: Keystone only

1.  Set up Apache HTTPD with Keystone.
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
3.  Extend the Keystone authenticate call to  use REMOTE_USER if there 
is no token
4.  Tokens work as before elsewhere.

Stage 2:  extend Eventlet to support Kerberos



Stage 1 is relatively simple.  Stage 2 is a lot harder.


>
> -Matt
>
> On Thu, Aug 23, 2012 at 5:49 PM, Adam Young <ayoung at redhat.com 
> <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120824/19148d12/attachment-0001.html>