On Thu, May 29, 2014 at 12:59 PM, Tim Bell <tim.b...@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:bto...@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: bto...@us.ibm.com > Assistant: Kendra Witherspoon (919) 254-0680 > > > > From: Morgan Fainberg <morgan.fainb...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 ayo...@redhat.com > Reply: OpenStack Development Mailing List (not for usage questions) > openstack-dev@lists.openstack.org > Date: May 28, 2014 at 09:24:26 > To: openstack-dev@lists.openstack.org openstack-dev@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev