Open Stack

Hi Andy,

>From your description, I don't think we're that far apart at all.  In fact, I think we're proposing almost exactly the same thing -- at least in terms of auth.   The purpose of our blueprint is *not* to provide a framework for creating an authentication service, but rather to simply establish a protocol between an authentication system and the underlying API.  You've done the same thing.  You suggest using X-OpenStack-User to pass the user to the API, we suggest using X-Authorization -- end of the day, it's the same approach.

Sure, in our spec, we spend quite a bit talking about error conditions and special cases because we want to ensure consistency and we want to make sure that the same authentication frameworks can be used between different APIs, etc.  We also want to make sure we have the flexibility to support multiple authentication schemes.

As you suggest, though, the typical case is really simple:  you have a middleware component that understands some authentication protocol and passes the information to the rest of the system.  You can implement our spec in only a few lines a code.  Why not just standardize on the headers?  If you do so you can simply rely on our blueprint to solve the authentication part for you.

-jOrGe W.

On Dec 30, 2010, at 4:05 AM, Andy Smith wrote:

Hi Jorge,

I don't really think we are on the same page for very long, your spec goes quite far down the path of specific authorization schemes where as mine really only takes the first step.

In general the spirit seems to be the same, that we want another service to be able to handle authentication, but our approaches are rather different, where yours provides a framework for creating an authentication service, mine is simply stating the information it needs and requesting that somebody else provide it.

Whether the authentication framework is OpenID, some form of PKI, or Facebook Auth the only important part to my spec is that at some point it boils down to the information the rest of the system actually needs to determine permissions, and at current those are two things: user and project.

While the processes you've described are some of the varied ways to implement something that could sit in front of those two basic necessities I think the scope of the specs are quite different.

I personally don't think the problem is so complex as your spec describes in the majority of the cases (most people will simply put a standard authenticating proxy / middleware backended on their user / project datastore in front of the api) but I do think your spec could provide a specific implementation pattern of an authentication component as fits the needs of, for example, rackspace or some other provider with a similar scheme that sits in front of the API.

--andy

On Thu, Dec 30, 2010 at 12:37 AM, Jorge Williams <jorge.williams at rackspace.com<mailto:jorge.williams at rackspace.com>> wrote:
Hi Andy,

The delegated auth pattern in Easy API seems to match our existing blueprint for authentication in OpenStack.

blueprint: https://blueprints.launchpad.net/nova/+spec/nova-authn
spec:  http://wiki.openstack.org/openstack-authn

Have you taken a look at the blueprint?  Are we on the same page in terms of auth or are you proposing something different?

-jOrGe W.

On Dec 29, 2010, at 2:08 PM, Andy Smith wrote:

+openstack

On Wed, Dec 29, 2010 at 12:06 PM, Andy Smith <andyster at gmail.com<mailto:andyster at gmail.com>> wrote:
Heya Matt,

I was intending on writing an email to the mailing list about it (so I'll just CC it), was just going over tone with the Anso team first since I tend to come off a bit antagonistic.

The short summary is that we wanted to return "hackability" to the project, as developers the move towards API compatibility has slowly removed most of the tools we had in place to test out new features as they were being worked on, so in that way the reflection api, self-registration of services, command-line tool and general simplicity (you can explain how everything works in just a few sentences) are a solution.

Part of that hackability also meant hackability for third-parties, we wanted developers to be able to add functionality to Nova without having to go through the Nova review process and even be able package that functionality separately, this is an obvious  goal for any large entity using openstack internally where they have additional changes to make to customize their deployment.

Easy API makes up a good basis for extensibility of the project over time.

The existing APIs are still necessary to serve their purpose which is translating the intents defined by existing specifications/implementations to tasks that make sense for Nova, and should it be desirable those interfaces can easily be built on top of and decoupled (due to the delegated auth pattern) from the Easy API, the EasyCloudTestCase gives a decent example of how such a thing could be done.

In my personal opinion I see the two existing API implementations as 'compatibility' APIs where as Easy API is a direct API and much easier to understand because of it.

The relevant blueprint (read the spec, obvs): https://blueprints.launchpad.net/nova/+spec/easy-api

--andy

On Wed, Dec 29, 2010 at 11:20 AM, Matt Dietz <matt.dietz at rackspace.com<mailto:matt.dietz at rackspace.com>> wrote:
Hey guys,

I was wondering if you could answer a few questions? I get the argument that EC2 and eucatools suck, and that the OS API is incomplete/unstable. What prompted you starting down the Easy API path? Subsequently, what issues are you hoping to solve with it? From what I can see, it's the WADL-like/reflection interface that seems to be the driving force. Is this correct?
I'm curious mostly because a lot of effort has been expended with the goal of making the existing OS API the canonical one. I'm fine with a better effort, but I've been operating in accordance with the internal goal of making it work 100% like the Rackspace API so all existing bindings will "just work" if someone cares to try out Openstack. Obviously we can't continue working on parallel paths because we'll just end up fracturing the  API user-base until we can decide which API is going to stick.
I'd like to get the discussion started, and I'll be glad to take it to the blueprint (since I see you made one as of 18 hours ago) or IRC.

Thanks,

Matt


_______________________________________________
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/20101230/45422243/attachment.html>