Open Stack

Clay, It sounds like a bad idea to remove delay_denial support (at least in
the near term).

Authorizing up front seem to have certain advantages:
1. Flexibility - as it allows authenticating based on any attribute
returned from the get_info() (without changes to Swift).
2. Security - a single point of control (unlike delay_denial in which we
need to maintain the co-play between Auth middleware(s) and Swift to be bug
free to be secure).
Performance and overhead are not the issue here.

The get_info() signature was designed to be somewhat extendable and future
proof in the sense that it returns a dictionary - allowing us to add
attributes as needed. And once it is used by middleware, we can use it in
auth middleware as well.

We may document that additional option + the pros and cons of
using delay_denial and vs. using get_info() upfront. Auth system developers
may take per auth system decision if it makes sense at some point to make
changes.

DH


On Tue, Jul 23, 2013 at 9:16 PM, Clay Gerrard <clay.gerrard at gmail.com>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20130724/d3edd495/attachment.html>