openstack team mailing list archive

["Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx>]

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.