On 08/03/2011 10:40 AM, Mark McLoughlin wrote:
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
> On 07/29/2011 11:58 AM, Martyn Taylor wrote:
>> - support authentication against external LDAP
>> - provide authentication mechanism across aeolus components
>> Conversation Topics
>> * 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
Using PAM is an interesting idea. It does make the app more complicated
to install and configure, though. And makes it less portable. Also, I
don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support
assuming we retain the option of using Conductor's DB as an identity
> and configure SSSD.
SSD is what would give us the identity cache, right?
Yes but not only.
The motivation there was for laptop use cases, right? i.e. where you
want to be able to authenticate a user even when you can't reach the
The motivation is mostly to abstract from different identity sources and
You can configure LDAP, AD, IPA, local files, or SSSD itself (it has
local indentity domain you are welcome to use).
The point is that your application does not need to know what is the
source. The source is configured outside the app.
> It already provides all the functionality you are talking about.
> * Local storage
i.e. authenticate against /etc/shadow ?
Not only. It has its own local user domain that you can use. It is not
> * External LDAP auth
And lots of other auth options
> * Identity cache
That's from SSD?
SSSD, you missing one S which might be confusing as there is another
project called SSD.
SSSD caches identities from remote identity sources in the local DB so
for the applications on the system is does not really matter whether the
system is connected or not and where the identities come from. It can
cache credentials too and do local authentication when disconnect from
I understand that to take advantage of SSSD one now would have to
implement PAM calls and NSS libc calls. This is limiting and not convenient.
Next year we plan to provide a D-BUS interface that will have all sorts
of bindings for different languages. I hope that switch from PAM/NSS to
this interface would be really simple and straightforward. One of the
benefits of it will be the capability to decouple the application
identity space from the OS identity space. We see that this would be a
highly desirable feature. Think about SSSD in this case as a local
instance of SiteMinder. This is the path we are going. We are not there
yet but I want to layout the direction for you so that you have all the
information to make your implementation decision and not do the work
that can be avoided.
>> * do we need UI for LDAP config (it's probably only IP + port,
>> 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
All LDAP configuration is in sssd.conf? No extra PAM, nsswitch or
aeolus-devel mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?