سؤال

هل هناك أي أمثلة لائقة لما يلي المتاحة:

أبحث من خلال وايف SDK, ، هناك أمثلة على استخدام WIF بالتزامن مع ASP.NET باستخدام WSFederationAuthenticationModule (FAM) لإعادة التوجيه إلى موقع ASP.NET بشرة رقيقة علاوة على خدمة الرمز المميز للأمان (STS) الذي يستخدمه المستخدم للمصادقة (من خلال توفير اسم مستخدم وكلمة مرور).

إذا فهمت WIF و Undived Access بشكل صحي (WS-*) ، وتوقع إعادة رمز SAML. من الناحية المثالية SessionAuthenticationModule ستعمل وفقًا للأمثلة باستخدام FAM بالتزامن مع SessionAuthenticationModule أي أن تكون مسؤولاً عن إعادة بناء IClaimsPrincipal من ملف تعريف الارتباط المكثف بأمان الجلسة وإعادة التوجيه إلى صفحة تسجيل الدخول إلى التطبيق الخاص بي عندما تنتهي صلاحية جلسة الأمان.

هو ما أصفه باستخدام FAM و SessionAuthenticationModule مع إعدادات web.config المناسبة ، أو هل أحتاج إلى التفكير في كتابة أ HttpModule نفسي للتعامل مع هذا؟ بدلاً من ذلك ، هل يتم إعادة توجيه إلى موقع رفيع على شبكة الإنترنت حيث يقوم المستخدمون بتسجيل الدخول إلى نهج DE الفعلي في سيناريو الطلب السلبي؟

هل كانت مفيدة؟

المحلول

يتوفر مثال على WIF + MVC في هذا الفصل من "دليل هوية المطالبات":

http://msdn.microsoft.com/en-us/library/ff359105.aspx

أقترح قراءة الفصول الأولى للزوجين لفهم جميع المبادئ الأساسية. يغطي منشور المدونة هذا تفاصيل MVC + WIF:

http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-mvc-how-it-works.aspx

السيطرة على تجربة تسجيل الدخول جيدة تمامًا. يجب عليك فقط نشر STS الخاص بك (في مجالك ، مع مظهرك ومشعرك ، إلخ). ستعتمد تطبيقاتك ببساطة على Authn (ولهذا السبب يطلق على التطبيق عادةً "حفلة الاعتماد").

ميزة البنية هي أن Authn يتم تفويضه إلى مكون واحد (STS) ولا ينتشر في العديد من التطبيقات. لكن الميزة الأخرى (الضخمة) هي أنه يمكنك تمكين سيناريوهات أكثر تطوراً بسهولة بالغة. على سبيل المثال ، يمكنك الآن الاتحاد مع مقدمي هوية المنظمة الآخرين.

أتمنى أن يساعد يوجينيو

@نجم صاعد:

يمكن تشفير الرمز المميز (الذي يحتوي على المطالبات) اختياريًا (وإلا فإنها ستكون في نص واضح). لهذا السبب ينصح دائمًا بـ SSL للتفاعلات بين المتصفح و STS.

لاحظ أنه على الرغم من أنها في نص واضح ، فإن العبث غير ممكن لأن الرمز المميز موقّع رقميًا.

نصائح أخرى

هذا سؤال مثير للاهتمام الذي طرحته. أعلم أنه لأي سبب من الأسباب ، وضعت Microsoft إطار عمل "Windows Identity Foundation" دون الكثير من الوثائق. أعرف ذلك لأنني تم تكليفه بمعرفة كيفية استخدامه مع مشروع جديد ودمجه مع البنية التحتية الحالية. لقد كنت أبحث عن الويب لعدة أشهر أبحث عن معلومات جيدة.

لقد أخذت زاوية مختلفة إلى حد ما لحل المشكلة التي تصفها.

لقد أخذت تطبيق تسجيل الدخول الحالي وسباكة WIF من Microsoft المدمجة فيه. من خلال ذلك ، أعني أن لديّ تطبيقًا يقوم فيه بتسجيل الدخول. يقوم تطبيق Log-On بتقديم بيانات الاعتماد المقدمة من المستخدم إلى خادم آخر يقوم بإرجاع هوية المستخدمين (أو يشير إلى فشل السجل).

بالنظر إلى بعض أمثلة Microsoft ، أرى أنهم يفعلون ما يلي: إنشاء أ SignInRequestMessage من QueryString (الذي تم إنشاؤه بواسطة تطبيق حزب الاعتماد) ، قم ببناء خدمة رمزية أمان من فئة مخصصة ، وأخيراً استدعاء FederatedSecurityTokenServiceOprations.ProcessSignInResponse مع httpcontext.response الحالي. لسوء الحظ ، لا أستطيع أن أشرح ذلك جيدًا هنا ؛ تحتاج حقًا إلى إلقاء نظرة على عينات التعليمات البرمجية.

