基于索赔的身份验证和经典Windows身份验证之间的差异

Question

我已经读了几篇关于相同的文章，但仍未清除SharePoint 2013中的基于索赔和经典窗口身份验证的差异.I从理论上了解了基于索赔的概念，但实际上无法在创建Web应用程序时看到任何区别2013年我们选择了基于索赔的身份验证，但我们在这里做出了什么比SharePoint 2010所做的。当我们登录我们的Web应用程序时，我们仍然使用用户名和密码，因此它如何实际工作？

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

如果您的Web应用程序使用经典模式身份验证，则无法配置基于表单的身份验证

Answer 5

在转换我们的2010农场以使用基于索赔的身份验证后，Out ArcGIS Web服务停止工作，我们的自定义WCF Web服务不再获取用户凭据 - 我相信它们函数匿名访问。事实证明，WCF Web服务需要谅解，它们不是。SilvePoint内部使用的WCF服务被严重限制使用基本绑定，并且在以前将凭据传递凭据是实质性的工作。我仍然通过自己的含义，但对更知识渊博的任何澄清都会受到赞赏。至于ArcGIS，我还没有得到答案。

Answer 6

索赔中的一个重要因素也是哪种服务器与哪个服务器交谈。在Kerberos之外的Windows Auth中，WFE服务器将通信处理到身份验证提供程序（通常是AD），并且客户端仅对WFE服务器进行通话。Kerberos需要客户端，SP服务器和DC之间的所有3个连接。

声称根本不需要SP连接到AUTH源。客户端处理SP服务器之间的传递，指示SP服务器需要了解关于用户和身份提供者的哪种属性。这允许SP系统仅关注授权，而不是识别，因此插入像Google，Facebook等等的其他身份提供商。