Open Stack

Yes, token auth and HTTP basic w/ SSL ended up being good options: http://bazaar.launchpad.net/~khussein/swift/authn/revision/143/swift/auth/basicauth.py

Open to other suggestions if anyone has an elegant Anyscale auth solution.

Thanks - 

Z

On Apr 18, 2011, at 12:15 PM, 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 at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>