페더레이션

페더레이션을 사용하면 권한 부여 권한을 다른 구성원에게 위임할 수 있습니다. 예를 들어 다음과 같은 비즈니스 문제를 고려합니다. 자동차 부품 제조 회사 Contoso Ltd는 고객 Fabrikam Inc.의 승인된 직원이 Contoso의 부품 주문 웹 서비스에 안전하게 액세스할 수 있도록 허용하려고 합니다. 이 시나리오의 한 가지 보안 솔루션은 Contoso가 Fabrikam을 사용하여 액세스 권한 부여 결정을 Fabrikam에 위임하는 트러스트 메커니즘을 설정하는 것입니다. 이 프로세스는 다음과 같이 작동할 수 있습니다.

• Fabrikam은 Contoso의 파트너가 되면 Contoso와 트러스트 계약을 설정합니다. 이 단계의 목표는 Fabrikam의 권한 부여를 나타내고 Contoso에 허용되는 보안 토큰 유형 및 콘텐츠에 동의하는 것입니다. 예를 들어 주체 이름이 "CN=Fabrikam Inc Supplier STS"인 신뢰할 수 있는 X.509 인증서가 Contoso Web Service에서 수락할 해당 SAML에 대한 SAML 토큰에 서명해야 한다고 결정할 수 있습니다. 또한 발급된 SAML 토큰의 보안 클레임은 'https://schemas.contoso.com/claims/lookup'(부분 조회 권한 부여의 경우) 또는 'https://schemas.contoso.com/claims/order'(부분 순서 권한 부여의 경우)이어야 한다고 결정할 수 있습니다.
• Fabrikam 직원이 내부 부품 주문 애플리케이션을 사용하는 경우 먼저 Fabrikam 내의 STS(보안 토큰 서비스)에 연결합니다. 해당 직원은 내부 Fabrikam 보안 메커니즘(예: Windows 도메인 사용자 이름/암호)을 사용하여 인증되고, 부품 주문에 대한 권한 부여가 확인되며, 적절한 클레임을 포함하고 위에서 결정한 X.509 인증서로 서명된 단기 SAML 토큰을 발급합니다. 그런 다음, 애플리케이션을 주문하는 파트는 발급된 SAML 토큰을 표시하는 Contoso 서비스에 연결하여 주문 작업을 인증하고 수행합니다.

여기서 Fabrikam STS는 '발급 당사자' 역할을 하고 Contoso 부품 서비스는 '신뢰 당사자' 역할을 합니다.

페더레이션 기능

다음은 페더레이션 시나리오와 관련된 당사자 또는 역할에 대해 지원되는 보안 기능입니다.

• 클라이언트 쪽: STS에서 보안 토큰을 가져오기 위해 WsRequestSecurityToken 함수를 사용할 수 있습니다. 또는 CardSpace 또는 LiveID와 같은 클라이언트 쪽 보안 토큰 공급자 라이브러리를 사용한 다음 출력을 사용하여 WsCreateXmlSecurityToken을 사용하여 보안 토큰을 로컬로 만들 수 있습니다. 어느 쪽이든 클라이언트에 보안 토큰이 있으면 채널을 보호하기 위한 WS_SSL_TRANSPORT_SECURITY_BINDING 같은 전송 보안 바인딩과 함께 토큰을 표시하는 WS_XML_TOKEN_MESSAGE_SECURITY_BINDING 지정하는 서비스에 대한 채널을 만들 수 있습니다.
• 서버 쪽: SAML 토큰을 발급하는 보안 토큰 서비스를 사용하는 페더레이션 시나리오에서 서버는 WS_SSL_TRANSPORT_SECURITY_BINDING 같은 전송 보안 바인딩과 함께 WS_SAML_MESSAGE_SECURITY_BINDING 사용하여 채널을 보호할 수 있습니다.
• STS 쪽: STS는 웹 서비스 애플리케이션이며 다른 보안 웹 서비스와 마찬가지로 수신기 생성 시 보안 설명 구조를 사용하여 보안 토큰을 요청하는 사용자에 대한 보안 요구 사항을 지정할 수 있습니다. 그런 다음 들어오는 요청 메시지 페이로드를 구문 분석하여 토큰 요청의 유효성을 검사하고 발급된 토큰을 회신 메시지 페이로드로 다시 보낼 수 있습니다. 현재 이러한 구문 분석 및 발급 단계에 도움이 되는 기능은 제공되지 않습니다.

