SharePoint 2013의 OAuth 및 리하이드레이션된 사용자 - 작업 방법 및 알아야 할 사항
최초 문서 게시일: 2012년 8월 16일 목요일
SharePoint에 대한 블로깅과 관련하여 마음에 드는 것 중 하나는 제 블로그 제목처럼 완전히 구어체로 사용할 수 있다는 점입니다. 새로운 버전의 SharePoint를 만들지 않는 한 잘 해내는 것이 불가능한 경우도 있습니다. SharePoint 2013에서 "기다리게 해서 미안해요. 거의 다 됐어요."와 같은 친근한 메시지를 본 적이 있나요? 제 친구 Tom이 지난 번에 다룬 HRESULT와 같은 것으로 변화를 주어서 더 재미 있습니다. 음…바뀌는 것이 많을수록 그대로인 것도 많아집니다.
다시 주제로 돌아가서, 이 블로그에서 SharePoint 2013의 새로운 기능을 설명할 때 oAuth에 대해 이미 한 두 차례 언급했습니다. "oAuth란 무엇인가"란 주제에 대해서는 전문 작성자 팀이 있으므로 여기서도 자세히 다루지는 않겠습니다. 다만 oAuth를 사용하는 방법과 관련하여 내용을 약간 보강하려고 합니다. oAuth 트러스트에 대한 가장 적합한 예로는 검색을 위한 원격 SharePoint 인덱스를 들 수 있습니다. 이 기능을 사용하여 한 팜의 사용자가 다른 SharePoint 팜과 관련된 쿼리를 실행할 수 있습니다. 그러면 해당 원격 SharePoint 팜에서는 검색 결과가 적절히 보안 조정되도록 사용자 ID를 다시 구성할 수 있습니다. 이 기능은 새 앱 모델과 같은 다른 시나리오(이 사용자에게 앱에서 요청하는 콘텐츠에 대한 액세스 권한이 있음) 및 SharePoint와 Exchange 같은 서버 응용 프로그램 간(이 사용자에게 사서함 콘텐츠에 대한 액세스 권한이 있음)에도 사용됩니다. 원격 SharePoint 인덱스는 모든 작업이 예상한 대로 수행되도록 우리가 하는 작업의 수행 하는 이유를 설명하는 데 가장 적합한 시나리오입니다.
먼저 FarmA가 FarmB에서 "Steve"를 찾는 "Steve를 만드는" 방법을 알아 보겠습니다. 모든 작업은 사용자 프로필 응용 프로그램에서 시작합니다. Steve는 FarmB에 있고 쿼리를 실행합니다. 이 쿼리는 FarmA에 Steve에 대한 일부 특성과 함께 전송됩니다. 기본적으로 이러한 특성은 Steve의 SMTP 주소, SIP 주소, 계정 이름, 이름 식별자 등입니다. FarmA에서 요청을 가져올 때 가장 먼저 로컬 사용자 프로필 응용 프로그램을 조회하여 전송된 Steve에 대한 값과 일치하는 프로필을 찾습니다. 이는 UPA가 정상적이고 SharePoint 2013에 채워지는지 확인하는 것이 중요한 이유이자 내가 이 작업과 관련하여 이 블로그 기사를 작성하는 이유이기도 합니다. https://blogs.msdn.com/b/sharepoint_ko/archive/2012/09/20/sharepoint-2013-ad-saml.aspx.
이제 FarmA에서 Steve 사용자 프로필을 찾았으므로 어떻게 해야 합니까? 여기서 대답은 "경우에 따라 다르다"입니다. 따라서 조직의 이 특징을 계획하는 것이 매우 중요합니다. 사용 중인 인증 유형에 따라 다음과 같이 달라집니다.
- Windows 클레임 - Windows 클레임을 사용 중이면 대부분의 경우 필요한 모든 것이 사용자 프로필에 있습니다. 사용자의 계정 이름과 AD 그룹 멤버 자격이 있습니다. "대부분의 경우"의 의미에 대해 잠시 설명하겠습니다. 간단히 말해서 Windows 클레임을 사용하는 것이 매우 좋습니다.
- 양식 기반 인증 클레임 - FBA를 사용할 경우 알아야 할 몇 가지 사항이 있습니다. 먼저 UPA를 채우고 최신의 상태로 유지할 방법이 필요합니다. FBA를 LDAP 공급자와 함께 사용하고 디렉터리가 실제로 Windows Active Directory인 경우 매우 유리한 상태에 있습니다. Active Directory에 대한 프로필 연결을 만든 후 위에 연결된 게시물에서 설명한 것과 비슷한 방법으로 FBA 공급자와 연결합니다. 하지만 대부분의 경우 AD는 공급자가 아니므로 UPA를 채우려면 일부 사용자 지정 코드를 직접 작성해야 합니다. FBA 사용자에 대해 실제로 고려해야 할 특성 즉, 계정 이름만 가져오면 충분합니다. 아시다시피 "대부분의 경우" 데이터의 나머지는 역할 공급자로부터 얻습니다. 정말 유용한 것은 FBA 사용자를 원상으로 되돌릴 때 연결된 역할 공급자를 호출하므로 FBA 사용자가 로컬로 로그온한 것과 같습니다. 그러면 FBA 사용자에 대한 모든 역할 클레임을 확보할 수 있습니다.
- SAML 클레임 - 가장 먼저 UPA를 채워야 한다는 점에서 FBA와 비슷합니다. 다행히도 사용자가 AD에 있다면 위에 연결된 블로그 게시물의 지침에 따라 클레임을 직접 가져올 수 있습니다. 그렇지 않으면 원본 디렉터리에 연결한 다음 클레임을 가져와야 합니다. 이 경우 직접 소유하지 않은 일대다 디렉터리가 존재할 수 있으므로(즉, 파트너가 있거나, ACS와 연결되어 있거나, Facebook 또는 다른 공급자를 사용 중일 수 있음) SAML 클레임에서 가장 복잡해질 수 있습니다. 그럼에도 불구하고, 이 모든 "정보"를 사용하려면 UPA를 채울 수 있는 방법을 찾아야 합니다. 또한, SAML 사용자로 로그인한 경우 ID 공급자(IdP)로부터 클레임을 가져옵니다. 이 사용자 원상 회복 프로세스에는 로그인을 시뮬레이션하는 방법이 없습니다. 이는 SAML의 특성입니다. 즉, 일대다로 리디렉션되고 고려되지도 않은 인증 프롬프트 및 인증 유형(예: 2요소 인증)을 제공할 수 있습니다. 그런 말이 무슨 의미가 있겠습니까? 클레임을 사용하여 콘텐츠 보안을 설정하고 이 사용자 원상 복구 프로세스를 통해 콘텐츠에 대한 액세스 권한을 부여하려면 클레임 확대를 통해 클레임을 추가해야 합니다. 원상 복구 중에 IdP로부터 클레임을 가져오지 않을 것이므로 원하는 경우 로컬로 권한을 부여합니다. 이것이 위에서 설명한 "대부분의 경우"의 의미이며 이제 설명하겠습니다.
- "대부분의 경우"란 어떤 의미입니까? 이제 분명하게 아셨기를 바랍니다. Windows 사용자이든, FBA 사용자이든, SAML 사용자이든 상관없이 인증 공급자로부터 가져오는 클레임 외에도 확대를 통해 추가된 클레임이 있을 수 있습니다. https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx(영문일 수 있음). 원상 복구 프로세스 중에 수행한 다른 작업으로 모든 등록된 사용자 지정 클레임 공급자를 호출했습니다. 그러면 로컬로 로그온하여 공급자를 호출한 경우에 해당 공급자가 수신한 원상 복구된 사용자에 대한 추가 클레임도 확보할 수 있습니다.
이것이 제가 필요한 계획을 설명할 때 원격 SharePoint 인덱스 시나리오를 좋아하는 이유입니다. 생각하시는 것처럼 팜 내에서 Windows 그룹, FBA 역할, SAML 클레임 또는 확대를 통해 추가된 클레임을 기반으로 콘텐츠에 대한 권한을 부여할 수 있습니다. 콘텐츠를 쿼리할 때 이러한 클레임을 소유하지 않은 경우 보안이 조정되어 콘텐츠가 표시되지 않습니다. 따라서 로컬로 로그인할 때 부여되는 모든 클레임과 사용자 버전을 원상 복구할 때 가져오는 클레임이 모두 중요합니다.
이 모든 것을 가능하게 하는 많은 잠재적인 계획이 있으므로 변화하는 주요 요소를 식별하여 주력할 항목이 무엇인지 파악할 수 있기를 바랍니다.
이 문서는 번역된 블로그 게시물입니다. 원본 문서는 OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know를 참조하십시오.