Any C coders want to help me with something?

[Mike McGrath]

On Wed, 29 Apr 2009, Axel Thimm wrote:

> On Wed, Apr 29, 2009 at 01:03:03PM -0500, Mike McGrath wrote:
> > > >> Well normally what I have seen is that the 'FAS' server would export a
> > > >> schema table to LDAP and LDAP would then be what is authenticated to
> > > >> (the same with Kerberos if combined). Or the FAS server has a
> > > >> mysql/postgres background and someone uses pam/mod mysql to do it.
>
> > > Sorry for butting in like this, but I always assumed FAS would use LDAP
> > > as a backend, so that 3rd parties, if they wanted to plug in to the
> > > system, would utilize LDAP.  Is that not the case?
> >
> > Correct, that's not the case.  Instead of LDAP we have a postgres backend
> > and use json to auth, third parties use python-fedora to authenticate.  We
> > tried pretty hard to get LDAP working with our account system but ran into
> > many problems and decided to go back to postgres.
>
> I'd third the LDAP love here, e.g. either a read-only cron'd export to
> LDAP or rewriting the FAS backend for LDAP. Any future tool you may
> want to attach to FAS will most probably have LDAP support out of the
> box, but any other kind of authentication would need special coding
> (like your pam module request), which is both time consuming and a
> security risk if not written properly.
>

We worked pretty closely with different LDAP teams and the way FAS works
is just not very... ldapian.  Although it's only some internal stuff that
we need (specifically related to our user/sponsor/admin bits in each
group.

As far as actually using FAS to do stuff, it's quite possible that we can
use LDAP there for things.  I think:

http://www.darold.net/projects/ldap_pg/HOWTO/

Is worth getting up and running to see.  If it turns out to be cumbersome,
then perhaps a cronned job is all that's available.

	-Mike