On Wed, 03 Aug 2011 15:17:13 +0100
Mark McLoughlin <markmc(a)redhat.com> wrote:
== Option 1. Shared Identity Store ==
With LDAP configured, both Image Factory and IWHD would be able to
authenticate a username/password against an LDAP server. Where Conductor
has local DB users, they could authenticate against Conductor using HTTP
authentication.
HTTP has several authentication modes: Basic, Digest, Negotiate.
In order for this to work, anything (e.g. aeolus-image or Conductor)
talking to Image Factory or IWHD needs the user's password. So, for
example, if Conductor is to list images in IWHD it would need to retain
the user's password in plain text.
You are assuming that Conductor has the password, whereas it's not
necesserily the case - it is only true if HTTP Basic is used between
Conductor's clients and Conductor. If Kerberos with GSSAPI used to
authenticate Conductors's clients in Conductor through HTTP Negotiate,
Conductor does not have the plaintext. I think HTTP Digest permits
Conductor and its clients authenticate using a shared secret which
is not necesserily the password (may be password's hash), and if that's
salted, it would be different for IWHD's shared secret.
This looks like a case for delegated credentials. Or Option 2.
In the longer term, GSSAPI would be used by all and a single
Kerberos
ticket would be used to authenticate the user against all three.
Well yeah... Except that perhaps it's not as long a term as you hope,
unless you mandate HTTP Basic.
== Option 2. Identity Delegated to Conductor ==
Instead, they would use two-legged OAuth to authenticate Conductor
itself. Conductor would share a secret with Image Factory and IWHD, and
they would be configured to only allow requests that can prove (using
OAuth) knowledge of that shared secret.
You know, if you used Kerberos to authenticate Conductor, my existing
patch (and its test harness) would work.
There are at least two options to achieve that. The second option
feels
right to me, but the implications are non-trivial. The first option
makes more sense where Kerberos is in use.
I say Option 2 and ship at least something working before every customer
has installed OpenStack or something.
-- Pete