SharePoint Server에서 사용자 인증 방법 계획

적용 대상:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

참고

여기에 언급된 사용자 인증 방법은 SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 및 SharePoint Server 구독 버전에 적용됩니다.

SharePoint Server에서 지원하는 사용자 인증 유형 및 방법과 웹 응용 프로그램 및 영역에 대해 사용할 유형 및 방법을 어떻게 결정할지에 대해 설명합니다.

Microsoft 365의 SharePoint 인증에 대해 알아봅니다.

참고

SharePoint Server 구독 버전에서는 이제 OIDC 1.0 인증을 지원합니다. 이 새 인증 유형으로 작업하는 방법에 대한 자세한 내용은 OpenID Connect 1.0 인증을 참조하세요.

소개

사용자 인증은 사용자의 자격 증명을 포함하며 사용자가 해당 자격 증명을 올바르게 제출했는지 확인할 수 있는 디렉터리 또는 데이터베이스인 인증 공급자에 대해 사용자 ID의 유효성을 검사하는 작업입니다. 인증 공급자의 예로는 AD DS(Active Directory 도메인 서비스)가 있습니다. 인증 공급자는 사용자 디렉터리, 특성 저장소라고도 합니다.

인증 방법은 계정 자격 증명 및 사용자의 ID를 어설션하는 기타 정보의 특정 교환입니다. 인증 방법을 사용하면 인증 공급자가 사용자를 인증했다는 증명(대개 클레임을 포함하는 토큰 형식)이 제공됩니다.

인증 유형은 하나 이상의 인증 공급자에 대해 자격 증명의 유효성을 검사하는 특정 방식으로, 업계 표준 프로토콜을 사용하기도 합니다. 하나의 인증 유형에서 여러 인증 방법을 사용할 수 있습니다.

사용자 ID의 유효성을 검사한 후에는 권한 부여 프로세스에서 사용자가 액세스할 수 있는 사이트, 콘텐츠 및 기타 기능을 결정합니다.

사용자 인증 유형 및 방법에 대한 계획에 따라 다음이 결정됩니다.

• 각 웹 응용 프로그램 및 영역에 대한 사용자 인증 유형 및 방법

• 결정된 인증 유형 및 방법을 지원하는 데 필요한 인증 인프라

  참고

  Windows 클래식 모드 인증은 SharePoint Server 2016, SharePoint Server 2019 및 SharePoint Server 구독 버전에서 더 이상 지원되지 않습니다.

클레임 기반 인증

AD DS의 사용자 ID는 사용자 계정을 기반으로 합니다. 사용자는 인증을 정상적으로 수행할 수 있도록 계정 이름 및 암호를 알고 있다는 증명을 제공합니다. 리소스 액세스를 결정하기 위해 응용 프로그램은 AD DS에서 계정 특성 및 기타 정보(예: 네트워크의 역할 또는 그룹 멤버 자격)를 쿼리해야 할 수 있습니다. 이 기능은 Windows 환경에서 잘 작동하지만 인터넷, 파트너 또는 클라우드 기반 컴퓨팅 모델을 지원하는 타사 인증 공급자 및 다중 공급업체 환경으로 확장되지는 않습니다.

클레임 기반 ID를 소유한 사용자는 일반적으로 신뢰할 수 있는 ID 공급자로부터 디지털 서명된 보안 토큰을 받습니다. 이 토큰에는 클레임 집합이 포함되어 있습니다. 각 클레임은 네트워크의 이름, 그룹 멤버 자격 및 역할과 같은 사용자에 대한 데이터의 특정 항목을 나타냅니다. 클레임 기반 인증은 클레임 기반 ID 기술 및 인프라를 사용하는 사용자 인증입니다. 클레임 기반 인증을 지원하는 응용 프로그램은 자격 증명이 아닌 사용자로부터 보안 토큰을 받은 다음 클레임 내의 정보를 사용하여 리소스 액세스를 결정합니다. 이 경우 AD DS 등의 디렉터리 서비스를 별도로 쿼리할 필요가 없습니다.

Windows의 클레임 기반 인증은 클레임 기반 ID를 구현하는 데 사용되는 .NET Framework 클래스 집합인 WIF(Windows Identity Foundation)를 기반으로 합니다. 클레임 기반 인증에는 WS-Federation, WS-Trust 등의 표준과 SAML(Security Assertion Markup Language) 등의 프로토콜이 사용됩니다.

클레임 기반 인증에 대한 자세한 내용은 다음 리소스를 참조하세요.

• Windows용 클레임 기반 ID(백서)

• Windows Identity Foundation 홈페이지

