Open Stack

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/3dd9c04e/attachment.html>