Open Stack

On Thu, May 29, 2014 at 12:59 PM, Tim Bell <Tim.Bell at cern.ch> wrote:

>
>
> A further vote to maintain compatibility . One of the key parts to a good
> federation design is to be using it in the field and encountering real life
> problems.
>
>
>
> Production sites expect stability of interfaces and functions. If this
> cannot be reasonably ensured, the federation function deployment scope will
> be very limited and remain lightly used. Without usage, the real end user
> functional gaps and additional requirements cannot be determined.
>

+1

Maintaining compatibility with OS-FEDERATION is not something we can
compromise on: backwards compatibility should be guaranteed. If we made a
terrible decision in the established groundwork that precludes solving a
use case with sufficiently high demand (and I have not seen any evidence
suggesting that to be the case), we'll have to build an alternative
solution in parallel - not redesign OS-FEDERATION.


>
>
> Tim
>
>
>
> *From:* Brad Topol [mailto:btopol at us.ibm.com]
> *Sent:* 29 May 2014 19:31
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [keystone] Redesign of Keystone Federation
>
>
>
> +1!   Excellent summary and analysis Morgan!
>
> --Brad
>
>
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet:  btopol at us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
>
>
>
> From:        Morgan Fainberg <morgan.fainberg at gmail.com>
> To:        "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>,
> Date:        05/29/2014 01:07 PM
> Subject:        Re: [openstack-dev] [keystone] Redesign of Keystone
> Federation
>  ------------------------------
>
>
>
>
> I agree that there is room for improvement on the Federation design within
> Keystone. I would like to re-iterate what Adam said that we are already
> seeing efforts to fully integrate further protocol support (OpenID Connect,
> etc) within the current system. Lets be sure that whatever redesign work is
> proposed and accepted takes into account the current stakeholders (that are
> really using Federation) and ensure full backwards compatibility.
>
> I firmly believe we can work within the Apache module framework for Juno.
> Moving beyond Juno we may need to start implementing the more native
> modules (proposal #2). Lets be sure whatever redesign work we perform this
> cycle doesn’t lock us exclusively into one path or another. It shouldn’t be
> too hard to continue making incremental improvements (agile methodology)
> and keeping the stakeholders engaged.
>
> David and Kristy, the slides and summit session are a great starting place
> for this work. Now we need to get the proposal drafted up in the new
> Keystone-Specs repository (
> https://git.openstack.org/cgit/openstack/keystone-specs ) so we can keep
> this conversation on track. Having the specification clearly outlined and
> targeted will help us address any concerns with the proposal/redesign as we
> move into implementation.
>
> Cheers,
> Morgan
>
>
> *— Morgan Fainberg*
>
>
> From: Adam Young ayoung at redhat.com
> Reply: OpenStack Development Mailing List (not for usage questions)
> openstack-dev at lists.openstack.org
> Date: May 28, 2014 at 09:24:26
> To: openstack-dev at lists.openstack.org openstack-dev at lists.openstack.org
> Subject:  Re: [openstack-dev] [keystone] Redesign of Keystone Federation
>
> On 05/28/2014 11:59 AM, David Chadwick wrote:
> > Hi Everyone
> >
> > at the Atlanta meeting the following slides were presented during the
> > federation session
> >
> > http://www.slideshare.net/davidwchadwick/keystone-apach-authn
> >
> > It was acknowledged that the current design is sub-optimal, but was a
> > best first efforts to get something working in time for the IceHouse
> > release, which it did successfully.
> >
> > Now is the time to redesign federated access in Keystone in order to
> > allow for:
> > i) the inclusion of more federation protocols such as OpenID and OpenID
> > Connect via Apache plugins
>
> These are underway: Steve Mar just posted review for OpenID connect.
> > ii) federating together multiple Keystone installations
> I think Keystone should be dealt with separately. Keystone is not a good
> stand-alone authentication mechanism.
>
> > iii) the inclusion of federation protocols directly into Keystone where
> > good Apache plugins dont yet exist e.g. IETF ABFAB
> I though this was mostly pulling together other protocols such as Radius?
> http://freeradius.org/mod_auth_radius/
>
> >
> > The Proposed Design (1) in the slide show is the simplest change to
> > make, in which the Authn module has different plugins for different
> > federation protocols, whether via Apache or not.
>
> I'd like to avoid doing non-HTTPD modules for as long as possible.
>
> >
> > The Proposed Design (2) is cleaner since the plugins are directly into
> > Keystone and not via the Authn module, but it requires more
> > re-engineering work, and it was questioned in Atlanta whether that
> > effort exists or not.
>
> The "method" parameter is all that is going to vary for most of the Auth
> mechanisms. X509 and Kerberos both require special set up of the HTTP
> connection to work, which means client and server sides need to be in
> sync: SAML, OpenID and the rest have no such requirements.
>
> >
> > Kent therefore proposes that we go with Proposed Design (1). Kent will
> > provide drafts of the revised APIs and the re-engineered code for
> > inspection and approval by the group, if the group agrees to go with
> > this revised design.
> >
> > If you have any questions about the proposed re-design, please don't
> > hesitate to ask
> >
> > regards
> >
> > David and Kristy
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140529/ce9415fe/attachment.html>