والتي المصادقة والتخويل مخططات تستخدم و لماذا ؟

Question

بدأنا تصميم مجموعة كاملة من الخدمات الجديدة إلى إنشاء (صندوق رأس المال العامل ، ADO.NET خدمات البيانات ، وربما في سحابة في بعض نقطة) واحد السؤال الذي ينبثق هو ما المصادقة والتخويل مخطط لاستخدام - هناك عدد قليل جدا!

نحن في الأساس تحتاج إلى أن تكون قادرة على تحديد المستخدمين (الناس الفعلية ، و "الظاهري" التطبيق/الخدمة المستخدمين) على مجموعة واسعة من بروتوكولات HTTP, HTTPS, TCP و نحن بحاجة إلى تعيين لهم على الأقل مجموعة من الأدوار / إذن أن نرى بعض البيانات و/أو عمليات معينة.

ونحن بالتأكيد لا يمكن أن تستخدم ويندوز عضوية المجموعة وحدها - لدينا الكثير من الخارجية المستهلكين من الخدمات التي نقدمها و نحن لا نريد أن يكون لديك لإنشاء حساب المجال في المجال الداخلي لكل منهم.

لذلك هناك أساسا ثلاثة خيارات ، أعتقد:

1. باستخدام ASP.NET نظام عضوية - إنشاء مستخدمين وتعيين الأدوار هناك
2. استخدام أزمان (إدارة التخويل) والتي يبدو أن يكون أكثر دقة وأكثر نضجا ، وأكثر تفصيلا النظام (مع المستخدمين, المهام, مجموعات - ثلاثة مستويات ، ليس فقط المستخدم + أدوار)
3. لفة الخاصة بنا

أولا وقبل كل شيء - الذي من هؤلاء الثلاثة تنصحين ؟ أي لماذا ؟

ثانيا - هل هناك المزيد من الخيارات التي أنا في عداد المفقودين ؟

شكرا على أي تلميحات المؤشرات والآراء!

مارك

PS:رؤية إجابات حتى الآن أنا مندهش من كمية من الناس التصويت على الخيار رقم 3.أنا أعتقد أن مايكروسوفت سوف تكون قادرة على تصميم شيئا قابلة لإعادة الاستخدام التي يمكن التعامل مع كل هذه المتطلبات....

Answer 1

في الحقيقة الجواب هو على الأرجح مزيج من 1 و 3.

يمكنك الاستفادة من الكثير من الأدوات والميزات إطار يوفر لك من خلال كتابة عضوية, دور أو الملف الشخصي مزود إذا الخيارات الافتراضية لا تذهب بعيدا كما كنت ترغب.

لقد فعلت ذلك فقط على عدد من المواقع العميل - على سبيل المثال أحد عملائنا معظم المستخدمين المخزنة على ملقم التجارة المستخدمين ، واستخدام التجارة الخادم الشخصي ، كتب عضوية الشخصي مزود التحدث تلك مخازن البيانات - إلى حد ما بسيطة كسسيرسيسي.

---

معظم الناس على الأرجح لمدة 3 بسبب الحاجة إلى المصادقة على الخام TCP - هذا يدخل طبقة أبعد من ذلك القياسية ASP.NET موفري العضوية.

معظم ما MS تنتج "موافق" أو "جيدة بما فيه الكفاية", ولكن سيكون هناك دائما حالات الحافة حيث كنت تريد أن تفعل شيئا "ليس تماما القياسية" التي تعني في نهاية المطاف المتداول الخاصة بك.أعتقد أن يكون شيء بعده "المصادقة الأساسية" أو "مصادقة Windows" التي كانت بسيطة بالنسبة متوسط المطور فهم أخذوا معقولة خيار "يتيح فقط بناء هذا على شبكة الإنترنت".

إذا كنت نلقي نظرة على العديد من الطرق التي يمكن المصادقة ضد خدمة WCF, سترى ما أعنيه - هذه هي مصممة للتعامل مع مختلف آليات النقل ، وبالتالي فهي أكثر تعقيدا من ذلك بكثير.

وقال الافتراضي أدوار الشخصية مقدمي محدودة إلى حد ما (الأدوار:أي التسلسل الهرمي ، لذلك تحتاج إلى التحقق من كل دور ، أو تعيين صراحة كل دور المستخدم ؛ ملامح:كل المخزنة في حقل واحد كما فاصلة فصل القيم - ليس من السهل العثور على جميع المستخدمين الذين قد حصلت على مجموعة قيمة).

Answer 2

نستخدم (3). في الواقع، ساعدتنا في مشهد التكامل للحصول على حسابات في المزامنة مع