클라이언트 쪽에서는 토큰 형식을 모르거나 토큰 형식 특정 처리를 수행하지 않고 발급된 보안 토큰을 일반적으로 XML 보안 토큰으로 처리할 수 있습니다. 그러나 서버는 이를 이해하고 처리하기 위해 특정 보안 토큰 유형을 이해해야 합니다. 보안 토큰 요청 및 응답 단계는 WS-Trust 사양에 정의된 구문을 사용합니다.

더 복잡한 페더레이션 시나리오

페더레이션 시나리오에는 페더레이션 체인을 형성하는 여러 STS가 포함될 수 있습니다. 다음 예제를 살펴보겠습니다.

• 클라이언트는 LiveID 사용자 이름/암호를 사용하여 LiveID STS에 인증하고 보안 토큰 T1을 가져옵니다.
• 클라이언트는 T1을 사용하여 STS1에 인증하고 보안 토큰 T2를 가져옵니다.
• 클라이언트는 T2를 사용하여 STS2에 인증하고 보안 토큰 T3을 가져옵니다.
• 클라이언트는 T3을 사용하여 대상 서비스 S에 인증합니다.

여기서 LiveID STS, STS1, STS2 및 S는 페더레이션 체인을 형성합니다. 페더레이션 체인의 STS는 전체 애플리케이션 시나리오에 대해 다양한 역할을 수행할 수 있습니다. 이러한 STS 기능 역할의 예로는 ID 공급자, 권한 부여 의사 결정자, 익명화기 및 리소스 관리자가 있습니다.

STS 요청 매개 변수 및 메타데이터 교환

클라이언트가 WsRequestSecurityToken 을 성공적으로 호출하려면 해당 호출의 매개 변수(예: 필요한 토큰 유형 및 클레임 형식), STS에 대한 요청 채널의 보안 설명 요구 사항 및 STS의 엔드포인트 주소를 알고 있어야 합니다. 클라이언트 애플리케이션은 다음 기술을 사용하여 이 정보를 확인할 수 있습니다.

• 디자인 타임 결정의 일부로 애플리케이션의 정보를 하드 코딩합니다.
• 로컬 애플리케이션 배포자가 설정한 애플리케이션 수준 구성 파일에서 이 정보를 읽습니다.
• WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT 구조와 함께 메타데이터 가져오기 기능을 사용하여 런타임에 이 정보를 동적으로 검색합니다.

페더레이션과 함께 동적 MEX를 사용하는 방법을 설명하려면 위의 3개의 STS 예제를 고려하세요. 클라이언트는 먼저 S를 사용하여 동적 MEX를 수행하여 T3(즉, STS2에서 요청할 내용)과 STS2 동적 MEX 주소(즉, STS2를 찾을 수 있는 위치)에 대한 정보를 가져옵니다. 그런 다음 이 정보를 사용하여 STS2를 사용하여 동적 MEX를 수행하여 T2 및 STS1에 대한 정보를 검색하는 등의 작업을 수행합니다.

따라서 동적 MEX 단계는 페더레이션 체인을 구축하기 위해 4, 3, 2, 1 순서로 수행되며 토큰 요청 및 프레젠테이션 단계는 페더레이션 체인을 해제하기 위해 1, 2, 3, 4 순서로 수행됩니다.

참고

Windows 7 및 Windows Server 2008 R2: WWSAPI는 LWSSP(경량 웹 서비스 보안 프로필)에 정의된 Ws-Trust 및 Ws-SecureConversation만 지원합니다. Microsoft의 구현에 대한 자세한 내용은 LWSSP의 MESSAGE 구문 섹션을 참조하세요.