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.gerr...@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.ha...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
