Freigeben über


SharePoint 2010과 ADFS v2 종단 간 구성

SharePoint 2010과 ADFS v2 종단 간 구성

이 게시물에서는 SAML 클레임 인증을 사용하도록 SharePoint 2010과 ADFS v2를 함께 구성하는 방법을 포괄적으로 소개하겠습니다. 또한 시연할 단계 및 PowerShell 스크립트를 포함하고 모든 항목을 모아 하나의 긴 게시물로 정리할 예정입니다.

먼저 관련된 구성 요소와 수행해야 할 작업에 대해 간략히 설명하겠습니다. 이 시나리오에서 ADFS v2는 IP-STS(Security Token Service)라고도 하는 ID 공급자입니다. 여기서는 RP(신뢰 당사자)에 대한 정보를 사용하여 ADFS를 구성해야 합니다. 이 경우에는 SharePoint가 RP에 해당하지만 이는 인증을 수행하고 클레임을 제공하는 ADFS에 따라 달라집니다. SharePoint 측면에서는 SharePoint가 클레임을 전송하는 IP-STS를 신뢰하도록 구성해야 하며 그런 다음 이러한 클레임을 사용할 웹 응용 프로그램과 사이트를 설정해야 합니다.

먼저 ADFS에서 신뢰 당사자를 만드는 것으로 과정을 시작하겠습니다. 이러한 작업을 수행하는 데 있어 순서는 중요하지 않지만 관례상 저는 대개 ADFS를 먼저 구성합니다. 따라서 ADFS가 설치된 서버로 이동하여 AD FS 2.0 관리 응용 프로그램을 엽니다. 트러스트 관계(Trust Relationships) 노드를 확장하고 신뢰 당사자 트러스트(Relying Party Trusts) 노드를 클릭합니다.

오른쪽 창의 신뢰 당사자 트러스트 추가(Add Relying Party Trust) 링크를 클릭하여 신뢰 당사자 트러스트 추가 마법사(Add Relying Party Trust Wizard)를 시작합니다.

시작(Start) 단추를 클릭하여 작업을 계속 수행합니다.

신뢰 당사자에 대한 데이터를 수동으로 입력(Enter data about the relying party manually) 옵션을 선택하고 다음(Next) 단추를 클릭합니다.

표시 이름(Display name)을 입력하고 경우에 따라 신뢰 당사자에 대한 설명을 입력한 후 다음(Next) 단추를 클릭합니다.

AD FS 2.0 프로필을 사용하는 옵션을 선택하고 다음(Next) 단추를 클릭합니다.

인증서를 선택하여 SAML 토큰 자체를 암호화할 수 있지만 이는 자주 사용되지 않는 방식입니다. ADFS를 사용하려면 SSL을 통해 SharePoint에 연결해야 하는데 토큰을 전송하는 데 사용되는 채널이 이미 암호화되어 있기 때문입니다. 다음(Next) 단추를 클릭합니다.

WS-Federation Passive 프로토콜 지원 사용(Enable support for the WS-Federation Passive protocol) 확인란을 선택합니다. 프로토콜 URL의 경우 SharePoint 웹 응용 프로그램의 루트 사이트 URL을 입력하고 “_trust” 하위 디렉터리를 포함해야 합니다. 이 예에서 제 SharePoint 웹 응용 프로그램의 URL은 https://seo14이므로 WS-Federation Passive 프로토콜 URL은 https://seo14/_trust/가 됩니다. URL을 입력한 후 다음(Next) 단추를 클릭합니다.