사용자 인증, 서버 간 인증 및 앱 인증에는 클레임 기반 인증이 널리 사용되고 있으므로 SharePoint Server 팜의 모든 웹 응용 프로그램 및 영역에 대해 클레임 기반 인증을 사용하는 것이 좋습니다. 자세한 내용은 SharePoint Server에서 서버 간 인증 계획을 참조하세요. 클레임 기반 인증을 사용하는 경우 지원되는 모든 인증 방법을 웹 응용 프로그램에서 사용할 수 있으며 서버 간 인증 및 앱 인증을 사용하는 SharePoint Server의 새로운 기능과 시나리오를 활용할 수 있습니다.

클레임 기반 인증의 경우 SharePoint Server는 모든 사용자 계정을 클레임 ID로 자동으로 변경합니다. 이렇게 변경하면 각 사용자에 대한 보안 토큰(클레임 토큰이라고도 함)이 생성됩니다. 클레임 토큰에는 사용자와 관련된 클레임이 포함됩니다. Windows 계정은 Windows 클레임으로 변환됩니다. 양식 기반 멤버 자격 사용자는 양식 기반 인증 클레임으로 변환됩니다. SharePoint Server는 SAML 기반 토큰에 포함된 클레임을 사용할 수 있습니다. 또한 SharePoint 개발자와 관리자는 더 많은 클레임으로 사용자 토큰을 보강할 수 있습니다. 예를 들어 Windows 사용자 계정 및 양식 기반 계정은 SharePoint Server에서 사용하는 추가 클레임으로 보강할 수 있습니다.

SharePoint Server에서 클레임 기반 인증을 사용하기 위해 클레임 설계자가 될 필요는 없습니다. 그러나 SAML 토큰 기반 인증을 구현하려면 SAML 토큰 기반 인증 계획에 설명된 대로 클레임 기반 환경의 관리자와 조정해야 합니다.

SharePoint Server 2013의 클래식 모드 인증

SharePoint 2013에서 중앙 관리에서 웹 애플리케이션을 만들 때 클레임 기반 인증에 대한 인증 유형 및 방법만 지정할 수 있습니다. 이전 버전의 SharePoint에서는 중앙 관리에서 웹 응용 프로그램에 대해 클래식 모드 인증도 구성할 수 있습니다. 클래식 모드 인증은 Windows 인증을 사용하고 SharePoint 2013은 사용자 계정을 AD DS 계정으로 처리합니다.

클래식 모드 인증을 사용하도록 웹 애플리케이션을 구성하려면 New-SPWebApplication PowerShell cmdlet을 사용하여 만들어야 합니다. 클래식 모드 인증을 위해 구성된 SharePoint 2010 Products 웹 애플리케이션은 SharePoint 2013으로 업그레이드할 때 인증 설정을 유지합니다. 그러나 SharePoint 2013으로 업그레이드하기 전에 웹 애플리케이션을 클레임 기반 인증으로 마이그레이션하는 것이 좋습니다.

SharePoint 2013 팜에는 두 모드를 모두 사용하는 웹 애플리케이션이 혼합될 수 있습니다. 일부 서비스는 기존 Windows 계정인 사용자 계정과 Windows 클레임 계정을 구분하지 않습니다.

업그레이드 전에 마이그레이션하는 방법에 대한 자세한 내용은 클래식 모드에서 클레임 기반 인증으로 마이그레이션을 참조하세요.

업그레이드 후에 마이그레이션하는 방법에 대한 자세한 내용은 Migrate from classic-mode to claims-based authentication in SharePoint Server을 참조하세요.

SharePoint 2013에서 클래식 모드 인증을 사용하는 웹 애플리케이션을 만드는 방법에 대한 자세한 내용은 SharePoint Server에서 클래식 모드 인증을 사용하는 웹 애플리케이션 만들기를 참조하세요. 클레임 기반 인증을 사용하여 클래식 모드 인증을 사용하는 웹 애플리케이션은 마이그레이션할 수 없습니다.

중요

Office Online은 클레임 기반 인증을 사용하는 SharePoint 2013 웹 애플리케이션에서만 사용할 수 있습니다. Office Online 렌더링 및 편집은 클래식 모드 인증을 사용하는 SharePoint 2013 웹 애플리케이션에서 작동하지 않습니다. 클래식 모드 인증을 사용하는 SharePoint 2010 웹 애플리케이션을 SharePoint 2013으로 마이그레이션하는 경우 Office Online에서 작업할 수 있도록 클레임 기반 인증으로 마이그레이션해야 합니다.

지원되는 인증 유형 및 방법

SharePoint Server는 다음과 같은 인증 유형에 대해 다양한 인증 방법 및 인증 공급자를 지원합니다.

• Windows 인증

• 양식 기반 인증

• SAML 토큰 기반 인증

Windows 인증

Windows 인증 유형에서는 Windows 환경에서 연결하는 클라이언트의 자격 증명 유효성을 검사하는 데 사용하는 기존 Windows 인증 공급자(AD DS) 및 인증 프로토콜을 활용합니다. 두 클레임 기반 인증에서 사용되는 Windows 인증 방법은 다음과 같습니다.

