settingsLogin | Registersettings

[openstack-dev] [keystone] Redesign of Keystone Federation

0 votes

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
ii) federating together multiple Keystone installations
iii) the inclusion of federation protocols directly into Keystone where
good Apache plugins dont yet exist e.g. IETF ABFAB

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.

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.

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

asked May 28, 2014 in openstack-dev by David_Chadwick (3,360 points)   3 4
retagged Jan 28, 2015 by admin

9 Responses

0 votes

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
responded May 28, 2014 by Adam_Young (19,940 points)   2 7 12
0 votes

-----Original Message-----
From: Adam Young [mailto:ayoung at redhat.com]
Sent: 28 May 2014 18:23
To: 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

Getting some working clients for the existing implementation would also be very desirable :-)

I would hope that any re-design would retain backwards compatibility for those of us who are deploying.

Tim

responded May 28, 2014 by Tim_Bell (16,440 points)   1 8 10
0 votes

Hi David and Kristy,

looking at the slides it is not clear to me why you need to have
an authn plugin for each Apache plugin. I have experience only with
few Apache plugins and they provide the possibility to customise the attributes
for the application behind. As an example, with mod_shib it is possible
to define how the information coming from the IdP should be provided
to the application. Maybe this is not possible with all plugins but
I am wondering if it is possible the other way around. In other words,
to create only a configurable authn plugin for all apache plugin. In the configuration
you should provide the name of the attributes to look at and the mapping
with the Keystone attributes.

BTW: design 2 seems better although requires more work.

Cheers,
Marco

On Wed, May 28, 2014 at 04:59:48PM +0100, 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
ii) federating together multiple Keystone installations
iii) the inclusion of federation protocols directly into Keystone where
good Apache plugins dont yet exist e.g. IETF ABFAB

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.

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.

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

--
====================================================
Eng. Marco Fargetta, PhD

Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy

EMail: Marco.Fargetta at ct.infn.it
====================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5483 bytes
Desc: not available
URL:

responded May 28, 2014 by Marco_Fargetta (1,020 points)   1
0 votes

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
responded May 29, 2014 by Morgan_Fainberg (17,320 points)   2 6 9
0 votes

+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)"
,
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded May 29, 2014 by Brad_Topol (2,080 points)   2
0 votes

On Thu, May 29, 2014 at 12:59 PM, Morgan Fainberg <morgan.fainberg at gmail.com
wrote:

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.

I can't tell from the linked slides what exactly will change. When a spec
is proposed I'd love to see at least the following things:

  • A description/diagram of the layers and how data flows between them.
  • A description/diagram showing structural code changes that need to
    happen to support the proposal.
  • A breakdown of user facing changes for things that can't be completely
    backward compatible.

The talk at the summit seemed to revolve around a few methods and a class
that had SAML in the name. I think some of the recent work is making this
more generic and there is at least one proposal to add protocols. It would
be nice to see why this refactoring isn't enough.

--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded May 29, 2014 by dstanek_at_dstanek.c (2,440 points)   1 2
0 votes

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.

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<mailto:morgan.fainberg at gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)" >,
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
responded May 29, 2014 by Tim_Bell (16,440 points)   1 8 10
0 votes

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)"
,
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:

responded May 29, 2014 by Dolph_Mathews (9,560 points)   1 2 3
0 votes

Hello,

For what it is worth I was toying around with the possibility to extend the federation mapping mechanism to be used with keystone's external auth plugin. I believe this would allow easy, immediate and generic support of other federation protocols through apache mods without the need to write specific auth plugins unless it is needed.
I've pushed a very early PoC on this and given some basic guidelines to make it work with OpenID here:

I'd be happy to get some feedback and push work forward on it if it can be of any use to the project. Let me know what you think !

Regards

Matthieu Huin

mhu at enovance.com

----- Original Message -----
From: "David Chadwick" <d.w.chadwick at kent.ac.uk>
To: "OpenStack Development Mailing List"
Sent: Wednesday, May 28, 2014 5:59:48 PM
Subject: [openstack-dev] [keystone] Redesign of Keystone Federation

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
ii) federating together multiple Keystone installations
iii) the inclusion of federation protocols directly into Keystone where
good Apache plugins dont yet exist e.g. IETF ABFAB

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.

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.

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
responded May 30, 2014 by Matthieu_Huin (280 points)   1
...