Any C coders want to help me with something?

[Stephen John Smoogen]

On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath <mmcgrath at redhat.com> 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"