On 08/04/2011 02:30 PM, Mo Morsi wrote:
>> Sorry if I'm jumping into the discussion a little late
but why are all
>> these services authenticating against each other?
>> For that matter why do we store any authentication details in the db?
>> Why not setup a single central LDAP server and have everything
>> authenticate against that, eg conductor, katello, candlepin, pulp, etc.
>> This may just be my opinion but I feel we replicate way too much data w/
>> aeolus, LDAP is meant for high performance authentication, and is simple
>> to setup and use.
> Yes but not all component really need authentication.
> As long as it is an internal component it just needs a trusted
> connection to a peer.
Thats fine, those components would be unaffected by all of this
> If we are talking about externally facing components like Conductor and
> Katello there are always two options:
> 1) Use central auth store with SSO (that would be AD or IPA as pure LDAP
> does not provide SSO) and perform operations using end user identity
> when one component needs to talk to another
If we're just talking about the web interfaces couldn't we just use a
shared cookie or similar? Then when communicating between conductor /
katello on the backend, we just need to simply pass around the current
logged in user over a trusted connection, no need for auth between those
> 2) Create a separate channel on a separate port. This connection just
> requires server to server trust. It can be OAuth, SSL, Kerberos or other
> similar technology.
I don't have much experience w/ it, but OAuth seems to be quickly
becoming a standard for these matters. Perhaps supporting OAuth logins
into conductor and katello would be a good solution?
I think you talk about 3 legged OAuth in this case or something like CAS.
I see 2 problems with this:
a) IPA would need to support OAuth or CAS. It does not. It is something
that can be done if this is the path everybody is going but this effort
is not on the road map and unstaffed
b) You loose the enterprise SSO technologies that are available. You
can't use native GSSAPI with Kerberos. Original plan was that this is
the direction so later the servers can talk to each other using Kerberos
ticket delegation or service to service Kerberos trust like S4you. Also
you forget that if you have mixed environment like AD and IPA and your
cloud infrastructure is running on the Linux machines managed by IPA you
want to have trusts between domains.
My point is that asking password at the boundary of the web app is bad.
Best would be - you authenticated into your workstation as a user and
this auth is respected across applications running in the enterprise
regardless what domain (AD or IPA you are from). IPA provides that or
works into this direction. With OAuth or other pure web based solutions
things are simpler but limiting in a longer run. But I suspect there be
a lock in into specific technology and our plans for real enterprise SSO
down the road would become unachievable.
aeolus-devel mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?