청구 기반 인증 및 고전적인 Windows 인증의 차이점

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 웹 서비스가 클레임 인식을 요구하는 것이 필요하다는 것이 밝혀졌습니다.Shilllight의 Silverlight에서 사용하는 WCF 서비스는 기본 바인딩을 사용하기 위해 심각하게 제한되며 이전에 자격 증명을 통과시킬 수있는 실질적인 작업입니다.나는 아직도 함의를 겪고 있지만, 더 잘 알고있는 사람으로부터의 명확한은 감사 할 것입니다.ArcGIS에 관해서는 아직 답변을 얻지 못했습니다.

Answer 6

클레임에서도 중요한 요소도 서버와 대화하는 서버와 똑같은 요소입니다.Windows에서 Kerberos 외부에서 WFE 서버는 인증 공급자 (일반적으로 AD)와 통신을 처리하고 클라이언트는 WFE 서버에만 통화합니다.Kerberos는 클라이언트, SP 서버 및 DC간에 3 개의 연결이 모두 필요합니다.

클레임은 SP가 AUTH 소스에 연결할 필요가 없습니다.클라이언트는 SP 서버가 사용자와 ID 공급자에 대해 알아야 할 속성의 종류를 나타내는 SP 서버 간의 전달을 처리합니다.이를 통해 SP 시스템은 식별이 아니라 인증에만 초점을 맞추고 Google, Facebook 등과 같은 다른 ID 공급자에 연결할 수 있습니다.