Re: [openstack-dev] V3 Authentication for swift store
Jamie - thanks for the link to your blog. I remember the Paris discussion :) And also noted the Vancouver discussion re. SDK not necessarily being targeted at service-service interactions. I sense there is renewed desire to maintain improve swiftclient, and a few of us are interested in looking into the session support (but lacking free cycles right now :/). We need to figure out a nice way to maintain the v1 auth mode as and when sessions comes into the Connection - there was a very brief conversation in Vancouver around maybe encapsulating the v1 auth in a keystone-session-like object. Alistair -Original Message- From: Jamie Lennox [mailto:jamielen...@redhat.com] Sent: 19 June 2015 02:27 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] V3 Authentication for swift store - Original Message - From: Alistair Coles alistair.co...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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:jamielen...@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/ _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] V3 Authentication for swift store
- Original Message - From: Alistair Coles alistair.co...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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:jamielen...@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/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] V3 Authentication for swift store
-Original Message- From: Jamie Lennox [mailto:jamielen...@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 snip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
