Any C coders want to help me with something?

[Axel Thimm]

On Thu, Apr 30, 2009 at 09:53:39AM -0700, Toshio Kuratomi wrote:
> Mike McGrath wrote:
> > On Thu, 30 Apr 2009, Ricky Zhou wrote:
> >> In some distant future version of FAS, I'd
> >> like to play with the idea of storing the data in LDAP while handling
> >> our group sponsorship system in postgres.
> >>
> > 
> > Ick
> > 
> heh :-)
> 
> I think ricky's approach could work but it would need planning.  The
> idea would be to increase the complexity of FAS but decrease the
> complexity for everything we deploy that needs authentication.  We'd
> want to examine that assumption in the planning phase to make sure it's
> actually true for us.
> 
> For instance, there was the thought that having cached credentials on
> our servers was preferable to what happens to when the LDAP server goes
> down.  Still a concern?

You can have slave LDAP servers, of course, and if you don't trust
their location, you can have slices of LDAP mirrored differently,
e.g. not all attributes, not all trees etc.

> We currently mask a lot of information for the privacy policy, can we do
> that with LDAP?  (Or just not put the information in there?)

Sure, there are rather fine-coarsed ACL systems in both openldap and ds.

> We let third parties (like the hosts to let packagers try building on
> ppc, x86_64, etc) use fas to get ssh keys.  Would we let them connect to
> and get that information from the LDAP server instead?

There would be no security downside compared to other retieval
solution. Absolute security is to let this be done by a trusted human.

> We let people use their normal accounts to get a subset of data for
> authenticating to their web apps while they're developing them.  Would
> we enable the same setup with LDAP?

Yes, check out the ACLs in either or the two popular projects.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20090501/280ed89d/attachment.sig>