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
