SharePoint 2010 및 Azure Access Control Service를 사용한 페더레이션 SAML 인증(1부)

Artikel
06/24/2011

최초 문서 게시일: 2011년 5월 6일 금요일

참고: 늘 생각하는 부분이지만 이 사이트는 서식이 적용되기 때문에 매우 불편합니다. 내용을 편하게 확인하려면 이 게시물에 첨부된 Word 문서를 다운로드하시기를 권합니다.

최근 Windows Azure ACS(Access Control Service)를 흥미롭게 지켜보면서 몇 가지 통합 옵션을 고려해 보았습니다. SharePoint 2010의 클레임 인증과 ADFS, Windows Live, Facebook 등을 통합하는 방법에 대한 많은 논의가 있었는데요, Azure 개발 분야와 마케팅 분야에서는 AppFabric ACS라고도 하는 ACS는 이러한 일반적인 ID 공급자에 대한 "커넥터"를 기본적으로 포함하므로 편리합니다. 따라서 ACS 네임스페이스(커넥터 및 구성 설정이 있는 계정으로 간주할 수 있음)를 설정할 때 ADFS 2.0, Windows Live, Yahoo, Google, Facebook 등에 쉽고 원활하게 연결할 수 있습니다. 프로그래머 입장에서 이는 흥미로운 기능이 아닐 수 없으므로, 두 가지 각도에서 이 기능을 살펴보기로 했습니다. 이 게시물에서는 그 중 첫 번째에 대해 설명하겠습니다.

이 시나리오에서는 SharePoint 2010과 ACS 간에 직접 트러스트를 설정하고자 했습니다. ADFS, Windows Live, Yahoo 및 Google 계정을 사용하여 SharePoint 사이트에 인증 및 로그인하는 것이죠. 개인적으로 소셜 컴퓨팅에는 관심이 없으므로(그나마 이 블로그에서 관련 내용을 약간 다루기는 하지만요.) Facebook은 포함하지 않았습니다. 저는 "우리집 야옹이가 새끼를 3마리 낳았는데 정말 귀여워요!" 같은 의미 없는 정보를 엄청나게 많은 사람들과 빈번하게 공유한다는 것에 별다른 흥미를 느끼지 못해서, Facebook이나 Twitter 계정이 없습니다. 여기서는 Windows Azure 계정을 만들고, Access Control Service 네임스페이스를 만들고, ACS를 관리하는 방법 등에 대해서는 설명하지 않습니다. 이러한 내용은 Windows Azure와 관련된 내용이므로 굳이 다시 설명할 필요는 없다고 생각합니다.

이 게시물에서는 앞서 언급한 모든 인증 계정이 함께 작동하도록 하는 데 필요한 여러 트러스트, 인증서 및 구성을 설정하는 과정에 대해 설명합니다. 이 과정을 설명한 후 마지막으로는 이러한 각 공급자의 ID로 로그인한 상태를 보여 주는 스크린샷을 포함할 것입니다. 1부에서 수행할 단계는 다음과 같습니다.

