openstack team mailing list archive

[Jan Drake <jan_drake@xxxxxxxxxxx>]

Whomever is driving design on this should drop me a line at jan.drake@xxxxxxxxxx.  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.mitchell@xxxxxxxxxxxxx> 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.mitchell@xxxxxxxxxxxxx>
> 
> This email may include confidential information. If you received it in error, please delete it.
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>