Open Stack

Good and valid points,

Here are my thoughts:
a) delegation would be what we're looking to do with nova and zones right now as per Sandy's note: http://wiki.openstack.org/FederatedAuthZwithZones. Oauth 2.0 has been proposed as a more complete solution eventually.
b) yes.
c) yes. http://wiki.openstack.org/FederatedAuthZwithZones solves for existing nova rbac/roles with action and resource groups.
d) agreed. Ideally we would also like the front-end and private interfaces pluggable as well. Otherwise, supporting things like certificate auth would be difficult. All depends on how much we can get done in 1-2 week iterations, but on board with the design principle.
e) javascript developers are also looking for that. It's one driver for a ReSTful API. It's what we would prefer to build, but as long as the service is pluggable we should be able to support other protocols.

Thanks for your input,
Ziad

On Apr 18, 2011, at 9:50 AM, <ksankar at doubleclix.net<mailto:ksankar at doubleclix.net>> wrote:

Ziad,
    Excellent, a separate authC/authZ service is a good idea. And I can see that you have built-in extensibility - an important aspect for enterprise deployments. Couple of quick thoughts:

    a)    Would the lightweight delegation include delegated administration as well as operational role ?
    b)    SAML would be another protocol to support, especially for enterprises
    c)    Looks like the first order of business is to refactor the authC/authZ as a separate service and then add features. If so, most probably the delegation and rbac/roles need to be the first ones as they are fundamental to rest of the services.
    d)    I know that you have pluggable backend. Pl make sure the datastore is separate and that there is an interface layer - direct call to DB and SQL manipulations should be avoided. If this interface could be abstracted well enough, developing plugins should be relatively easier and this will lower the barrier for enterprise adoption.
    e)    IMHO, REST APIs over JSON would be a good choice for any North facing interfaces

Cheers
<k/>
-------- Original Message --------
Subject: [Openstack] Proposing an Identity Service in OpenStack (a.k.a.
Auth)
From: Ziad Sawalha <ziad at sawalha.com<mailto:ziad at sawalha.com>>
Date: Mon, April 18, 2011 4:42 am
To: "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>

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<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110418/fdc64e38/attachment.html>