• NTLM

• Kerberos

• 다이제스트

• 기본

자세한 내용은 이 문서의 Windows 인증 계획을 참조하세요.

SharePoint 2013 및 SharePoint Server 2016의 Windows 클레임 인증 동영상 보기

SharePoint Server에서는 Windows 인증 유형은 아니지만 익명 인증도 지원합니다. 사용자는 자격 증명의 유효성을 검사하지 않고도 SharePoint 콘텐츠에 액세스할 수 있습니다. 익명 인증은 기본적으로 사용하지 않도록 설정됩니다. 일반적으로 SharePoint Server를 사용하여 보안이 필요하지 않고 공용 인터넷 웹 사이트와 같은 모든 사용자가 사용할 수 있는 콘텐츠를 게시할 때 익명 인증을 사용합니다.

익명 인증을 사용하도록 설정하는 것 외에도 사이트 및 사이트 리소스에 대한 익명 액세스(권한)를 구성해야 합니다.

참고

웹 애플리케이션을 제공하기 위해 SharePoint에서 만든 IIS(인터넷 정보 서비스) 웹 사이트는 익명 및 양식 인증에 대한 SharePoint 설정을 사용하지 않도록 설정한 경우에도 항상 익명 인증 및 양식 인증 방법을 사용하도록 설정합니다. 이는 의도적인 것이며 IIS 설정에서 익명 또는 양식 인증을 직접 사용하지 않도록 설정하면 SharePoint 사이트에서 오류가 발생합니다.

양식 기반 인증

양식 기반 인증은 ASP.NET 멤버 자격 및 역할 공급자 인증을 기반으로 하는 클레임 기반 ID 관리 시스템입니다. 다음과 같이 인증 공급자에 저장된 자격 증명에 대해 양식 기반 인증을 사용할 수 있습니다.

• AD DS

• 데이터베이스(예: SQL Server 데이터베이스)

• Novell eDirectory, NDS(Novell Directory Services) 또는 Sun ONE과 같은 LDAP(Lightweight Directory Access Protocol) 데이터 저장소

양식 기반 인증에서는 사용자가 로그온 양식(대개 웹 페이지)에 입력하는 자격 증명을 기반으로 사용자의 유효성을 검사합니다. 인증되지 않은 요청은 사용자가 유효한 자격 증명을 제공하고 양식을 제출해야 하는 로그인 페이지로 리디렉션됩니다. 시스템에서는 인증된 요청에 대해 후속 요청용으로 ID를 다시 설정하기 위한 키가 포함된 쿠키를 발급합니다.

SharePoint 2013 및 SharePoint Server 2016의 양식 기반 클레임 인증 동영상 보기

참고

양식 기반 인증을 사용하는 경우 사용자 계정 자격 증명은 일반 텍스트로 전송됩니다. 따라서 SSL(Secure Sockets Layer)을 사용하여 웹 사이트 트래픽을 암호화하는 경우가 아니면 양식 기반 인증을 사용해서는 안 됩니다.

자세한 내용은 양식 기반 인증 계획을 참조하세요.

SAML 토큰 기반 인증

SharePoint Server의 SAML 토큰 기반 인증은 SAML 1.1 프로토콜 및 WS-F PRP(WS-Federation Passive Requestor Profile)를 사용합니다. SAML 토큰 기반 인증을 사용하려면 고유한 내부 환경이든 파트너 환경이든 관계없이 클레임 기반 환경의 관리자와 협력해야 합니다. AD FS(Active Directory Federation Services) 2.0을 사용하는 경우에는 SSAML 토큰 기반 인증 환경이 제공됩니다.

SAML 토큰 기반 인증 환경에는 IP-STS(ID 공급자 Security Token Service)가 포함되어 있습니다. IP-STS는 해당 계정이 연결된 인증 공급자에 포함된 사용자를 대신하여 SAML 토큰을 발급합니다. 토큰에는 사용자 이름 및 사용자가 속한 그룹 같은 사용자에 대한 클레임이 수에 제한 없이 포함될 수 있습니다. IP-STS의 예로는 AD FS 2.0 서버가 있습니다.

SharePoint Server에서는 IP-STS에서 권한이 부여된 사용자에게 발급하는 토큰에 포함된 클레임을 활용합니다. 클레임 환경에서 SAML 토큰을 받아들이는 응용 프로그램을 RP-STS(신뢰 당사자 STS)라고 합니다. 신뢰 당사자 응용 프로그램에서는 SAML 토큰을 수신하고 내부의 클레임을 사용하여 요청된 자원에 대해 클라이언트 액세스를 부여할지 여부를 결정합니다. SharePoint Server에서 SAML 공급자를 사용하도록 구성된 각 웹 응용 프로그램은 IP-STS에 별도의 RP-STS 항목으로 추가됩니다. 단일 SharePoint 팜이 IP-STS의 여러 RP-STS 항목을 나타낼 수 있습니다.