신뢰 당사자 트러스트 식별자(Relying party trust identifier)로는 사용자가 웹 응용 프로그램에 로그인할 때 웹 응용 프로그램에서 ADFS로 전달하는 영역을 입력해야 합니다. 이 영역은 대개 urn:foo:bar 형식으로 만들어지며 웹 응용 프로그램과 연결되어 있고 ADFS에서 들어오는 로그인 요청을 신뢰 당사자 트러스트에 매핑하는 방식과 관련이 있습니다. SharePoint와 함께 사용할 경우 ADFS에서는 로그인 요청과 연결된 영역을 인식하고 이를 조회하여 신뢰 당사자 트러스트를 확인한 다음 사용자를 인증한 후 해당 WS-Federation Passive 프로토콜 URL에 유의하여 나중에 사용자를 리디렉션할 위치를 파악합니다. 따라서 이 경우에는 영역을 urn:seo:sharepoint로 입력했습니다. 제 SharePoint 사이트인 https://seo14로 이동하려고 하면 ADFS로 리디렉션되므로 SharePoint에서 이러한 요청에 대해 urn:seo:sharepoint 영역을 사용하도록 구성하겠습니다. ADFS에서는 저에 대한 인증이 완료되면 저를 다시 https://seo14/_trust/로 리디렉션하는데, 이는 이 URL이 해당 신뢰 당사자에 대한 수동 프로토콜 URL이기 때문입니다. 여기서 사용할 원하는 아무 영역이나 추가하고 나중에 SharePoint를 구성할 때 다시 입력해야 하므로 해당 영역을 기록해 둡니다. 다음(Next) 단추를 클릭합니다.

대부분의 경우 모든 사용자가 이 신뢰 당사자를 사용할 수 있도록 할 것입니다. 따라서 이 시나리오에서도 이러한 경우를 가정할 예정이므로 기본 선택 항목을 그대로 사용하고 다음(Next) 단추를 클릭합니다.

신뢰 당사자 트러스트의 다른 구성을 변경해야 한다면 여기서 변경하면 됩니다. 이 상황에서는 그럴 필요가 없으므로 다음(Next) 단추를 클릭하여 계속 진행하면 됩니다.

신뢰 당사자 트러스트의 구성을 마쳤지만 여전히 ADFS에 SharePoint로 돌려보낼 클레임을 알려 주는 클레임 규칙을 만들어야 합니다. 따라서 클레임 규칙 편집 대화 상자 열기(Open the Edit Claim Rules dialog)를 선택된 상태로 두고 닫기(Close) 단추를 클릭합니다.

이제 새 규칙을 만들 예정이므로 규칙 추가…(Add Rule…) 단추를 클릭합니다.

이 경우 Active Directory에서 정보를 가져오므로 LDAP 특성을 클레임으로 전송하게 됩니다. 즉, 우리는 ADFS에서 인증을 수행하고 ADFS에서는 회사 Active Directory를 사용하여 우리를 인증하고 해당 특성을 확인하게 됩니다. 따라서 기본값을 선택된 상태로 두고 다음(Next) 단추를 클릭하여 계속 진행합니다.

클레임 규칙 이름(Claim rule name)을 입력하는 것으로 시작하겠습니다. 원하는 아무 이름이나 입력하면 됩니다. 그런 다음 특성 저장소(Attribute store) 드롭다운 목록에서 Active Directory를 선택합니다. 다음으로 이 시나리오에서는 전자 메일 주소와 사용자가 다시 SharePoint에 속하게 되는 그룹을 전송하려고 합니다. 전자 메일 주소를 특정 개인에 대한 식별자로 사용할 예정이며 사용자가 속해 있는 모든 그룹이 역할(Role) 클레임에서 전송되도록 하려고 합니다. 매핑을 수행하기 위해 왼쪽의 드롭다운 목록에서 원하는 특성을 선택한 다음 오른쪽 창의 드롭다운 목록에서 전송할 클레임을 선택합니다. 여기서는 Active Directory의 E-Mail-Addresses 특성이 표준 전자 메일 주소(E-Mail Address) 클레임에서 전송되도록 하려고 합니다. 또한 사용자가 속하는 그룹은 표준 역할(Role) 클레임에서 전송되도록 하려고 합니다. 이 경우 그룹 이름을 그룹의 이름을 나타내는 단순한 문자열로 전송하도록 토큰 그룹 – 비정규화된 이름(Token-Groups – Unqualified Names)을 선택했습니다. 그룹의 SID를 전송할 수도 있지만 이렇게 하면 SharePoint 그룹에 역할(Role) 클레임을 할당하려고 할 때 사용하기가 더 까다로워집니다. 여기에 설명된 대로 이 규칙의 구성을 마쳤으면 마침(Finish) 단추를 클릭하여 규칙을 완성합니다.

