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


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?

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


David and Kristy

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to