RE: Credentials for Application use

[Mikey <mike_chan_ () hotmail com>]

This is all well and good but we are talking different authentication and 
access control boundaries. Your references refer to Microsoft technologies 
that does not necessarily apply in a large scale enterprise scenario with 
heterogeneous systems.

Sorry.

At 10:20 AM 11/05/2005 -0500, Gunnar Peterson wrote:
> Keith Brown has a good discussion of at least one of the design choices, 
> namely
> delegation vs. impersonation:
>
> http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsDelegation.html
> &
> http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsImpersonation.html
>
> -gp
>
> Quoting Gizmo <[EMAIL PROTECTED]>:
>
> > I have a similar situation in one of my applications.  The customer wishes
> > to secure the database.  Since we use a Btrieve database, the only way 
> to do
> > this is be setting an owner name on the DB, and then encrypting using the
> > owner name as the password.  However, once the DB is secured, you can't
> > access it unless you have the owner name, and giving out the owner name to
> > everyone who uses the app to access the DB pretty much defeats the whole
> > purpose of the exercise.
> >
> > The only way <I> can see to deal with this is something similar to what 
> I've
> > done in my app:
> >
> > The user provides the management console with the password to secure 
> the DB.
> > The app encrypts the password using the blowfish algorithm and a private
> > key.  It then postpends a SHA1 hash, Base64 encodes the result, and stores
> > it in three places: a local configuration file, a remote configuration 
> file,
> > and the registry.  All three stores are secured using an ACL such that only
> > the user the main server app runs under has access to the data.  In the
> > event that one of the stores is corrupted or tampered with (as 
> determined by
> > the SHA1 hash) voting logic is used to determine which stored password 
> is to
> > be discarded.
> >
> > I imagine that someone here has a better idea, and if so, I'd love to hear
> > it.
> >
> > Later,
> > Chris