SharePoint 2013 및 SharePoint Server 2016의 SAML 기반 클레임 인증 동영상 보기

SAML 토큰 기반 인증용 인증 공급자 집합은 클레임 환경의 IP-STS에 따라 달라집니다. AD FS 2.0을 사용하는 경우 인증 공급자(AD FS 2.0의 특성 저장소라고 함)는 다음을 포함할 수 있습니다.

• Windows Server 2003 Active Directory 및 Windows Server 2008의 AD DS

• SQL Server 2005 및 SQL Server 2008의 모든 버전

• 사용자 지정 특성 저장소

자세한 내용은 SAML 토큰 기반 인증 계획을 참조하세요.

LDAP 환경을 위한 인증 유형 선택

양식 기반 인증 또는 SAML 토큰 기반 인증에서는 LDAP 환경을 사용할 수 있습니다. 현재 LDAP 환경과 일치하는 인증 유형을 사용합니다. LDAP 환경이 아직 없는 경우 덜 복잡하기 때문에 양식 기반 인증을 사용하는 것이 좋습니다. 그러나 인증 환경에서 WS-Federation 1.1 및 SAML 1.1을 이미 지원하는 경우에는 SAML을 사용하는 것이 좋습니다. SharePoint Server에서는 LDAP 공급자가 기본적으로 제공됩니다.

Windows 인증 계획

Windows 인증 방법을 계획하고 구현하는 프로세스는 클레임 기반 인증과 비슷합니다. 웹 애플리케이션에 대한 클레임 기반 인증은 Windows 인증 방법을 구현하는 복잡성을 증가하지 않습니다. 이 섹션에서는 Windows 인증 방법 계획 과정을 간략히 설명합니다.

NTLM 및 Kerberos 프로토콜

NTLM 및 Kerberos 프로토콜은 모두 Windows 통합 인증 모드로, 자격 증명에 대한 메시지를 표시하지 않고 사용자가 원활하게 인증을 수행할 수 있도록 합니다. 예를 들면 다음과 같습니다.

• Internet Explorer에서 SharePoint 사이트에 액세스하는 사용자는 Internet Explorer 프로세스 실행에 사용되는 자격 증명을 사용하여 인증합니다. 기본적으로 이러한 자격 증명은 사용자가 컴퓨터에 로그인하는 데 사용한 자격 증명입니다.

• Windows 통합 인증 방법을 사용하여 SharePoint 리소스에 액세스하는 서비스 또는 응용 프로그램은 실행 중인 스레드의 자격 증명(기본적으로 프로세스의 ID)을 사용하여 인증합니다.

NTLM은 구현하기 위한 가장 간단한 형태의 Windows 인증이며 일반적으로 인증 인프라의 추가 구성이 필요하지 않습니다. 웹 애플리케이션을 만들거나 구성할 때 이 옵션을 선택합니다.

Kerberos 프로토콜은 티켓 인증을 지원합니다. Kerberos 프로토콜을 사용하려면 더 많은 환경 구성이 필요합니다. Kerberos 인증을 사용하도록 설정하려면 클라이언트 컴퓨터와 서버 컴퓨터에 도메인 KDC(키 배포 센터)에 대한 트러스트된 연결이 있어야 합니다. Kerberos 프로토콜을 구성하려면 SharePoint Server를 설치하기 전에 AD DS에서 SPN(서비스 사용자 이름)을 설정해야 합니다.

Kerberos 인증을 고려해야 하는 이유는 다음과 같습니다.

• Kerberos 프로토콜은 가장 강력한 Windows 통합 인증 프로토콜이며 AES(Advanced Encryption Standard) 암호화 및 클라이언트와 서버의 상호 인증을 비롯한 고급 보안 기능을 지원합니다.

• Kerberos 프로토콜을 사용하는 경우 클라이언트 자격 증명을 위임할 수 있습니다.

• 사용 가능한 여러 보안 인증 방법 중에서 AD DS 도메인 컨트롤러에 대해 필요한 네트워크 트래픽의 양이 가장 적은 방법이 Kerberos입니다. Kerberos를 사용하면 페이지 대기 시간이 감소하는 경우도 있고, 프런트 엔드 웹 서버가 처리할 수 있는 페이지 수가 증가하는 경우도 있습니다. 또한 Kerberos는 도메인 컨트롤러에 대한 로드도 줄일 수 있습니다.

• Kerberos 프로토콜은 다수의 플랫폼과 공급업체에서 지원하는 개방형 프로토콜입니다.

Kerberos 인증이 적합하지 않을 수 있는 이유는 다음과 같습니다.

