Open Stack

I think delay_denial will have to be maintained for awhile for backwards
compatibility no matter what happens.

I think existing auth middlewares can and often do reject requests outright
without forwarding them to swift (no x-auth-token?).

I think get_info and the env caching is relatively new, do we have
confidence that it's call signature and data structure will be robust to
future requirements?  It seems reasonable to me at first glance that
upstream middleware would piggy back on existing memcache data, middleware
authors certainly already can and presumably do depend on get_info's
interface; so i guess the boat already sailed?

I think there's some simplicity gained from an auth middleware
implementor's perspective if swift specific path parsing and and relevant
acl extraction has a more procedural interface, but if there's efficiency
gains it's probably worth jumping through some domain specific hoops.

So it's certainly possible today, but if we document it as a supported
interface we'll have to be more careful about how we maintain it.    What's
motivating you to change what's there?  Do you think keystone or swauth
incur a measurable overhead from the callback based auth in the full
context of the lifetime of the request?

-Clay



On Tue, Jul 23, 2013 at 1:49 AM, David Hadas <david.hadas at gmail.com> wrote:

> Hi,
>
> Starting from 1.9, Swift has get_info() support allowing middleware to get
> container and/or account information maintained by Swift.
> Middleware can use get_info() on a container to retrieve the container
> metadata.
> In a similar way, middleware can use get_inf() on an account to retrieve
> the account metadata.
>
> The ability to retrieve container and account metadata by middleware opens
> up an option to write Swift Auth systems without the use of the Swift Delay
> Denial mechanism. For example, when a request comes in ( during
> '__call__()' ), the Auth middleware can perform get_info on the container
> and/or account and decide whether to authorize or reject the client request
> upfront and before the request ever reaching Swift. In such a case, if the
> Auth middleware decides to allow the request to be processed by Swift, it
> may avoid adding a swift.authorize callback and thus disabling the use of
> the Swift delay_denial mechanism.
>
> Qs:
> 1. Should we document this approach as another way to do auth in Swift
> (currently this option is not well documented)
>      See http://docs.openstack.org/developer/swift/development_auth.html:
>       "Authorization is performed through callbacks by the Swift Proxy
> server to the WSGI environment’s swift.authorize value, if one is set."
> followed by an example how that is done. Should we add description for this
> alternative option of using get_info() during __call__()?
>
> 2. What are the pros and cons of each of the two options?
>      What benefit do we see in an AUTH system using delay_denial over
> deciding on the authorization upfront?
>      Should we continue use delay_denial in keystone_auth, swauth?
>
> DH
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/85b8a538/attachment.html>