Access Control Management(액세스 제어 관리) 페이지 열기
1. Windows Azure 관리 포털에 로그인하여 왼쪽 창의 Service Bus, Access Control and Caching(서비스 버스, 액세스 제어 및 캐싱) 메뉴를 클릭합니다. 왼쪽 창 위쪽에서 AppFabric 아래의 Access Control(액세스 제어)을 클릭하고, 오른쪽 창에서 네임스페이스를 클릭한 후에 리본 메뉴의 Manage(관리) 부분에 있는 Access Control Service 단추를 클릭합니다. 그러면 Access Control Management(액세스 제어 관리) 페이지가 열립니다.
ADFS에 대해 ID 공급자 추가
1. 왼쪽 창의 Trust relationships(트러스트 관계) 메뉴에서 ID 공급자를 클릭합니다.
2. Add(추가) 링크를 클릭합니다.
3. WS-Federation ID 공급자 라디오 단추가 기본적으로 선택되어 있는지 확인하고 선택되어 있지 않으면 선택합니다. ADFS 2.0에는 이 ID 공급자를 사용합니다. Next(다음) 단추를 클릭합니다.
4. Identity Provider Settings(ID 공급자 설정) 섹션에 내용을 입력합니다.
  1. 표시 이름을 “My ADFS Server”와 같이 입력합니다.
  2. WS-Federation 메타데이터의 경우 ADFS 서버가 인터넷을 통해 표시되는 경우에는 페더레이션 메타데이터 끝점의 URL을 입력합니다. 이 URL은 기본적으로 https://yourAdfsServer.com/FederationMetadata/2007-06/FederationMetadata.xml입니다. ADFS 서버가 인터넷을 통해 표시되지 않는 경우 로컬 브라우저에서 끝점 URL을 엽니다. 브라우저로 이동하여 로컬 파일 시스템 페이지를 .XML 파일로 저장합니다. 그런 다음 ACS의 Identity Provider Settings(ID 공급자 설정)에서 File(파일) 편집 상자 옆의 라디오 단추를 클릭하고 Browse(찾아보기) 단추를 사용하여 방금 저장한 페더레이션 메타데이터 xml 파일을 찾습니다.

이러한 방법으로 ACS에서 ID 공급자를 만들 수 있습니다.

3. SharePoint에 대해 신뢰 당사자 추가

