2009-09-28 22 views

cevap

10

Kimlik yönetimi/kimlik doğrulama yönetimini üyelik yönetiminden ayırmak. "Büyük" kullanıcı tablosu, gerçek kimlik deposudur - örneğin, kimlik verilerinizi depolamak için SQL kullanmak istiyorsanız, hepsi buraya girer. Ancak kimlik deponuz olmak için başka bir kaynak - yani Active Directory - kullanmak isteyebilirsiniz. Bunun yerine kimlik ve kimlik doğrulamasını doğrularsınız, ancak yine de SQL tabanlı rol/üyelik verilerini AD tabanlı kimlik verilerine katmanın bir yolunun olması gerekir. Daha küçük masanın buraya geldiği yer bu ilişkileri korumak için yeterli bilgi.

+0

Asp.net üyeliğim için özür dilerim çünkü ihtiyaç duymadığım pek çok tabloya ihtiyacım var ve bazı şeyleri yaptığımdan beri tüm yerleşik yöntemi işe yaramaz hale getirdim. Bu yüzden verileri böyle bölmek mi yoksa tek bir masaya yapıştırmak mı diye anlamaya çalışıyorum. Önerilen yaklaşım nedir? – chobo2

+1

@ Chobo2 ihtiyaçlarınızı bilmeden söylemek zor. Ancak, ASP.NET sağlayıcınız ihtiyacınız olan her şeyi yaparsa ve ihtiyacınız olmayan bir şey yaparsa, bununla kalmak isteyebilirsiniz. Kendinizi inşa etmek, daha iyi şeyler için harcayabileceğiniz bir maliyettir. Ancak, ihtiyacınız olan bazı özel işlevler varsa, önce sağlayıcınızı gereksiniminize göre tasarlayın. –

2

Tek bir kullanıcı veritabanından birden çok uygulamanın güvenliğini sağlamak içindir; aspnet_membership'in UserId ve ApplicationId'i vardır, böylece her kullanıcı birden fazla uygulama için farklı bir şifreye sahip olabilir (ve aynı zamanda bir uygulamadan diğerine kilitlenemez).

+2

Bu doğrudur, ancak diğer tabloda da bu bilgiler vardır, bu nedenle iki farklı tablonun neden var olduğunu yanıtlamadınız. –