Open Stack

Thanks Matt - interesting detail, and a bit beyond what I was originally asking :-) I

'm not sure I understand the benefit you're getting with the cross-realm setup and how you'd want to deploy it. I think the description detail below is primarily concerned with pure authentication - more into the instances that you might spin up than just accessing OpenStack APIs, and not asserting anything about mapping groups in AD to either roles or projects. Am I reading that correctly?

- joe

On Jul 14, 2012, at 12:12 PM, Matt Joyce wrote:
> One thing I'd love to see eventually with Active Directory would be kerberos ticket passing and mapping to authentication tokens in keystone.
> 
> We discussed an early integration effort with keystone at one customer site and we got to the point where we decided the best means of handling it ( at the time ) was to simply setup a Kerb 5 KDC with a cross realm trust to the AD environment then perform a binary check against the kdc for pass / user and pull the rest of the posix data from local keystone ldap.
> 
> What I would like to see eventually is a means of authenticating to AD via keystone and getting the kerb 5 ticket passed to user instances so that users can perform passwordless gssapi ticket auth.  Also query the keystone API once authenticated for a keystone auth token and all of the associated env data for the user to use client apis.  
> 
> Along these same lines... I really want to see the keystone ec2 url path placed into the metadata api so that instances can query the path to the Keystone API.  I think I am just going to go ahead and submit a patch for that.  It really should be there.  I know some folks disagree with that, but I think the benefits outweigh the academic arguments vastly.
> 
> -Matt
> 
> On Sat, Jul 14, 2012 at 11:55 AM, Joseph Heck <heckj at mac.com> wrote:
> Good morning,
> 
> I wanted to solicit some detail from y'all as operators. I'm starting in on development for a Keystone backend that does basic Authentication against an existing active directory.
> 
> Looking forward past basic authentication, there's several potentials in how to implement this, and I'm curious among several possibilities what you all would find most useful. I'd love feedback on which of these you'd find most useful, and of course if there's a variation on the theme that would "rock your world", please tell me about it.
> 
> 1) no explicit mapping to active directory groups, projects and roles managed externally to active directory, with a users in active directory getting assigned to those projects and roles, but using the credentials (userid/password) from active directory.
> 
> 2) using active directory groups to assign roles to users, regardless of tenant. This would be storing "projects" and links of users to projects external to active directory, but using active directory groups to define what "roles" a user should have within their project(s).
> 
> 3) using active directory groups to represent projects, with membership in the group simply implying a "membership" style role with broad capabilities in the project.
> 
> The quandary I'm facing is that I'm not sure how y'all are using groups and what they represent to you, and what that *could* mean to an OpenStack deployment in your organization. Any and all feedback welcome - either back to this list, or directly to me: Joe Heck (heckj at mac.com)
> 
> -joe
> Keystone PTL
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120714/ac6d3f1f/attachment-0001.html>