1. 이제 SharePoint와 ADFS를 함께 구성할 때와 같은 방법으로 ACS의 신뢰 당사자로 SharePoint를 추가해야 합니다. 먼저 왼쪽 창의 Trust relationships(트러스트 관계) 메뉴 아래에 있는 Relying party applications(신뢰 당사자 응용 프로그램) 링크를 클릭합니다.
2. Add(추가) 링크를 클릭합니다.
3. Relying Party Application Settings(신뢰 당사자 응용 프로그램 설정) 섹션에 내용을 입력합니다.
  1. 표시 이름을 “SharePoint 2010”과 같이 입력합니다.
  2. 기본 모드를 사용하거나 설정을 수동으로 입력합니다.
  3. Realm(영역) 편집 상자에 영역을 입력하고 저장합니다. SharePoint에서 SPTrustedIdentityTokenIssuer를 만들 때 이 영역을 다시 사용합니다. 이 예제에서는 영역을 "urn:sharepoint:acs”로 입력합니다.
  4. 반환 URL로는 ADFS에서 SharePoint를 신뢰 당사자로 설정할 때 사용했던 것과 같은 형식을 사용합니다(https://yourSiteName/_trust/).
  5. Token format(토큰 형식) 드롭다운에서는 SAML 1.1을 선택해야 합니다.
  6. Token lifetime (secs)(토큰 수명(초))은 원하는 대로 설정할 수 있습니다. 기본값은 10분입니다. 여기서는 3600(1시간)으로 설정했습니다.
4. Authentication Settings(인증 설정) 섹션에 내용을 입력합니다.
  1. Identity providers(ID 공급자) 아래의 모든 확인란을 선택합니다. 그러면 이전 단계에서 만든 ADFS ID 공급자가 표시됩니다.
  2. Rule groups(규칙 그룹) 아래에서 기본값인 Create new rule group(새 규칙 그룹 만들기)을 선택한 상태로 둡니다.
5. Token Signing Settings(토큰 서명 설정)에서는 기본 옵션인 Use service namespace certificate (standard)(서비스 네임스페이스 인증서 사용(표준))을 선택한 상태로 두면 됩니다.
6. Save(저장) 단추를 클릭하여 변경 내용을 저장하고 신뢰 당사자를 만듭니다.

4. 신뢰 당사자에 대한 규칙 만들기

1. 여기서는 이전에 ACS에서 규칙 집합을 만들지 않았다고 가정하여 새 그룹을 만들겠습니다. 다시 사용하려는 그룹이 있는 경우에는 이전 단계에서 기본값인 Create new rule group(새 규칙 그룹 만들기)을 선택하는 대신 신뢰 당사자에 사용할 그룹 옆의 확인란을 선택하면 됩니다. 그러나 여기서는 새 그룹을 만들 것이므로 왼쪽 창의 Trust relationships(트러스트 관계) 메뉴에서 Rule groups(규칙 그룹) 링크를 클릭합니다.
2. “모든 신뢰 당사자 이름에 대한 기본 규칙 그룹"과 같은 규칙 그룹이 표시됩니다. 해당 규칙 그룹 이름의 링크를 클릭합니다.
3. 여기서 작업을 수행하는 가장 쉬운 방법은 Generate(생성) 링크를 클릭하는 것입니다. 그러면 기본적으로 각 ID 공급자에서 가져올 모든 클레임을 열거하는 규칙 집합이 자동으로 만들어진 다음, 각 클레임에 대해 동일한 클레임 유형을 사용하여 해당 클레임 값을 신뢰 당사자에게 전달하는 규칙이 만들어집니다.
4. Generate Rules(규칙 생성) 페이지에서 각 ID 공급자 옆의 확인란을 선택하고 Generate(생성) 단추를 클릭합니다. 그러면 앞서 설명한 규칙이 만들어집니다. 규칙 생성이 완료되면 Edit Rule Group(규칙 그룹 편집) 페이지로 리디렉션되며, 여기에 모든 규칙이 나열됩니다. 대부분의 경우에는 여기까지만 작업을 수행해도 되지만, 이 예제에서는 한 가지 상황을 고려해야 합니다. 여기서는 SharePoint에서 전자 메일 주소를 ID 클레임으로 사용하려고 합니다. 그런데 Windows Live를 제외한모든 ID 공급자는 전자 메일 주소를 보내며 이를 위한 규칙이 만들어집니다. 따라서 이 예제에서는 Windows Live 공급자를 "가장"하는 규칙을 만들 것입니다. 즉, Windows Live에서 제공하는 클레임인 nameidentifier를 가져와서 이 클레임을 전자 메일 클레임으로 다시 전달하는 규칙을 만들 것입니다. 최소한의 요소만 변경하면서 이 데모 환경을 실행하기 위해 이러한 방식을 선택했습니다. 이제 이 마지막 규칙을 추가합니다.
5. Add(추가) 링크를 클릭합니다.
6. Identity Provider(ID 공급자) 드롭다운 목록에서 Windows Live ID를 선택합니다.
7. Input claim type(입력 클레임 유형) 섹션에서 Select type:(유형 선택:) 옆의 라디오 단추를 클릭합니다. Windows Live ID가 지원하는 클레임 유형은 nameidentifier 하나뿐이므로 이미 선택되어 있습니다.
8. 아래쪽의 Output claim type(출력 클레임 유형) 섹션으로 스크롤하여 Select type:(유형 선택:) 옆의 라디오 단추를 클릭합니다.
9. 드롭다운 목록에서 https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress를 찾아서 선택합니다.
10. 원하는 경우 설명을 입력한 다음 Save(저장) 단추를 클릭하여 변경 내용을 저장하고 규칙을 만듭니다.
11. Edit Rule Group(규칙 그룹 편집) 페이지로 리디렉션되면 Save(저장) 단추를 클릭하여 변경 내용을 모두 저장합니다. 이제 ACS 구성이 완료되었지만, 다른 구성 요소를 만들고 구성할 때 추가 정보를 확인해야 하므로 아직 브라우저를 닫지 마십시오.

5. ADFS에서 ACS에 대해 신뢰 당사자 만들기

1. ADFS는 ACS의 ID 공급자이며 ACS는 ADFS의 신뢰 당사자입니다. 즉, ACS가 인증 요청을 ADFS로 리디렉션할 때 ADFS가 응답할 수 있도록 하는 트러스트가 설정되도록 ADFS에서 신뢰 당사자를 구성해야 합니다. 먼저 ADFS 서버로 이동하여 AD FS 2.0 관리 콘솔을 엽니다.
2. AD FS 2.0 > Trust Relationships(트러스트 관계) > Relying Party Trusts(신뢰 당사자 트러스트) 노드로 이동한 다음 오른쪽 창에서 Add Relying Party Trust…(신뢰 당사자 트러스트 추가...) 링크를 클릭합니다.
3. Start(시작) 단추를 클릭하여 마법사를 시작합니다.
4. 기본 옵션을 사용하여 온라인에 게시된 신뢰 당사자에 대한 데이터를 가져옵니다. 사용해야 하는 URL은 ACS 관리 포털에서 확인할 수 있습니다. 포털이 열려 있는 브라우저로 돌아가서 왼쪽 창의 Trust relationships(트러스트 관계) 메뉴 아래에 있는 Application Integration(응용 프로그램 통합) 링크를 클릭합니다.
5. WS-Federation 메타데이터에 대해 표시된 URL을 복사하여 ADFS 마법사의 Federation metadata address (host name or URL)(페더레이션 메타데이터 주소(호스트 이름 또는 URL)) 편집 상자에 붙여 넣고 Next(다음) 단추를 클릭합니다.
6. 표시 이름을 입력하고 원하는 경우 메모를 입력한 후에 Next(다음) 단추를 클릭합니다.
7. 모든 사용자가 신뢰 당사자에 액세스하도록 허용하는 기본 옵션을 그대로 두고 Next(다음) 단추를 클릭합니다.
8. Next(다음) 단추를 클릭하면 신뢰 당사자가 만들어집니다.
9. 신뢰 당사자가 만들어지면 ADFS에서 규칙 편집기를 열어서 클레임 값을 ACS로 전달하는 새 규칙을 만들 수 있습니다.
10. Issuance Transform Rules(발급 변환 규칙) 탭을 선택한 상태로 Add Rule...(규칙 추가...) 단추를 클릭합니다.
11. 기본 서식 파일인 Send LDAP Attributes as Claims(LDAP 특성을 클레임으로 보내기)를 선택한 상태로 두고 Next(다음) 단추를 클릭합니다.
12. 나머지 규칙 세부 정보를 입력합니다.
  1. 클레임 규칙 이름을 입력합니다.
  2. Attribute store:(특성 저장소:) 드롭다운에서 Active Director(활성 디렉터)를 선택합니다.
  3. Mapping of LDAP attributes(LDAP 특성 매핑) 섹션에서 각 항목을 다음과 같이 매핑합니다.
    1. LDAP 특성 E-Mail-Addresses(전자 메일 주소)를 Outgoing Claim Type E-Mail Address(보내는 클레임 유형 전자 메일 주소)에 매핑합니다.
    2. LDAP 특성 Token-Groups – Unqualified Names(토큰 그룹 - 정규화되지 않은 이름)를 Outgoing Claim Type Role(보내는 클레임 유형 역할)에 매핑합니다.
  4. Finish(마침) 단추를 클릭하여 규칙을 저장합니다. 이제 ADFS 구성이 완료되었습니다.

6. ACS와의 SharePoint 트러스트 구성

1. 트러스트를 구성하는 프로세스는 여러 단계로 구성되며, 먼저 ACS에서 토큰 서명 인증서를 가져오는 단계부터 수행합니다. 이 인증서는 FederationMetadata.xml 파일에 포함되어 있으므로 이 파일에서 인증서를 검색하여 SharePoint Server에 로컬로 저장합니다. SharePoint Server에서 브라우저를 열고 위에서 설명한 것처럼 Access Control Management(액세스 제어 관리) 페이지를 엽니다.
2. 왼쪽 창에서 Trust relationships(트러스트 관계) 메뉴 아래의 Application Integration(응용 프로그램 통합) 링크를 클릭하고 WS-Federation 메타데이터에 대해 표시된 URL을 복사한 다음 브라우저에 붙여 넣습니다. ACS FederationMetadata.xml 파일이 브라우저에 표시됩니다.
3. 다음과 같은 섹션을 찾습니다. 이 섹션은 페이지 맨 위에서 아래쪽으로 두 번째 주요 섹션쯤에 있습니다.

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

X509Certificate 요소에서 데이터를 복사하여 메모장에 붙여 넣은 다음 .CER 파일 확장명으로 저장합니다. 이때 ANSI 인코딩을 사용해야 합니다. 이 게시물에서는 파일 이름을 C:\AcsTokenSigning.cer로 지정하겠습니다. 이 파일이 ACS의 토큰 서명 인증서입니다.

1. ACS 토큰 서명 인증서를 SharePoint의 신뢰할 수 있는 루트 기관 목록에 추가합니다. 이 작업은 https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx(영문일 수 있음)의 설명에 따라 수행할 수도 있고, PowerShell을 사용하여 다음과 같이 추가할 수도 있습니다.

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

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

1. 다음 단계에서는 SPTrustedIdentityTokenIssuer를 새로 만듭니다. 이 작업을 수행하는 방법은 여러 게시물을 통해 소개한 바 있습니다. https://blogs.msdn.com/b/sharepoint_ko/archive/2010/11/17/sharepoint-2010-adfs-v2.aspx의 내용을 참고할 수 있습니다(아래쪽에 나오는 ADFS 설정 내용 뒷부분의 정보로 스크롤). 다음과 같은 몇 가지 사항을 기억하십시오.
  1. name과 nameidentifier는 모두 SharePoint에서 예약된 클레임 유형이므로, ACS의 표준 ID 공급자에 대해 공통 클레임이 nameidentifier뿐이더라도 ID 클레임 옵션으로는 제공되지 않습니다. 대신, 위에서 설명한 것처럼 전자 메일 주소를 전달하고 ACS에서 적절한 규칙을 추가하는 것이 좋습니다.
  2. New-SPTrustedIdentityTokenIssuer의 SignInUrl 매개 변수는 https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation과 같이 ACS 인스턴스를 가리켜야 합니다. ACS에 대해 ADFS에서 설정한 신뢰 당사자를 확인하면 이 매개 변수를 찾을 수 있습니다. 이렇게 하려면 Relying Party properties(신뢰 당사자 속성) 대화 상자를 열고 Endpoints(끝점) 탭을 클릭한 다음 POST 바인딩용으로 WS-Federation 패시브 끝점에 대해 표시되는 URL을 사용합니다. 표시되는 URL은 하나뿐입니다.
2. 마지막 단계에서는 웹 응용 프로그램을 만들고, ACS에 대해 만든 SPTrustedIdentityTokenIssuer 및 클레임 인증을 사용하도록 구성하고, 마지막으로 웹 응용 프로그램에서 사이트 모음을 만들어 테스트를 시작합니다.

이 시점이 되면 사이트를 방문하여 인증을 시험해 볼 수 있습니다. 사이트 모음 관리자를 ID 공급자 중 하나가 반환하는 전자 메일 중 하나로 구성해야 사이트에 로그인할 수 있습니다. 이렇게 구성하고 나면 일반적인 방법으로 공급자의 전자 메일 주소 또는 역할 클레임을 SharePoint 그룹에 추가할 수 있습니다.

이 게시물의 앞부분에서도 설명한 것처럼, Windows Live ID에 주의해야 합니다. Windows Live에 대한 유효한 전자 메일 주소는 없기 때문에, SharePoint 그룹에 "PUID"를 추가해야 합니다. 테스트를 위해 이 작업을 가장 간편하게 수행하려면, Windows Live ID를 사용하여 로그인합니다. 그러면 사용자가 "foo"로 로그인되었다는 메시지가 표시된 SharePoint 페이지가 표시되며, 액세스가 거부됩니다. 이 페이지에서 PUID를 복사하여 관리 사용자로 로그인한 다음 SharePoint 그룹에 PUID를 추가하면 됩니다. Windows Live ID에 대해 사용 가능한 디렉터리 옵션은 살펴보지 않았는데요, 아마 없을 것으로 예상됩니다. 이 예제에서는 최초 테스트를 수행하므로 이러한 개념을 기반으로 진행할 수 있을 것으로 보입니다. 이제 작업이 완료되었으며, 각 ID 공급자를 사용하여 사이트에 로그인한 상태의 스크린샷은 다음과 같습니다.

로그인 페이지

ADFS

Google

Yahoo

Windows Live ID

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1을 참조하십시오.

Freigeben über

SharePoint 2010 및 Azure Access Control Service를 사용한 페더레이션 SAML 인증(1부)

Zusätzliche Ressourcen