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 : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
