الفرق بين المصادقة القائمة على المطالبة ومصادقة النوافذ الكلاسيكية

Question

لقد قرأت عدة مقالات حول نفس الشيء ولكن لا تزال غير مستحقة عن الفرق بين المصادقة القائمة على المطالبة ومصادقة النافذة الكلاسيكية في SharePoint 2013. أن تفهم مفهوم المطالبة النظرية نظريا، ولكن عمليا غير قادر على رؤية أي فرق أثناء إنشاء تطبيق ويبفي عام 2013. نقوم باختيار المصادقة القائمة على المطالبة ولكن ما نقوم به حقا مختلف هنا من SharePoint 2010. عند تسجيل الدخول إلى تطبيق الويب الخاص بنا، ما زلنا نستخدم اسم المستخدم وكلمة المرور، فكيف يعمل حقا؟

Answer 1

SharePoint Foundation supports the following types of authentication and the advantage with claim based authentication is that it supports systems that are non Windows based.

• Windows: IIS and Windows authentication integration options, including Basic, Digest,(NTLM), and Kerberos. Windows authentication allows IIS to perform the authentication for SharePoint Foundation. This is also referred to as “classic mode authentication”. This approach has a number of disadvantages such as. This approach is not future proof and unsuitable for environments such as extranet, inter-organization, or situations where the domain may not be accessible or there may be many domains in play.
• Claims based authentication: The claims-based identity is an identity model in Microsoft SharePoint that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications. When a user signs in to SharePoint, the user's token is validated and then used to sign in to SharePoint. The user's token is a security token issued by a claims provider.

You can find the entire article here.

Answer 2

The big difference with claims based authentication is that you can easily (well it is still SharePoint) add other providers.

For example you can add another provider and being able to sign in with your google account, live-id, linkedin account etc etc.

Claims-based identity allows you to factor out the authentication logic from individual applications. Instead of the application determining who the user is, it receives claims that identify the user.

In software, this bundle of claims is called a security token. Each security token is signed by the issuer who created it. A claims-based application considers users to be authenticated if they present a valid, signed security token from a trusted issuer.

Both from http://msdn.microsoft.com/en-us/library/ff359101.aspx which is a great introduction

Answer 3

What I believe is the major difference is that with classic mode, you login directly, and if you need to be authenticated to a second server, it's not possible (you need to be logged in to this second server first -> new login screen). You will find that this is still often done but in that case the second connection is done under a different account (with privileges specifically for the resource, for instance).

With claims, you authenticate, you get a claims token and that is passed around to whoever needs it, and you are authenticated to this second server automatically without another login screen. Given that the server trusts your secure token service (whom initially authenticated you).

I may have the details wrong but in theory but this is generally how it works.

Claims and Kerberos are similar, but they differ in the technicalities.

Important part:

• Kerberos delegation — If the client authenticates with the front-end service by using Kerberos authentication, Kerberos delegation can be used to pass the client's identity to the back-end system.
• Claims — claims authentication allows the client's claims to be passed between services as long as there is trust between the two services and both are claims-aware.
• Claims authentication, like Kerberos authentication, can be used to delegate client credentials but requires the back-end application to be claims-aware.

Source:

http://blogs.msdn.com/b/besidethepoint/archive/2010/05/09/double-hop-authentication-why-ntlm-fails-and-kerberos-works.aspx

Answer 4

لا يمكنك تكوين المصادقة المستندة للنماذج إذا كان تطبيق الويب الخاص بك يستخدم مصادقة الوضع الكلاسيكي

Answer 5

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

Answer 6

عامل مهم في المطالبات وكذلك الخوادم تتحدث إلى الخوادم.في Windows Auth خارج Kerberos، يعالج خادم WFE الاتصالات إلى موفر المصادقة (AD بشكل عام) ومحادثات العميل فقط إلى خادم WFE.يتطلب Kerberos جميع الاتصالات الثلاثة بين العميل وخادم SP و DC. لا تتطلب المطالبات

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