<div dir="ltr"><div><div>Hi Alan,<br><br>Thanks for your reply. I have to admit I don't know much about VOMS-- I hadn't heard about it until I started googling for openstack auth plugins. How would VOMS fit in with a Kerberos-based workflow? Would the user obtain a certificate from the VOMS service by authenticating with their Kerberos credentials? <br>

<br>I'm happy to share more about what I'm doing. In a nutshell I'm evaluating OpenStack with the intention of building an internal cloud. The given direction is not too specific at this point and neither are the requirements or projected use cases but one "use story" is to allow users to create machines of certain "classes", a class being "a machine that runs application X" like a web server that hosts a specific application. That's tricky for a whole host of reasons particularly as security is concerned. We don't want people injecting files/root keys into images or running unapproved images. It's the whole IaaS vs PaaS and OpenStack is really geared towards the former IMO. Let me know if you'd like more/different info about what I'm doing.<br>

<br></div><div>I was hoping to leverage Kerberos and AD/LDAP for AuthN/AuthZ, respectively. The idea with using LDAP as the identity provider was to map group membership to tenant/role membership, but with the LDAP schema keystone is expecting the groups would map to tenants and not to any particular role within a tenant. I would have had to write something to sync group members to the role objects within a tenant. I was hoping to avoid writing code to do any massaging of data so I feel like I didn't really gain much from the LDAP backend. That coupled with the fact that the implementation (openldap with a slew of overlays to talk to AD) had implementation issues in of itself. I have reverted to the SQL identity provider and will likely end up writing something to keep the two data sources in sync. Actually, something I just thought of, I could perhaps use a pipeline filter for keystone instead of doing a manual sync.<br>

<br></div>Where I am (the NIH) is pretty committed to strong authentication (Kerberos, PIV/Smart Cards etc.) so this is definitely a priority for me. I'm sure it's a policy violation for a user to store their credentials in plain text in environment variables which seems to be required for the current command line utilities. I'm also interested to see how openstack handles this going forward and am curious as to why this hasn't been a blocker for more people. This etherpad might shed some light on the future of this: <a href="https://etherpad.openstack.org/havana-external-auth" target="_blank">https://etherpad.openstack.org/havana-external-auth</a>.<br>

</div><div><br>-Aaron<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 5:34 PM, Sill, Alan <span dir="ltr"><<a href="mailto:alan.sill@ttu.edu" target="_blank">alan.sill@ttu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Aaron,<br>
<br>
I'd be interested in hearing more about what you are doing.  As you know, VOMS is a general method of supplying virtual organization membership attributes (e.g., groups, roles, etc.) as a web service. One method of doing this is in the form of extended attribute certificates, which can be fitted into any PKI or Kerberos-based workflow in principle. Other methods to make use of VOMS information may exist through portals and other related methods of accessing the features of the stored attributes through web services calls.<br>

<br>
The more general question you are asking, though, is about Auth plugins and interfacing external auth. I know several user communities that are completely committed to use of strong authentication and for which a well-designed set of interfaces that can support this are required items. One doesn't want to lose generality in producing such interfaces, though, so I would be interested in seeing how the openStack community is responding to the design topics for this aspect of authN/authZ integration.<br>

<span class="HOEnZb"><font color="#888888"><br>
Alan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On May 7, 2013, at 12:52 PM, Aaron Knister <<a href="mailto:aaron.knister@gmail.com">aaron.knister@gmail.com</a>> wrote:<br>
<br>
> Hi Everyone,<br>
><br>
> I'm looking for feedback and input about what other sites are doing for authentication and authorization with OpenStack.<br>
><br>
> First, some background:<br>
><br>
> I'm currently evaluating OpenStack (Grizzly), specifically working on integration with Active Directory. I'm unable to modify the schema to allow groupOfNames as a SUP of organizationalRole so I've implemented a workaround using openldap and several of its overlays backends to sit in front of AD. That all works just fine, however I really would like to be able to map AD groups to roles/tenants. I suspect I'll end up writing some code to do this-- shouldn't be too hard.<br>

><br>
> Also on the subject of Active Directory, it's a show stopper for me to put un-encrypted AD credentials in environment variables to then pass to the various openstack CLI progs. My ideal workaround would be to use Kerberos authentication which I actually have working. I setup keystone to run under apache based on this documentation with some tweaks here and there:<br>

><br>
> <a href="http://docs.openstack.org/developer/keystone/external-auth.html" target="_blank">http://docs.openstack.org/developer/keystone/external-auth.html</a><br>
><br>
> I created an openstack client auth plugin (based on the VOMS auth plugin) using requests_kerberos and this works well with the nova client, however none of the other client tools, including horizon, seem to support authentication plugins or the external authentication concept in general.<br>

><br>
> So, here are my questions:<br>
><br>
> - How have other folks handled integration of OpenStack with existing authN/authZ infrastructures? I'm particularly interested in the automatic mapping of existing LDAP groups to roles/tenants within openstack.<br>

> - Are there plans to add support for the auth plugins to the *client modules and CLI tools going forward? I'd be interested in contributing this if it's on the roadmap and hasn't been done yet.<br>
> - Are there plans to add support for auth plugins/external au th to Horizon? As above, I'm interested in implementing this if there's interest.<br>
> - I see vague references in the documentation/*client code to using certificates for authentication (without the need for httpd external authentication) which would also eliminate the credentials-in-environment-variables issue. Is using PKI for authentication going to be supported? If so what's the status?<br>

><br>
> Thanks in advance!<br>
><br>
> -Aaron<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</div></div></blockquote></div><br></div>