Open Stack

----- Original Message -----
> From: "Alistair Coles" <alistair.coles at hp.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Thursday, 18 June, 2015 4:39:52 PM
> Subject: Re: [openstack-dev] V3 Authentication for swift store
> 
> 
> 
> > -----Original Message-----
> > From: Jamie Lennox [mailto:jamielennox at redhat.com]
> > Sent: 18 June 2015 07:02
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [glance] V3 Authentication for swift store
> > 
> > Hey everyone,
> > 
> > TL;DR: glance_store requires a way to do v3 authentication to the swift
> > backend.
> > 
> > <snip>
> > 
> > However in future we are trying to open up authentication so it's not
> > limited to
> > only user/password authentication. Immediate goals for service to service
> > communications are to enable SSL client certificates and kerberos
> > authentication. This would be handled by keystoneclient sessions but they
> > are
> > not supported by swift and it would require a significant rewrite of
> > swiftclient to
> > do, and the swift team has indicated they do not which to invest more time
> > into
> > their client.
> 
> If we consider specifically the swiftclient Connection class, I wonder how
> significant a rewrite would be to support session objects? I'm not too
> familiar with sessions - is a session an object with an interface to fetch a
> token and service endpoint url? If so maybe Connection could accept a
> session in lieu of auth options and call the session rather than its
> get_auth methods.
> 
> If we can move towards sessions in swiftclient then that would be good IMHO,
> since we have also have requirement to support fetching a service token [1],
> which I guess would (now or in future) also be handled by the session?
> 
> [1] https://review.openstack.org/182640
> 
> Alistair
> 

So the sessions work is built on, and is modelled after requests.Session. It consists of two parts, the session which is your transport object involving things like CA certs, verify flags etc and an auth plugin which is how we can handle new auth mechanisms. Once coupled the interface looks very similar to a requests.Session with get(), post(), request() etc methods, with the addition that requests are automatically authenticated and things like the service catalog are handled for you. I wrote a blog post a while back which explains many of the concepts[2].

The fastest way I could see including Sessions into swiftclient would be to create new Connection and HttpConnection objects. Would this be something swift is interested in? I didn't mean to offend when saying that you didn't want to put any more time into the client, there was a whole session in Paris about how the client had problems but it was just going to limp along until SDK was ready. Side note, i don't know how this decision will be affected based on Vancouver conversations about how SDK may not be suitable for service->service communications. 

Regarding service tokens, we have an auth plugin that is passed down from auth_token middleware that will include X-Service-Token in requests which I think swiftclient would benefit from.


Jamie

[2] http://www.jamielennox.net/blog/2014/09/15/how-to-use-keystoneclient-sessions/