<div dir="ltr">I think delay_denial will have to be maintained for awhile for backwards compatibility no matter what happens.<div><br></div><div>I think existing auth middlewares can and often do reject requests outright without forwarding them to swift (no x-auth-token?).</div>
<div><br></div><div><div>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?</div>
</div><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>-Clay</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 23, 2013 at 1:49 AM, David Hadas <span dir="ltr"><<a href="mailto:david.hadas@gmail.com" target="_blank">david.hadas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi, <br><br>Starting from 1.9, Swift has get_info() support allowing middleware to get container and/or account information maintained by Swift.<br>
Middleware can use get_info() on a container to retrieve the container metadata. <br>
In a similar way, middleware can use get_inf() on an account to retrieve the account metadata.<br><br>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. <br>
<br>Qs:<br>1. Should we document this approach as another way to do auth in Swift (currently this option is not well documented)<br> See <a href="http://docs.openstack.org/developer/swift/development_auth.html" target="_blank">http://docs.openstack.org/developer/swift/development_auth.html</a>:<br>
"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__()?<br><br>2. What are the pros and cons of each of the two options? <br>
What benefit do we see in an AUTH system using delay_denial over deciding on the authorization upfront? <br> Should we continue use delay_denial in keystone_auth, swauth? <br><span class="HOEnZb"><font color="#888888"><br>
DH<br> </font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>