확인(OK) 단추를 클릭하여 ADFS에서 신뢰 당사자 트러스트를 만드는 절차를 완료합니다. ADFS의 구성 측면에서는 더 이상 수행할 작업이 없습니다. 그러나 ADFS에서 가져와야 할 것이 한 가지 더 있습니다. ADFS에서는 인증서를 사용하여 전송하는 토큰에 서명합니다. 이를 통해 토큰 소비자는 토큰이 만들어진 이후 조작되지 않았음을 확인하게 됩니다. SharePoint를 구성하려면 이 인증서의 복사본이 필요합니다. SharePoint에서 ADFS를 IP-STS로 사용하도록 구성할 때 이 인증서를 사용해야 하기 때문입니다. ADFS에서 이 토큰 서명 인증서를 가져오려면 서비스(Service) 노드를 확장하고 인증서(Certificates) 노드를 클릭합니다.

여기에 토큰 서명 인증서를 위한 섹션이 있습니다. 일대다 토큰 서명 인증서를 사용할 수 있지만 기본 토큰 서명 인증서는 항상 하나만 있습니다. 해당 인증서를 클릭하고 오른쪽 창에서 인증서 보기(View Certificate) 링크를 클릭합니다.

이 경우에는 ADFS 웹 사이트에서 SSL에 대해 만든 인증서를 사용하도록 선택했습니다. 이는 반드시 이렇게 해야 한다거나 이렇게 하는 것이 좋다고 제안하는 것은 아니며 그냥 제가 선택한 방식입니다. 이제 인증서를 확인하므로 대화 상자 맨 위에서 세부 정보(Details) 탭을 클릭합니다.

파일에 복사…(Copy to File…) 단추를 클릭합니다. 그러면 인증서 복사본을 디스크에 저장하기 위한 마법사가 시작됩니다.

다음(Next) 단추를 클릭하여 계속 진행합니다.

개인 키를 사용할 필요는 없으므로 기본 설정을 그대로 사용하고 다음(Next) 단추를 클릭합니다.

기본 형식이 양호하므로 다음(Next) 단추를 클릭하여 계속 진행합니다.

인증서를 저장할 위치를 선택하고 다음(Next) 단추를 클릭합니다. 인증서를 저장한 위치에서 SharePoint 서버로 복사해야 하므로 이 위치를 기억해 두어야 합니다.

인증서를 로컬로 복사하는 데 필요한 모든 정보를 캡처했으므로 이제 마침(Finish) 단추를 클릭하여 마법사를 완료하고 인증서를 로컬 파일에 저장합니다. 이 파일을 SharePoint 서버에 복사하면 ADFS 서버에 대한 절차가 완료됩니다.

이번에는 SharePoint 서버로 전환하여 이를 구성하는 단계를 시작하겠습니다. SharePoint를 구성하기 전에 지금 새 웹 응용 프로그램을 만드는 것이 좋습니다. 이 웹 응용 프로그램을 만들어 클레임 인증을 사용하지만 인증 설정에 대해서는 Windows 통합 인증 – NTLM을 선택합니다. 웹 응용 프로그램에서 포트 443을 사용하도록 구성하고 SSL(Secure Sockets Layer) 사용 라디오 단추를 선택합니다. 웹 응용 프로그램을 만든 후에는 IIS 관리자로 가서 적절한 SSL 인증서를 할당할 수 있도록 새 가상 서버에 대한 바인딩을 편집합니다. 이러한 단계는 이 게시물의 범위를 벗어나지만 인터넷의 여러 위치에 잘 정리되어 있습니다. 요약하자면 여기서는 포트 443 및 SSL을 사용하는 제가 만든 웹 응용 프로그램이 하나 있고 이 웹 응용 프로그램의 URL은 https://seo14입니다.

SharePoint 쪽에서 수행할 첫 번째 작업은 ADFS 서버에서 복사한 토큰 서명 인증서를 추가하는 것입니다. 하지만 이 작업을 수행하기 전에 먼저 인증서를 확인해야 합니다. 토큰 서명 인증서는 해당 인증서 체인에 상위 인증서가 하나 이상 있을 수 있습니다. 하나 이상의 상위 인증서가 있는 경우 해당 체인의 모든 인증서를 SharePoint의 신뢰할 수 있는 상위 인증 기관 목록에 추가해야 합니다. 이해를 돕기 위해 ADFS에서 복사한 토큰 서명 인증서를 찾아 두 번 클릭하겠습니다. 그러면 인증서 속성 창이 나타납니다. 인증 경로(Certification Path) 탭을 클릭하면 체인에 다른 인증서가 있는지 여부를 확인할 수 있습니다. 여기서 제 토큰 서명 인증서에는 상위 인증서가 있으며, 이는 상위 인증 기관의 인증서입니다.

