تطبيق الويب - مصادقة المستخدم عبر المجالات

Question

لقد اقترب منا عميلنا لتطوير تطبيق ، وكما هو معتاد ، ينمو النطاق يومًا بعد يوم.

في البداية ، بدأ تطبيقًا مخصصًا محصوراً في شبكة الشركات الخاصة بهم. تم إنشاء مصادقة المستخدم عن طريق تناول تسجيل الدخول إلى Windows للمستخدم واستخدام قاعدة بيانات SQLServer لاستضافة حقوق الوصول. كل شيء مستقيم جدا إلى الأمام.

يريدون الآن ما يلي:
- التطبيق ليكون على شبكة الإنترنت
- طلب يمكن استضافته خارج شبكة الشركات
- مصادقة المستخدم للعمل بنفس الطريقة (لا تستخدم كلمات المرور ، فقط تسجيلات ويندوز)

لمزيد من تعقيدها ، يريدون أن تكون الوظائف المختلفة للتطبيق قابلة للاستخدام من خلال تطبيق آخر يطلق فقط من طلبات HTTP.
- يقوم المستخدم بتسجيل الدخول إلى شبكة الشركات
- يقوم المستخدم بتشغيل تطبيق الشركة
- يعالج المستخدم تفاصيل العميل
- ينقر المستخدم على زر
- تطبيق الشركات يطلق طلب HTTP إلى تطبيق الويب المستضاف الخاص بنا
- يتضمن طلب HTTP المصادقة اللازمة وتفاصيل العميل
- تم إكمال مصادقة المستخدم "تلقائيًا" (لا توجد مشاركة بشرية)
- يتم إرسال بيانات العميل بشكل آمن

إنهم حريصون جدًا على القيام بذلك من أجلهم لأن نهجنا الأولي كان ما يريدون. إنهم ما زالوا يريدون منا القيام بذلك على الرغم من أن تطبيقات الويب المستضافة هذه ليست خاصة بنا. لذلك أنا الآن أقترب من الخبراء.
- هل لدى أي شخص أي نصيحة حول كيفية التعامل مع هذا؟
- هل لدى أي شخص أي تحذير بشأن المزالق المحتملة لتجنب؟

Answer 1

في الأساس يتحدثون عن الوصول الموحدين. ستستضيف نقطة مصادقة داخل شبكتها والتي بدورها تُقدم رمزًا إلى تطبيقك الذي يمتلكه ويسمح (أو يتوقف عن الوصول). هذا قياسي إلى حد ما ، ويوفر MS قاعدة جيدة لهذا في إطار جنيف. سيعمل هذا أيضًا لمكالمات خدمة الويب التي بشرط أن يتمكنوا من تغيير تطبيقاتها لاستخدام WSFED كبروتوكول والتحدث إلى خدمة رمزية أمان تصدر بصمت رمز المصادقة. في معظم الحالات ، ستستخدم SAML لهذا الغرض. كما أنه يحتوي على مكافأة إضافية لتفاصيل المصادقة التي لا تخرج من شبكة الشركات الخاصة بهم.

يعد اقتراح المصادقة القائمة على الشهادة مقترحًا مثيرًا للاهتمام ، ولكنه يتطلب المزيد من العمل في طرح بنية تحتية PKI. هذا يمكن أن يكون مكلفا.

لن تعمل Cardspace - إنها ليست صامتة كما يبدو أنها تريد. OpenID هو غير بداية ، إنه ليس صامتًا أيضًا.

نقاط إضافية إذا كنت تبحث عن Azure - تستخدم أجزاء المصادقة من Azure أيضًا Saml/WSFED تحت الغطاء ، ولديها أجزاء من جنيف. لذا ، إذا انتقلت إلى السحابة ، فسيتعين على كل من عملائك فقط تكوين صفحة تسجيل دخول داخل شبكتهم - كل ما عليك فعله هو الثقة في تلك الصفحة لإصدار رموز المصادقة لك وتحليلها وفقًا لقواعدك.

Answer 2

ربما Communciation WCF مع المصادقة القائمة على الشهادة ، أي للمستخدمين الخارجيين الذين يستخدمون الخدمة التي توفرها لهم الشركة شهادة صالحة. هذا لن يتطلب بعد ذلك كلمة مرور اسم مستخدم ولكن خذ المستخدم مباشرة.

Answer 3

هل ألقيت نظرة بالفعل على سمل?

Answer 4

الدفع Windows Cardspace نظرًا لأنه يتكامل مع تسجيل دخول Windows الخاص بك ويسمح لسيناريو SSO الذي يتطلبه.

Answer 5

اعتمادًا على كيفية بناء تطبيقك ، يمكنك أن تملأ مع مفتاح Machine في الويب الخاص بك. قد يتضمن ذلك تطبيق ASP.NET صغير داخل شبكة الشركات لمجرد الخروج من الرموز المميزة للمصادقة وإعادة توجيه التطبيق الخاص بك.

إذا شارك التطبيقان نفس مفتاح MachineKey ، فسيسمح نظام مصادقة ASP.NET للمستخدمين بسعادة في تطبيقك المستضاف.

هناك مشاكل في هذا النهج:

• يمكنك تقديم اعتماد آخر في نظامك (تطبيق المصادقة داخل شبكة الشركات.) سيكون تطبيقًا بسيطًا ، لكنك ستواجه مشاكل عند محاولة تشخيص المشكلات إذا لم يكن لديك وصول.
• أنت بحاجة إلى الخدمة المستضافة إلى نفس مجال تطبيق المصادقة (وبالتالي يتم تمرير تذكرة المصادقة في ملف تعريف الارتباط HTTP.)
• ستحتاج أيضًا إلى شهادة SSL لخدمتك المستضافة لتأمين المعلومات. (ليس في الحقيقة جانبًا سلبيًا لكل شئ ، ربما ترغب في القيام بذلك على أي حال.)
• نظرًا لأنك وعميلك سيكون لديك مفتاح آلي مشترك ، فسوف تقوم بربط مثيل لتطبيقك على هذا العميل بالذات.

Answer 6

سأستخدم مزودًا/خادمًا خاصًا مفتوحًا لهذا الغرض.