On 07/29/2011 11:58 AM, Martyn Taylor wrote:
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
* LDAP Support:
* Conductor auth against LDAP with local DB Fallback
* conductor first tries authenticate user against external LDAP
server. If user is found there, user account in local db is created
(except credentials) if it doesn't exist yet. If user is not found in
LDAP, local db is searched.
I wonder why reinvent the wheel. Can you use local pam stack for
authentication and configure SSSD.
It already provides all the functionality you are talking about.
* Local storage
* External LDAP auth
* Identity cache
We will be providing a special interface down the road but for now
simple wrappers around pam and nss calls would allow you to save you a
lot of time.
Do you want to explore it more?
* Keep Consistent With Katello
* This means Using DB as initial resource and falling back to LDAP
SSSD handles this.
* if admin deletes a LDAP user in admin section, user is
only from local db, but this user can login again (as she will be
authenticated against LDAP)
* user listing in conductor - shoud we list only local users or
SSSD can create unified lists across local and LDAP domains if you
really need the list.
It can also return you groups and group membership for your access
* do we need UI for LDAP config (it's probably only IP +
maybe LDAP domain), if so we will need some table for saving
configuration (we don't have this yet)
If you go with SSSD it is not needed. Everything goes to sssd.conf
* should be LDAP server setup part of aeolus-configure script?
don't think so.
This is a big question but if you set SSSD your test scripts then can
add local users to it do a dry run and test even withouth the external
* but we should probably have something in aeolus-configure to
conductor/etc aware of the ldap store
* IWHD Auth against:
IWHD authenticating against Conductor does not make sense. It
against some identity source. Conductor is not a source. If we are
talking about IWHD connecting to Conductor then it depends how it
connects but I am not sure if this connection exsts. This is something
still not clear from other discussions on the list.
* warehouse should know about same set of users as conductor? No
IMO there is a big overlap between those so I would say yes. The store
should be in general the same. Just different groups within same
organization or community.
* warehouse is going to support GSSAPI. So if someone is
authenticating to warehouse, identity check should be done against
Against IPA. GSSAPI gives you Kerberos SSO.
User authenticates against IPA and gets ticket to access IWHD.
Same should be generally with any component.
It is all covered on the diagrams that I sent a month ago however there
was not discussion or agreement about hose so I do not know if everybody
on the same page about it. It looks like it is not the case so far.
It can be done using LDAP but then you would have to provide you
password on every command.
* Should IWHD and imagefactory users be independent
No. In context of the combined solution users come from one identity
source (at least for v1)
* should IWHD authenticate always against conductor or against
or other resource? if not against conductor local db users won't have
access to iwhd
It looks like there is a lot of confusion. Can we have a meeting about it?
* Should ImageFactory Authenticate users?Yes
It depends. If IF does not expose CLI/UI directly then may be no.
We need to agree on the diagrams I sen a month ago before we can answer
John, Hugh, should we have a formal review meeting?
* Authentication across components
Diagrams are about it...
* Use OAuth?
* Already Support By Katello
* supports OAuth (two-legged), so it's not a problem for conductor
to be a 'consumer' of Katello service and use two-legged OAuth too (in
case conductor will use Katello as a service)
* OAuth Providers:
* Will IWHD Support OAuth as well as GSSAPI?
* OAuth Clients
* if iwhd supports only GSSAPI (and should authenticate against
conductor) then conductor should act as GSSAPI server. Also user creds
in image build process will have to be passed through
Oh... Let us have a review... please!
* any other alternative to OAuth?
Before we move to the actions and tasks we should agree on the architecture.
* Add LDAP support in conductor
* Update authentication model to auth againsts LDAP id available
* Create non existing users to local db
* Add OAuth Provider Support to
* Add OAuth Client Support to
* Add Deps to componets and fedora
* gem used in conductor for ldap auth, could be part of some more
sophisticated gem (devise, omniauth)
* oauth, gssapi libs
aeolus-devel mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?