• Kerberos 인증이 정상적으로 작동하려면 다른 인증 방법과 달리 인프라와 환경에서 추가 구성을 수행해야 합니다. 대부분의 경우에는 Kerberos 프로토콜을 구성하려면 도메인 관리자 권한이 필요합니다. Kerberos 인증은 설정 및 관리하기가 어려울 수 있습니다. Kerberos를 잘못 구성하는 경우 사이트에 올바르게 인증하지 못할 수 있습니다.

• Kerberos 인증을 사용하려면 클라이언트 컴퓨터를 KDC 및 AD DS 도메인 컨트롤러에 연결해야 합니다. Windows 배포에서는 KDC가 AD DS 도메인 컨트롤러입니다. 이 네트워크 구성은 조직 인트라넷에서 일반적이지만 인터넷 연결 배포는 일반적으로 이러한 방식으로 구성되지 않습니다.

다음 단계에는 Kerberos 인증 구성 방법이 요약되어 있습니다.

1. AD DS에 SQL Server 서비스 계정의 SPN을 만들어 SQL Server 통신에 대해 Kerberos 인증을 구성합니다.

2. Kerberos 인증을 사용할 웹 응용 프로그램의 SPN을 만듭니다.

3. SharePoint 서버 팜을 설치합니다.

4. 팜 내의 특정 서비스가 특정 계정을 사용하도록 구성합니다.

5. Kerberos 인증을 사용할 웹 응용 프로그램을 만듭니다.

다이제스트 및 기본

다이제스트 인증 방법을 사용하면 사용자 계정 자격 증명이 MD5 메시지 다이제스트로 웹 애플리케이션 또는 영역을 호스트하는 웹 서버의 IIS(인터넷 정보 서비스) 서비스로 전송됩니다. 기본 인증 방법을 사용하는 경우 사용자 계정 자격 증명은 일반 텍스트로 전송됩니다. 따라서 SSL을 사용하여 웹 사이트 트래픽을 암호화하지 않는 한 기본 인증 방법을 사용하면 안 됩니다.

환경에서 웹 사이트에 대한 다이제스트 또는 기본 인증만 지원하는 웹 브라우저나 서비스를 사용하는 경우에는 이러한 이전 인증 방법을 사용해야 할 수 있습니다.

NTLM, Kerberos 및 익명 인증과는 달리 다이제스트 및 기본 인증 방법은 IIS(인터넷 정보 서비스) 스냅인에서 웹 응용 프로그램 또는 영역에 해당하는 웹 사이트의 속성을 통해 구성합니다.

클레임 기반 인증을 사용하는 경우 다음을 참조하세요.

• SharePoint Server에서 클레임 기반 웹 응용 프로그램에 대해 다이제스트 인증 구성

• SharePoint Server에서 클레임 기반 웹 응용 프로그램에 대해 기본 인증 구성

양식 기반 인증 계획

양식 기반 인증을 사용하여 Windows를 기반으로 하지 않거나 외부에 있는 ID 관리 시스템에 대해 사용자를 인증하려면 Web.config 파일에 멤버 자격 공급자 및 역할 관리자를 등록해야 합니다. SharePoint Server는 표준 ASP.NET 역할 관리자 인터페이스를 사용하여 현재 사용자에 대한 그룹 정보를 수집합니다. 각 ASP.NET 역할은 SharePoint Server의 권한 부여 프로세스에서 도메인 그룹으로 간주됩니다. 인증을 위해 멤버 자격 공급자를 등록하는 것과 정확히 같은 방법으로 Web.config 파일에 역할 관리자를 등록합니다.

중앙 관리 웹 사이트에서 멤버 자격 사용자 또는 역할을 관리하려면 중앙 관리 웹 사이트의 Web.config 파일에 멤버 자격 공급자 및 역할 관리자를 등록해야 합니다. 콘텐츠를 호스트하는 웹 애플리케이션에 대한 Web.config 파일에 멤버 자격 공급자 및 역할 관리자를 등록합니다.

양식 기반 인증을 구성하는 자세한 단계는 SharePoint Server에서 클레임 기반 웹 응용 프로그램에 대해 양식 기반 인증 구성을 참조하세요.

SAML 토큰 기반 인증 계획

SAML 토큰 기반 공급자를 구현하기 위한 아키텍처에는 다음 구성 요소가 포함되어 있습니다.

• SharePoint 보안 토큰 서비스 이 서비스는 팜에서 사용하는 SAML 토큰을 만듭니다. 서비스는 서버 팜의 모든 서버에서 자동으로 만들어지고 시작됩니다. 모든 팜 간 통신은 클레임 기반 인증을 사용하므로 이 서비스는 팜 간 통신에 사용됩니다. 이 서비스는 클레임 기반 인증을 사용하는 웹 애플리케이션에 대해 구현되는 인증 방법에도 사용됩니다. 이러한 방법에는 Windows 인증, 양식 기반 인증 및 SAML 토큰 기반 인증이 포함됩니다.

