Whomever is driving design on this should drop me a line at
jan.dr...@disney.com. We are going to open source our oauth solution to
openstack.
Jan Drake
Principal Cloud Architect
The Walt Disney Company
On Jul 22, 2011, at 3:59 PM, "Kevin L. Mitchell" <kevin.mitch...@rackspace.com>
wrote:
> Keystone integration on the server side of our services is relatively
> straightforward: you pull the auth_token middleware in, add an
> appropriate middleware, if necessary, for for the actual integration,
> and you get the unified keystone authentication.
>
> So far as I know, however, we have not really looked at keystone
> integration into our client tools. This is a harder problem because
> each tool uses its own framework, and none of the frameworks really have
> the concept of a middleware that would be useful in this context.
> Additionally, we have to deal with the problem both at an API level and
> at a CLI level.
>
> I've been thinking about this problem today, and I have a possible
> approach that I'd like to put out there for discussion. The idea is
> that we create a single, uniform plugin that would integrate with
> keystone--and of course if you want to use some authentication system
> other than keystone, all you need to do is switch out that one plugin.
> The plugin centralizes all the logic necessary to perform the
> authentication, and advertises:
>
> 1. The information it needs to do its job (username, tenant,
> password, auth URL, whatever)
> * We can use this information to automatically build
> command-line arguments for CLIs
> 2. The information it provides once the authentication has been
> performed (base URL for the service, authentication token, etc.)
> 3. The translations it needs to perform on the outgoing requests to
> do its job
>
> This third item is the most complex, of course, since potentially a
> plugin may need to inject headers ("X-Auth-Token"), rewrite the URL,
> rewrite the request body, catch a authentication-related status code,
> even potentially resubmit an operation after having retrieved updated
> authentication information.
>
> The authentication plugin would work with an object provided by the
> client which would tell the plugin what it needs to know about the
> client, such as the service name to look up the base URL for, as well as
> providing an interface for submitting requests to arbitrary URLs (so we
> can avoid reinventing the wheel or pulling in external client
> frameworks). It would also have the interface necessary for
> resubmitting an operation that the plugin has hooked based on an
> authentication-related status code.
>
> Thoughts? Comments?
> --
> Kevin L. Mitchell <kevin.mitch...@rackspace.com>
>
> This email may include confidential information. If you received it in error,
> please delete it.
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