이제 해야 할 일은 위의 체인에서 제 토큰 서명 인증서 위에 있는 각 인증서에 대해 각 인증서의 복사본을 로컬로 저장하는 것입니다. 이를 위해 인증서를 클릭하면 대화 상자에서 인증서 보기(View Certificate) 단추가 사용하도록 설정됩니다. 이 단추를 클릭하면 해당 인증서에 대한 별도의 속성 대화 상자가 열립니다. 그러면 앞에서 설명한 것과 동일한 절차에 따라 인증서의 복사본을 디스크에 저장할 수 있습니다. 즉, 세부 정보(Details) 탭을 클릭하고 파일에 복사…(Copy to File…) 단추를 클릭한 다음 인증서를 .CER 파일로 로컬에 저장합니다. 여기서는 이 작업을 수행하여 C:\adfsParent.cer에 저장했습니다. 따라서 이제 제 SharePoint 서버에는 두 개의 인증서가 있습니다.

· C:\adfs.cer - ADFS 서버에서 복사한 토큰 서명 인증서

· C:\adfsParent.cer - 토큰 서명 인증서에 대한 상위 인증서

이러한 두 개의 인증서가 생겼으므로 이제 이를 제 신뢰할 수 있는 상위 인증 기관 목록에 추가해야 합니다. 이 작업은 다음 스크립트를 사용하여 PowerShell에서 수행하겠습니다.

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfsParent.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfs.cer ")

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

PowerShell에서 이러한 명령을 실행하면 다음과 같은 결과가 출력됩니다.

다음에는 SharePoint에서 사용할 클레임 매핑을 만들겠습니다. 이 문서의 앞부분을 떠올리면 제가 SharePoint에서 전자 메일 주소 및 역할 클레임을 사용할 것이라고 말한 내용이 기억나실 것입니다. 다음은 이러한 매핑을 만드는 데 사용할 PowerShell입니다.

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

다음에는 SharePoint에서 사용하도록 할 영역에 대한 변수를 만들겠습니다. 여기서는 urn:seo:sharepoint 영역을 사용하겠다고 이미 얘기했습니다. 다음은 제 영역 변수를 만들기 위한 PowerShell입니다.

$realm = "urn:seo:sharepoint"

이제 제 SPTrustedIdentityTokenIssuer를 만들 준비가 완료되었습니다. 여기서 모든 구성 정보를 취합하므로 SharePoint에서는 IP-STS를 연결하고 이를 사용하여 작업을 수행하는 방법을 인식하게 됩니다. 여기서 PowerShell을 소개한 다음 중요한 부분에 대해 설명하겠습니다.

$ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "https://congen1.contoso.local/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

“Name” 특성은 웹 응용 프로그램에서 사용할 인증 공급자를 구성할 때 해당 웹 응용 프로그램에 나타납니다. “realm” 특성에서는 SharePoint에서 이 신뢰할 수 있는 ID 토큰 발급자와 함께 사용하도록 할 영역을 연결합니다. “ImportTrustCertificate” 특성에는 ADFS 서버에서 복사한 토큰 서명 인증서를 전달합니다. “ClaimsMappings” 특성에는 이 신뢰할 수 있는 ID 토큰 발급자에서 사용하도록 할 클레임을 알려 줍니다. “SignInUrl”은 IP-STS로 인증하도록 사용자가 리디렉션되는 URL입니다. 이 경우 사용자가 Windows 통합 보안을 사용하는 ADFS 서버로 인증하도록 하려고 하므로 사용자를 /adfs/ls 하위 디렉터리로 보냅니다. 마지막으로 “IdentifierClaim” 특성은 사용자를 식별하는 데 사용할 thee 클레임을 SharePoint에 알려 줍니다. 여기서는 전자 메일 주소를 사용하여 사용자를 식별한다고 설명했습니다.