• 토큰 서명 인증서(ImportTrustCertificate) 이 인증서는 IP-STS에서 내보낸 다음 팜의 한 서버에 복사하여 팜의 신뢰할 수 있는 루트 기관 목록에 추가합니다. 이 인증서를 사용하여 SPTrustedIdentityTokenIssuer를 만든 후에는 이 인증서를 사용하여 다른 인증서를 만들 수 없습니다. 이 인증서를 사용하여 다른 SPTrustedIdentityTokenIssuer를 만들려면 먼저 기존 항목을 삭제해야 합니다. 기존 항목을 삭제하기 전에 이를 사용할 수 있는 모든 웹 응용 프로그램에서 해당 항목의 연결을 해제해야 합니다.

• ID 클레임 ID 클레임은 사용자의 고유 식별자인 SAML 토큰의 클레임입니다. IP-STS의 소유자만이 토큰의 값(각 사용자에 대해 항상 고유함)을 알고 있습니다. ID 클레임은 모든 필요한 클레임을 매핑하는 동안 정규 클레임 매핑으로 만들어집니다. SPTrustedIdentityTokenIssuer가 만들어지면 ID 클레임 역할을 하는 클레임이 선언됩니다.

• 기타 클레임 이러한 클레임은 사용자를 설명하는 SAML 티켓의 추가 클레임으로 구성됩니다. 여기에는 사용자 역할, 사용자 그룹 또는 나이와 같은 다른 종류의 클레임이 포함될 수 있습니다. 모든 클레임 매핑은 SharePoint Server 팜의 서버 간에 복제되는 개체로 만들어집니다.

• 영역 SharePoint 클레임 아키텍처에서 SAML 토큰 기반 공급자를 사용하도록 구성된 SharePoint 웹 애플리케이션과 연결된 URI 또는 URL은 영역을 나타냅니다. 팜에서 SAML 기반 인증 공급자를 만들 때 IP-STS가 한 번에 하나씩 인식할 영역 또는 웹 애플리케이션 URL을 지정합니다. SPTrustedIdentityTokenIssuer를 만들 때 첫 번째 영역이 지정됩니다. SPTrustedIdentityTokenIssuer를 만든 후 더 많은 영역을 추가할 수 있습니다. 영역은 다음과 $realm = "urn:sharepoint:mysites"유사한 구문을 사용하여 지정됩니다. SPTrustedIdentityTokenIssuer에 영역을 추가한 후 IP-STS 서버의 영역 식별자를 사용하여 RP-STS 트러스트를 만들어야 합니다. 이 프로세스에는 웹 애플리케이션의 URL 지정이 포함됩니다.

• SPTrustedIdentityTokenIssuer IP-STS에서 토큰과 통신하고 받는 데 필요한 값을 포함하는 SharePoint 팜에서 만들어진 개체입니다. SPTrustedIdentityTokenIssuer를 만들 때 사용할 토큰 서명 인증서, 첫 번째 영역, ID 클레임을 나타내는 클레임 및 기타 클레임을 지정합니다. STS의 토큰 서명 인증서는 하나의 SPTrustedIdentityTokenIssuer에만 연결할 수 있습니다. 그러나 SPTrustedIdentityTokenIssuer를 만든 후 추가 웹 애플리케이션에 대한 영역을 더 추가할 수 있습니다. SPTrustedIdentityTokenIssuer에 영역을 추가한 후에는 IP-STS에도 해당 영역을 신뢰 당사자로 추가해야 합니다. SPTrustedIdentityTokenIssuer 개체는 SharePoint Server 팜의 서버 간에 복제됩니다.

• 신뢰 당사자 보안 토큰 서비스(RP-STS) SharePoint Server에서 SAML 공급자를 사용하도록 구성된 각 웹 애플리케이션은 IP-STS 서버에 RP-STS 항목으로 추가됩니다. SharePoint Server 팜 하나에 여러 개의 RP-STS 항목이 포함될 수 있습니다.

• IP-STS(ID 공급자 보안 토큰 서비스) 이 서비스는 연결된 사용자 디렉터리에 포함된 사용자를 대신하여 SAML 토큰을 발급하는 클레임 환경의 보안 토큰입니다.

다음 다이어그램에서는 SharePoint Server SAML 토큰 클레임 아키텍처를 보여줍니다.

SAML 토큰 클레임 아키텍처

SPTrustedIdentityTokenIssuer 개체는 다음과 같은 여러 매개 변수를 사용하여 만들어집니다.

• 단일 ID 클레임

• 단일 SignInURL 매개 변수입니다.

  SignInURL 매개 변수는 IP-STS에 인증하기 위해 사용자 요청을 리디렉션할 URL을 지정합니다.