1. العمليات التجارية
2. أنظمة أخرى (وليس كلها على نفس كومة التكنولوجيا (ASP.NET))

Answer 3

في مشروع حديثة، مددنا مزود عضوية ASP.NET (كتب مزود مخصص) بقصد استخدام بعض الضوابط القائمة على الأدلة لإدارة الأذونات. الآن بعد أن نضج المشروع بما فيه الكفاية، نجد أن الضوابط ليست مرنة بما يكفي لمتطلباتنا، وإلى حد ما أن ندمج مسار عضوية MS. المتداول المصادقة الخاصة بك إذا كان لديك الوقت المهندس المعماري بشكل صحيح سيكون الخيار الأفضل.

يبدو أن التطبيق الخاص بك هو قليلا من الهجين في أنك تخدم العملاء الداخليين والخارجيين، ولكن ربما تعطي أيضا بعض الاعتبار للدمج openid. لعملائك الخارجيين. هناك بعض عناصر التحكم OpenID ASP.NET رائعة التي تجعل من التعامل مع حسابات جديدة للعملاء الخارجيين بدون عنان. هذا بالطبع يعتمد على كيفية تقديم طلبك "العام".

Answer 4

ldap. أي واحد؟ إنه مجاني، عبرت العليا، وسهلة الاستخدام والإدارة عن بعد، لديه جسور لمخططات المصادقة الأخرى، والأرباف بمزيد من اللغات التي تعرفها موجودة ...

Answer 5

ليس أزمان من عام 2003؟

أود أن أوصي 1 أو 3. شخصيا ذهبت دائما لمدة 3. هناك الكثير من الوظائف التي لا تستخدمها 1 أو يهتم بها.

Answer 6

سأبقى بعيدا عن عظيم. ذهبنا إلى أسفل هذا الطريق مرة واحدة ولم يعجبنا قسم المدينة التي خرجنا فيها. لقد فعلنا دائما تسجيلات تسجيلات قائمة على الإعلانات التي تستخدم SID من المستخدم الحالي الرابط للمستخدم في قاعدة البيانات، ثم اتخذ الأذونات من هناك. بالنظر إلى الإعداد الخاص بك قد لا يكون هذا ممكنا (أو عمليا)، لكنني سأبقى بعيدا عن أزمان في أي حال.

Answer 7

أنا لست مطورا ASP أو .NET، لكن كولندي يقول (3). أنت حقا لا تريد أن يكون لديك تطبيق ويب للاستخدام العام أن يكون لديك أي نوع من الوصول إلى شبكة الشركات الخاصة بك، حيث تمكن أقل بكثير من وضع بيانات اعتماد المصادقة في أي مكان بالقرب من الإعلان.

Answer 8

يبدو أنك توفر أكثر من اللازم ومتوسطة جدا للتمسك بحل تكنولوجي واحد

الحل 3.

أود أن أساعد التطبيق بأكمله حول فئة مستخدم سيتعين عليك ببساطة على نموذجه بحيث يوفر لك المرونة والاستمتة اللازمة

شيء مثل:

    [ClassAttribute ( "Yordan Georgiev", "1.0.2", "20090302", "20090415" , false )]
public class User
{
    #region DomainName
    private string _DomainName;
    public string DomainName
    {
        get { return _DomainName; }
        set { _DomainName = value; }
    } //eof property DomainName 


    #endregion DomainName

    #region Status
    private int _Status;
    public int Status
    {
        get { return _Status; }
        set { _Status = value; }
    } //eof property Status 


    #endregion Status

#region Password
    private string _Password = Resources.GV.Pass; 
    public string Password
    {
        get { return _Password; }
        set {
            _Password = GenApp.Utils.Security.Encryptor.Encrypt ( value,
                GenApp.Conf.GenAppSettings.Instance.EncryptionAlgorithm );
            //debug_Password = value; //unencrypted 
        }
    } //eof property Password 


    #endregion Password 

#region ListUserRoles
        private List<UserRole> _ListUserRoles;
        public List<UserRole> ListUserRoles { get { return _ListUserRoles; } set     { _ListUserRoles = value; } }
        #endregion ListUserRoles


    #region UserSettings
    private GenApp.Conf.UserSettings _UserSettings;
    public GenApp.Conf.UserSettings UserSettings
    {
        get {
            if (_UserSettings == null)
                _UserSettings = (GenApp.Conf.UserSettings)GenApp.Conf.GenAppSettings.Instance;

            return _UserSettings; 
        }
        set { _UserSettings = value; }
    } //eof property UserSettings 

}