마지막 PowerShell 명령을 실행하고 나면 SharePoint 웹 응용 프로그램과 함께 사용할 수 있는 SPTrustedIdentityTokenIssuer를 얻게 됩니다. 따라서 이제 브라우저를 열고 중앙 관리로 이동하겠습니다. 웹 응용 프로그램 관리 링크를 클릭하고 목록에서 ADFS를 사용하여 인증을 수행할 웹 응용 프로그램을 클릭한 다음 리본의 인증 공급자 단추를 클릭합니다. 대화 상자에서 ADFS를 사용하여 인증을 수행하려는 영역에 해당하는 링크를 클릭합니다. 아래쪽의 인증 유형 섹션으로 스크롤합니다. 이제 NTLM의 선택을 취소할 수 있으며 신뢰할 수 있는 공급자 목록에 “SAML Provider”라는 새 공급자가 나타납니다.

이 공급자 옆에 있는 확인란을 선택하고 저장 단추를 클릭하여 변경 내용을 저장합니다. 이제 웹 응용 프로그램의 사이트 모음으로 이동하고 사이트 모음을 만들 수 있습니다. 이 프로세스를 단계별로 설명하는 것은 이 게시물의 범위를 벗어나지만 이를 수행할 때 기억해야 할 한 가지 중요한 사항이 있습니다. 사이트 모음 관리자를 추가하는 경우 반드시 ID 클레임 형식으로 이름을 입력해야 합니다. 예를 들어 이 시나리오에서 ID 클레임은 전자 메일 주소입니다. 따라서 저는 사이트 모음 관리자를 추가할 때 사이트 모음 관리자로 지정할 사용자의 전자 메일 주소인 administrator@contoso.local이라는 이름을 사용했습니다.

이제 새 사이트 모음으로 이동하여 시험해 볼 준비를 마쳤습니다. 먼저 브라우저를 열고 https://seo14를 입력한 다음 Enter 키를 누릅니다. 가장 먼저 발생하는 일은 제 웹 응용 프로그램과 연결된 SPTrustedIdentityTokenIssuer의 SignInUrl로 리디렉션되는 것입니다. SPTrustedIdentityTokenIssuer를 만들 때 사용한 PowerShell을 떠올려 보면 이 URL은 https://congen1.contoso.local/adfs/ls입니다. 따라서 여기서 브라우저에 제 SharePoint 사이트의 URL을 입력하면 다음과 같은 결과가 발생합니다.

이제 브라우저 창의 URL이 제 ADFS 서버를 가리키고 있으며 로그인 대화 상자의 배경에 있는 그림이 ADFS 서버를 나타내는 것임을 확인할 수 있습니다. 또한 제 Windows 자격 증명인 domain\user를 사용하여 로그인하고 있음을 확인할 수 있습니다. 제가 이렇게 할 수 있는 것은 SharePoint가 아닌 ADFS 서버에서 인증을 수행하기 때문입니다. SharePoint는 전자 메일 주소를 제 ID로 사용하도록 구성되어 있지만, 실제로 발생하는 작업은 제가 ADFS에서 인증을 수행하면 ADFS에서는 위에서 만든 클레임 규칙을 사용하여 제 전자 메일 주소와 그룹을 수집하고 이를 SharePoint로 돌려보낼 클레임에 집어넣는 것입니다. 따라서 저는 인증을 수행한 후 ADFS에서 설정한 신뢰 당사자에 구성한 대로 SharePoint의 URL인 https://seo14/_trust/로 리디렉션됩니다. 여기서 SharePoint는 SAML 토큰에서 가져온 클레임을 사용하여 이를 SPUser로 변환함으로써 해당 측면에서 인증 프로세스를 완료하게 됩니다. 그러면 저는 마침내 사이트의 홈 페이지로 이동하게 됩니다.

페이지 오른쪽 위의 로그인 컨트롤에서 제 ID를 전자 메일 주소로 표시하고 있음을 확인할 수 있을 것입니다. 이는 이 전자 메일 주소가 제 ID 클레임이기 때문입니다.

여기까지가 약간 확장한 전체 종단 간 프로세스입니다. 위의 지침에 따라 이 프로세스를 사용하여 사이트를 구성하고 실행할 수 있게 되기를 바랍니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 SharePoint 2010과 ADFS v2 종단 간 구성을 참조하십시오.