• 단일 Wreply 매개 변수입니다.

  일부 IP-STS 서버에는 true 또는 false로 설정된 Wreply 매개 변수가 필요합니다. 기본값은 False입니다. IP-STS에 필요한 경우에만 Wreply 매개 변수를 사용합니다.

• 여러 영역

• 여러 클레임 매핑

SharePoint Server에서 SAML 토큰 기반 인증을 구현하려면 미리 계획해야 하는 다음 단계를 구현합니다.

1. IP-STS에서 토큰 서명 인증서를 내보냅니다. SharePoint Server 팜의 서버에 인증서를 복사합니다.

2. 사용자의 고유 식별자로 사용할 클레임을 정의합니다. 이 클레임을 ID 클레임이라고 합니다. UPN(사용자 계정 이름) 또는 사용자 전자 메일 이름은 사용자 식별자로 자주 사용됩니다. IP-STS의 소유자만 항상 사용자별로 고유할 토큰의 값을 알고 있기 때문에 IP-STS의 관리자와 협력하여 올바른 식별자를 확인합니다. 사용자의 고유 식별자를 식별하는 것은 클레임 매핑 프로세스의 일부입니다. Microsoft PowerShell을 사용하여 클레임 매핑을 만듭니다.

3. 추가 클레임 매핑을 정의합니다. SharePoint Server 팜에서 사용할 들어오는 토큰의 추가 클레임을 정의합니다. SharePoint Server 팜의 리소스에 대한 사용 권한을 할당하는 데 사용할 수 있는 클레임의 예로는 사용자 역할을 들 수 있습니다. 매핑이 없는 들어오는 토큰의 모든 클레임은 삭제됩니다.

4. PowerShell을 사용하여 토큰 서명 인증서를 가져오는 새 인증 공급자를 만듭니다. 이 프로세스를 수행하면 SPTrustedIdentityTokenIssuer가 만들어집니다. 이 프로세스 중에는 매핑한 ID 클레임 및 추가 클레임을 지정합니다. SAML 토큰 기반 인증을 위해 구성하는 첫 번째 SharePoint 웹 애플리케이션과 연결된 영역을 만들고 지정합니다. SPTrustedIdentityTokenIssuer를 만든 후 추가 SharePoint 웹 애플리케이션에 대한 영역을 만들고 추가할 수 있습니다. 이 절차를 사용하면 동일한 SPTrustedIdentityTokenIssuer를 사용하도록 여러 웹 애플리케이션을 구성할 수 있습니다.

5. SPTrustedIdentityTokenIssuer에 추가하는 각 영역에 대해 IP-STS에 RP-STS 항목을 만들어야 합니다. SharePoint 웹 애플리케이션이 존재하기 전에 이 항목을 만들 수 있습니다. 아울러 이와 관계없이 웹 응용 프로그램을 만들기 전에 URL을 계획해야 합니다.

6. 기존/신규 SharePoint 웹 응용 프로그램이 새로 만든 인증 공급자를 사용하도록 구성합니다. 인증 공급자는 웹 애플리케이션을 만들 때 중앙 관리에서 신뢰할 수 있는 ID 공급자로 표시됩니다.

여러 SAML 토큰 기반 인증 공급자를 구성할 수 있습니다. 그러나 팜에서 토큰 서명 인증서를 한 번만 사용할 수 있습니다. 구성된 모든 공급자는 중앙 관리에서 옵션으로 표시됩니다. 신뢰할 수 있는 다른 STS 환경의 클레임은 충돌하지 않습니다.

파트너 회사에 대해 SAML 토큰 기반 인증을 구현하는 경우 사용자 환경에 IP-STS가 포함되어 있으면 내부 클레임 환경 관리자와 함께 내부 IP-STS에서 파트너 STS로의 단방향 트러스트 관계를 설정하는 것이 좋습니다. 이 방법은 SharePoint Server 팜에 인증 공급자를 추가할 필요가 없습니다. 또한 이 방식을 사용하면 클레임 관리자가 전체 클레임 환경을 관리할 수 있습니다.

중요

이제는 SharePoint Server에서 클레임 기반 인증을 사용할 때 더 이상 네트워크 부하 분산을 단일 선호도로 설정할 필요가 없습니다.

참고

웹 응용 프로그램이 SAML 토큰 기반 인증을 사용하도록 구성된 경우 SPTrustedClaimProvider 클래스는 사용자 선택 컨트롤에 대해 검색 기능을 제공하지 않습니다. 사용자 선택 컨트롤에 입력한 텍스트는 유효한 사용자, 그룹 또는 클레임인지 여부에 관계없이 확인된 것처럼 자동으로 표시됩니다. SharePoint Server 솔루션에서 SAML 토큰 기반 인증을 사용할 예정인 경우에는 사용자 지정 검색 및 이름 확인을 구현하는 사용자 지정 클레임 공급자를 만들도록 계획하세요.

AD FS를 사용하여 SAML 토큰 기반 인증을 구성하는 자세한 단계는 SharePoint Server에서 AD FS를 사용하여 SAML 기반 클레임 인증 구성을 참조하세요.

웹 응용 프로그램의 영역 계획

영역은 웹 응용 프로그램의 동일한 사이트에 액세스하기 위한 각기 다른 논리적 경로를 나타냅니다. 각 웹 응용 프로그램에는 영역을 5개까지 포함할 수 있습니다. 웹 애플리케이션을 만들 때 중앙 관리에서 default라는 영역을 만듭니다. 영역을 추가로 만들려면 웹 응용 프로그램을 확장하고 나머지 영역 이름(인트라넷, 엑스트라넷, 인터넷 또는 사용자 지정) 중 하나를 선택합니다.

영역 계획은 다음 항목에 따라 달라집니다.

• 클레임 기반 인증(권장) - 단일 영역에서 여러 인증 공급자를 구현할 수 있습니다. 여러 영역을 사용할 수도 있습니다.

단일 영역에서 두 개 이상의 인증 유형 구현

클레임 기반 인증을 사용하며 둘 이상의 인증 방법을 구현하는 경우에는 기본 영역에서 여러 인증 방법을 구현하는 것이 좋습니다. 그러면 모든 사용자가 동일한 URL을 사용하게 됩니다.

동일한 영역에서 여러 인증 방법을 구현하는 경우에는 다음과 같은 제한이 적용됩니다.

• 영역당 하나의 양식 기반 인증 인스턴스만 구현할 수 있습니다.

• 중앙 관리를 사용하면 Windows 통합 메서드와 Basic을 동시에 사용할 수 있습니다. 그렇지 않으면 영역에서 둘 이상의 유형의 Windows 인증을 구현할 수 없습니다.

팜 하나에 여러 개의 SAML 토큰 기반 인증 공급자가 구성되어 있는 경우 웹 응용 프로그램이나 새 영역을 만들면 이러한 공급자가 모두 옵션으로 나타납니다. 동일한 영역에 여러 개의 SAML 공급자를 구성할 수 있습니다.

다음 다이어그램에서는 파트너 공동 작업 사이트의 기본 영역에 구현된 여러 인증 유형을 보여줍니다.

기본 영역에서 구현되는 여러 인증 유형

다이어그램에서는 각기 다른 디렉터리 저장소의 사용자가 동일한 URL을 사용하여 파트너 웹 사이트에 액세스합니다. 파트너 회사 주위의 파선으로 된 상자는 사용자 디렉터리와 기본 영역에 구성된 인증 유형 간의 관계를 보여 줍니다.

콘텐츠 크롤링 계획

크롤링 구성 요소에서는 NTLM을 사용하여 콘텐츠에 액세스해야 합니다. 하나 이상의 영역이 NTLM 인증을 사용하도록 구성해야 합니다. 기본 영역에서 NTLM 인증이 구성되지 않은 경우 크롤링 구성 요소는 NTLM 인증을 사용하도록 구성된 다른 영역을 사용할 수 있습니다.

두 개 이상의 영역 구현

웹 응용 프로그램에 대해 두 개 이상의 영역을 구현하려는 경우에는 다음 지침을 따르세요.

• 기본 영역을 사용하여 가장 안전한 인증 설정을 구현합니다. 요청을 특정 영역과 연결할 수 없는 경우 기본 영역의 인증 설정 및 기타 보안 정책이 적용됩니다. 기본 영역은 웹 응용 프로그램을 만들 때 작성되는 영역입니다. 일반적으로 가장 안전한 인증 설정은 최종 사용자 액세스용으로 디자인됩니다. 따라서 최종 사용자는 기본 영역에 액세스할 가능성이 높습니다.

• 사용자가 액세스할 수 있도록 하는 데 필요한 최소 영역 수만 사용합니다. 각 영역은 웹 애플리케이션에 액세스하기 위해 새 IIS 사이트 및 도메인과 연결됩니다. 필요한 경우에만 새 액세스 지점을 추가합니다.

• 하나 이상의 영역이 크롤링 구성 요소에 대해 NTLM 인증을 사용하도록 구성되어 있는지 확인합니다. 필요한 경우가 아니면 인덱스 구성 요소에 대한 전용 영역을 만들지 마세요.

다음 다이어그램에서는 파트너 공동 작업 사이트에 대한 서로 다른 인증 유형을 수용하도록 구현된 여러 개의 영역을 보여줍니다.

인증 유형당 하나의 영역

이 다이어그램에서 기본 영역은 원격 직원용으로 사용됩니다. 각 영역은 서로 다른 URL과 연결되어 있습니다. 직원은 사무실에서 일하고 있는지 아니면 원격으로 작업하는지에 따라 다른 영역을 사용합니다.