On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath <mmcgrath@xxxxxxxxxx> wrote: > On Thu, 30 Apr 2009, 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? >> >> 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?) >> >> 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? >> >> 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? >> > > I figure we're still very much in the exploritory stage, we should get our > requirements together though. FAS going down is still a real concern, but > if we implement a hardware key system, like yubikey, we'll have a similar > requirement in that yubikey requires a yubiserver of some kind (or the AES > key on every server). Normally there will need to be a prcedure to deal with such failures. Who to contact, how they log it, what methods are used for 'all-things-failed' access (usually a one-time-password that is changed afterwords), how to log actions and how to set things right again. This is more of a person fix versus technological fix. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