بعض الكود الخاص بي يشبه إلى حد كبير عينة الكود. حيث ستكون مهتمًا بتنفيذ الكثير من المنطق الخاص بك في GetOutputClaimsIdentity. هذه هي الوظيفة التي تبني هوية المطالبات التي تصف المستخدم المسجل.

الآن ، هذا ما أعتقد أنك مهتم حقًا بمعرفته. هذا ما لا تخبرك به Microsoft في وثائقها ، AFAIK.

بمجرد قيام المستخدم بتسجيل الدخول ، يتم إعادة توجيههم إلى تطبيق الطرف بالاعتماد. بغض النظر عن كيفية عمل تطبيق LOG-ON ، سترسل فئات WIF استجابة لمتصفح المستخدم الذي يحتوي على إدخال HTML "المخفي" الذي يحتوي على شهادة توقيع الرمز المميز ومطالبات المستخدم. (ستكون المطالبات في نص واضح). في نهاية هذا الرد ، يتم إعادة توجيه إلى موقع الويب الخاص بك. أنا أعرف فقط عن هذا الإجراء لأنني استولت عليه مع "Fiddler"

بمجرد العودة إلى موقع الويب الخاص بالحفلات ، ستتعامل فئات WIF مع الاستجابة (قبل تشغيل أي رمز الخاص بك). سيتم التحقق من صحة الشهادة. افتراضيًا ، إذا قمت بإعداد موقع الويب الخاص بك على الويب مع fedutil.exe (بالنقر فوق "إضافة مرجع STS في تطبيق الطرف الخاص بك من Visual Studio) ، فإن فئة Microsoft سوف تتحقق من الشهادة Thumbprint.

أخيرًا ، يقوم WIF Framework بتعيين ملفات تعريف الارتباط في متصفح المستخدم (في تجربتي ، تبدأ أسماء ملفات تعريف الارتباط بـ "Fedauth") التي تحتوي على مطالبات المستخدمين. ملفات تعريف الارتباط ليست قابلة للقراءة.

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

أعلم أن هذا يختلف عما تصفه ، لكن لدي هذا الإعداد يعمل. آمل أن يساعد هذا!

ملاحظة. يرجى الاطلاع على الأسئلة الأخرى التي طرحتها حول Windows Identity Foundation.

تحديث: للإجابة على السؤال في التعليق أدناه:

أحد الأشياء التي تركتها هو أن إعادة توجيه تطبيق STS يحدث عن طريق إعادة التوجيه باستخدام سلسلة الاستعلام التي تحتوي على عنوان URL للتطبيق الذي يقوم المستخدم بتسجيل الدخول إليه. يحدث هذا إعادة التوجيه تلقائيًا في المرة الأولى التي يحاول فيها المستخدم الوصول إلى صفحة تتطلب المصادقة. بدلاً من ذلك ، أعتقد أنه يمكنك القيام بإعادة التوجيه يدويًا مع WSFederationAuthentication وحدة.

لم أحاول أبدًا القيام بذلك ، ولكن إذا كنت ترغب في استخدام صفحة تسجيل الدخول داخل التطبيق نفسه ، أعتقد أن الإطار يجب أن يسمح لك باستخدام ما يلي:

1) تغليف رمز STS داخل المكتبة. 2) الرجوع إلى المكتبة من التطبيق الخاص بك. 3) إنشاء صفحة تسجيل الدخول داخل التطبيق الخاص بك. تأكد من أن هذه الصفحة لا تتطلب المصادقة. 4) تعيين خاصية المصدر لـ wsFederation عنصر داخل Microsoft.IdentityModel قسم من web.config إلى صفحة تسجيل الدخول.

ما تريد القيام به هو علامة نشطة. WIF يشمل Wstrustchannel (مصنع) مما يتيح لك التواصل مباشرة مع STS والحصول على رمز أمان. إذا كنت تريد أن يعمل نموذج تسجيل الدخول الخاص بك بهذه الطريقة ، فيمكنك اتباع عينة "Wstrustchannel" من WIF 4.0 SDK. بمجرد حصولك على الرمز المميز ، سوف يأخذ الرمز التالي هذا الرمز المميز واتصل معالج WIF لإنشاء رمز جلسة وتعيين ملف تعريف الارتباط المناسب:

public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
    var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;            
    var token = handlers.ReadToken(new XmlTextReader(
                                        new StringReader(genericToken.TokenXml.OuterXml)));

    var identity = handlers.ValidateToken(token).First();
    // create session token
    var sessionToken = new SessionSecurityToken(
        ClaimsPrincipal.CreateFromIdentity(identity));
    FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}

بمجرد القيام بذلك ، يجب أن يتصرف موقعك كما لو أن التوقيع السلبي قد حدث.

يمكنك استخدام التحكم في FederatedPassivesignin.

وضع ملف تعريف الارتباط الخاص بك مثل هذا: FederatedAuthentication.SessionAuthenticationModule.writesessionTokentOckie (SessionToken) ؛ DOENS لا تعمل مع SSO للمجالات الأخرى.

يجب تعيين ملف تعريف الارتباط من قبل STS وليس في RP.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top