openstack team mailing list archive

[Ziad Sawalha <ziad@xxxxxxxxxxx>]

And here is a launchpad mirror: https://launchpad.net/keystone
<https://launchpad.net/keystone>

On Apr 26, 2011, at 5:25 PM, Ziad Sawalha wrote:

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 https://github.com/khussein/keystone/. The code includes a rudimentary token-based authentication implementation.

Included in the project (our internal code name for the project is Keystone and we're proposing that as the project name):
1 - Keystone (Identity.py): an identity and token management service with a ReSTful API
2 - Echo: a sample service that echoes back requests
3 - Two middleware components:
- one to install with the echo (or OpenStack) service that verifies incoming requests are authenticated (and redirects them is not)
- another that handles the token validation (this service can be run inline with the echo service or on a separate, remote proxy layer)

This is rough code. And, admittedly, the middleware part is hard to explain (we tried in this blueprint: http://wiki.openstack.org/openstack-authn), but we want to put this out there in the open ASAP for everyone interested to participate.

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.


Reach out to us, we look forward to meeting everyone:
- Ziad Sawalha
- Jorge Williams
- Khaled Hussein

Thanks for everyone who contributed to the code, especially Jesse and Vish for helping us be more pythonic!

Ziad


On Apr 18, 2011, at 10:15 AM, Eric Day wrote:

Looks good! I'm looking forward to the summit discussions. Beyond
pluggable backends, I would make sure other layers remain pluggable
as well (the auth mechanism, protocols to verify, etc). The use cases
I have in mind are:

* All common forms of HTTP auth.
* OpenID, OAuth, and any other open initiatives.
* Signatures (for ec2 compatibility)
* SASL mechamisms?
* AuthN/AuthZ from non-HTTP based protocols. For example the MySQL
protocol for DBaaS requires either plaintext storage of the password
(which we shouldn't do) or a custom hash.

We'll also want to decide if we need a default mechanism for
OpenStack deployments, and if so, what should it be. We had a
discussion previously and I think it was somewhere between token
and HTTP basic w/ SSL. The reason for this is we need to make sure
different deployments are compatible.

-Eric

On Mon, Apr 18, 2011 at 06:42:22AM -0500, Ziad Sawalha wrote:
 Hi Everyone,
 For OpenStack to achieve the goal of being a "massively scalable cloud
 operating system", it needs a common approach to some of the problems that
 an "operating system"deals with such as Authentication (auth-n) and
 Authorization (auth-z). There has been much discussion on the topic (see
 below) so we are proposing we combine all these efforts into a new
 OpenStack project that addresses the auth of all other projects.
 I would like to raise this for discussion at the upcoming summit in Santa
 Clara and put forward the following as a starting point for the
 discussion:
 SCOPE
 The potential scope for an auth service is huge; this is not a simple
 problem, especially when you deal with authorization and, eventually,
 usage metering. We suggest we start with a minimum viable product (MVP)
 and that the most immediate requirements that need to be addressed are
 what has already been solved for in Swift and Nova today.
 We propose to start building in (1-2 week) iterations during the Diablo
 development phase:
 * One Service: there should be one auth-n service (this does not presume
 or preclude auth-z)
 * Service is a new Core service
 * Protocol: initial implementation of Rackspace auth token
 * Anyscale: single dev machine to globally distributed
 * Integrate with Swift, Nova
 * Independent: I can run this on its own (no coupling to other services).
 Therefore can be installed and run with any services that are OpenStack
 compatible.
 TIMELINE
 Iteration 0 (1-2 weeks): MVP prototype
 * blueprint
 * We need lightweight delegation (one tenant / multiple users) on validate
 (this extends scope of what is in Rackspace and Swift, but is needed for
 Nova)
 * No delegation beyond existing Nova and Swift implementation
 * Using a Token
 * Admin is handled by "groups" (roles) - only group allowed to be returned
 is ADMIN
 * nothing as a Service for testing.
 Post MVP: iteration 2/3/...: defined from subset of backlog & feedback
 from community
 Backlog:
 * migration path from cactus
 * support for ec2 & openstack api
 * zones support
 * authz by group/role/attribute/... with pluggable Policy Engine
 * Pluggable back-end (ex: database, LDAP, Active Directory, PAM, Swift)
 * rbac / roles
 * Delegation
 * OAuth for solving 3rd party partner problem / federation
 * (Generic?) Organizational Model
 * user management API
 DESIGN SUMMIT
 * We are looking forward to starting a discussion with the community on
 how to incrementally define and execute on a common Auth system for
 OpenStack
 ADDITIONAL INFORMATION
 For reference, existing blueprints and discussions on the topic are:
 SPECS and CODE
 http://wiki.openstack.org/AuthnAuthz (spec and discussion)
 http://wiki.openstack.org/openstack-authn (spec)
 http://bazaar.launchpad.net/~anso/nova/authn_and_authz/revision/770 (auth
 service prototype)
 https://code.launchpad.net/~khussein/swift/authn (middleware proposal)
 SWIFT
 https://blueprints.launchpad.net/swift/+spec/swift-authn
 https://blueprints.launchpad.net/swift/+spec/bexar-swauth
 NOVA
 https://blueprints.launchpad.net/nova/+spec/authentication-consistency
 https://blueprints.launchpad.net/nova/+spec/nova-authn
 GLANCE
 https://blueprints.launchpad.net/glance/+spec/authentication
 BURROW
 https://blueprints.launchpad.net/burrow/+spec/openstack-auth-ldap
 Regards,
 Ziad

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp