<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">And here is a launchpad mirror: <span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 14px; "><a href="https://launchpad.net/keystone">https://launchpad.net/keystone</a></span><div><a href="https://launchpad.net/keystone"></a><div><font class="Apple-style-span" face="Calibri, sans-serif" size="4"><span class="Apple-style-span" style="font-size: 14px;"><br></span></font></div><div><div><div>On Apr 26, 2011, at 5:25 PM, Ziad Sawalha wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>As a follow-up, and to keep the  conversation moving, we've built and posted a proof of concept for the OpenStack Identity service at <a href="https://github.com/khussein/keystone">https://github.com/khussein/keystone</a>/. The code includes a rudimentary token-based authentication implementation.</div></blockquote><blockquote type="cite"><div><br>Included in the project (our internal code name for the project is Keystone and we're proposing that as the project name):<br>1 - Keystone (Identity.py): an identity and token management service with a ReSTful API<br>2 - Echo: a sample service that echoes back requests<br>3 - Two middleware components:<br><span class="Apple-tab-span" style="white-space:pre">    </span>- one to install with the echo (or OpenStack) service that verifies incoming requests are authenticated (and redirects them is not)<br><span class="Apple-tab-span" style="white-space:pre">       </span>- another that handles the token validation (this service can be run inline with the echo service or on a separate, remote proxy layer)<br><br>This is rough code. And, admittedly, the middleware part is hard to explain (we tried in this blueprint: <a href="http://wiki.openstack.org/openstack-authn">http://wiki.openstack.org/openstack-authn</a>), but we want to put this out there in the open ASAP for everyone interested to participate.<br><br>We are looking for feedback, input, contributions, and good conversations about the path forward. We're at the summit this week and available to explain, demo, hack, discuss, and collaborate with anyone interested.<br><br><br>Reach out to us, we look forward to meeting everyone:<br>- Ziad Sawalha<br>- Jorge Williams<br>- Khaled Hussein<br><br>Thanks for everyone who contributed to the code, especially Jesse and Vish for helping us be more pythonic! <br><br>Ziad<br><br><br>On Apr 18, 2011, at 10:15 AM, Eric Day wrote:<br><br><blockquote type="cite">Looks good! I'm looking forward to the summit discussions. Beyond<br></blockquote><blockquote type="cite">pluggable backends, I would make sure other layers remain pluggable<br></blockquote><blockquote type="cite">as well (the auth mechanism, protocols to verify, etc). The use cases<br></blockquote><blockquote type="cite">I have in mind are:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">* All common forms of HTTP auth.<br></blockquote><blockquote type="cite">* OpenID, OAuth, and any other open initiatives.<br></blockquote><blockquote type="cite">* Signatures (for ec2 compatibility)<br></blockquote><blockquote type="cite">* SASL mechamisms?<br></blockquote><blockquote type="cite">* AuthN/AuthZ from non-HTTP based protocols. For example the MySQL<br></blockquote><blockquote type="cite"> protocol for DBaaS requires either plaintext storage of the password<br></blockquote><blockquote type="cite"> (which we shouldn't do) or a custom hash.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We'll also want to decide if we need a default mechanism for<br></blockquote><blockquote type="cite">OpenStack deployments, and if so, what should it be. We had a<br></blockquote><blockquote type="cite">discussion previously and I think it was somewhere between token<br></blockquote><blockquote type="cite">and HTTP basic w/ SSL. The reason for this is we need to make sure<br></blockquote><blockquote type="cite">different deployments are compatible.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Eric<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Mon, Apr 18, 2011 at 06:42:22AM -0500, Ziad Sawalha wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">  Hi Everyone,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  For OpenStack to achieve the goal of being a "massively scalable cloud<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  operating system", it needs a common approach to some of the problems that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  an "operating system"deals with such as Authentication (auth-n) and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Authorization (auth-z). There has been much discussion on the topic (see<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  below) so we are proposing we combine all these efforts into a new<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  OpenStack project that addresses the auth of all other projects.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  I would like to raise this for discussion at the upcoming summit in Santa<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Clara and put forward the following as a starting point for the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  discussion:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  SCOPE<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  The potential scope for an auth service is huge; this is not a simple<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  problem, especially when you deal with authorization and, eventually,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  usage metering. We suggest we start with a minimum viable product (MVP)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  and that the most immediate requirements that need to be addressed are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  what has already been solved for in Swift and Nova today.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  We propose to start building in (1-2 week) iterations during the Diablo<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  development phase:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * One Service: there should be one auth-n service (this does not presume<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  or preclude auth-z)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Service is a new Core service<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Protocol: initial implementation of Rackspace auth token<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Anyscale: single dev machine to globally distributed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Integrate with Swift, Nova <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Independent: I can run this on its own (no coupling to other services).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Therefore can be installed and run with any services that are OpenStack<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  compatible.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  TIMELINE<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Iteration 0 (1-2 weeks): MVP prototype<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * blueprint<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * We need lightweight delegation (one tenant / multiple users) on validate<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  (this extends scope of what is in Rackspace and Swift, but is needed for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Nova)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * No delegation beyond existing Nova and Swift implementation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Using a Token<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Admin is handled by "groups" (roles) - only group allowed to be returned<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  is ADMIN<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * nothing as a Service for testing.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Post MVP: iteration 2/3/...: defined from subset of backlog & feedback<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  from community<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Backlog:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * migration path from cactus<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * support for ec2 & openstack api<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * zones support<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * authz by group/role/attribute/... with pluggable Policy Engine<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Pluggable back-end (ex: database, LDAP, Active Directory, PAM, Swift)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * rbac / roles<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * Delegation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * OAuth for solving 3rd party partner problem / federation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * (Generic?) Organizational Model<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * user management API<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  DESIGN SUMMIT<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  * We are looking forward to starting a discussion with the community on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  how to incrementally define and execute on a common Auth system for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  OpenStack<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  ADDITIONAL INFORMATION<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  For reference, existing blueprints and discussions on the topic are:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  SPECS and CODE<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="http://wiki.openstack.org/AuthnAuthz">http://wiki.openstack.org/AuthnAuthz</a> (spec and discussion)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="http://wiki.openstack.org/openstack-authn">http://wiki.openstack.org/openstack-authn</a> (spec)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="http://bazaar.launchpad.net/~anso/nova/authn_and_authz/revision/770">http://bazaar.launchpad.net/~anso/nova/authn_and_authz/revision/770</a> (auth<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  service prototype)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="https://code.launchpad.net/~khussein/swift/authn">https://code.launchpad.net/~khussein/swift/authn</a> (middleware proposal)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  SWIFT<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="https://blueprints.launchpad.net/swift/+spec/swift-authn">https://blueprints.launchpad.net/swift/+spec/swift-authn</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="https://blueprints.launchpad.net/swift/+spec/bexar-swauth">https://blueprints.launchpad.net/swift/+spec/bexar-swauth</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  NOVA<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="https://blueprints.launchpad.net/nova/+spec/authentication-consistency">https://blueprints.launchpad.net/nova/+spec/authentication-consistency</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="https://blueprints.launchpad.net/nova/+spec/nova-authn">https://blueprints.launchpad.net/nova/+spec/nova-authn</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  GLANCE<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="https://blueprints.launchpad.net/glance/+spec/authentication">https://blueprints.launchpad.net/glance/+spec/authentication</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  BURROW<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  <a href="https://blueprints.launchpad.net/burrow/+spec/openstack-auth-ldap">https://blueprints.launchpad.net/burrow/+spec/openstack-auth-ldap</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Regards,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  Ziad<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">More help   : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">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">https://launchpad.net/~openstack</a><br>More help   : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></div></blockquote></div><br></div></div></body></html>