WS-Trust, WS-Fed 및 SAML 1.1/2.0 프로토콜의 차이점

Question

WS-Trust, WS-Fed 및 SAML 1.1/2.0 프로토콜의 차이점은 무엇입니까?

WS-Trust 및 WS-Fed 프로토콜에서 SAML이 보안 토큰으로 사용될 때 이러한 프로토콜에 대한 이해가 혼란스러워집니다.

이러한 프로토콜이 어떤 시나리오에서 사용되고 어떤 것이 다른지 알면 관심이 있습니다. 상용 제품/기술 참조가 사용되지 않으면 답변을 쉽게 이해할 수 있습니다.

Answer 1

높은 수준에서 WS- * 프로토콜은 전통적으로 Microsoft에서 사용되었습니다.

SAML-P (프로토콜의 경우 P)는 오픈 소스 이동에 사용되었으므로 Java가 사용되었습니다.

WS-Fed에는 활성 프로필과 수동 속성의 두 가지 프로필이 있습니다. 활성은 WCF (WS-Trust), 수동은 브라우저 기반 (로그인 페이지를 통한 WS-Fed)입니다.

두 가지 모두 SAML 토큰을 사용합니다.

기능적으로 WS-Fed와 SAML 모두 동일한 작업을 수행합니다. federation

두 개의 ADFS (Microsoft IDP)를 함께 연합하는 경우 WS-Fed를 사용합니다. Sharepoint에 추가하면 WS-Fed도 사용됩니다. 전달 된 토큰은 SAML 토큰 형식입니다.

스프링을 사용하는 Java 응용 프로그램을 사용하는 경우 SAML-P를 통해 ADFS에 연결됩니다. 전달 된 토큰은 SAML 토큰 형식입니다.

Answer 2

이 질문은 오래된 질문이지만 온라인 답변을 찾는 데 어려움을 겪었습니다.

많은 온라인 게시물은 '수동/브라우저'클라이언트가 WS-Fed를 사용하고 '액티브/스마트'는 WS-Trust를 사용한다고 말합니다. 이는 활성 유스 케이스가 기본적으로 '/ ws-trust/2005'또는 '/ws-trust/v1.x/'와 같은 URL을 사용하기 때문일 수 있습니다. 이것은 100 % 정확하지는 않습니다. 위대한 무료 책 : 클레임 기반 ID (Request-Identity) 제 2 판은이 문제를 해결하는 데 도움이되었으며 만족스러운 답변을 찾았습니다.

많은 아키텍처의 목표는 브라우저 나 스마트 클라이언트 중 하나를 사용하여 페더레이션을 활성화하는 것입니다. 스마트 클라이언트와의 연합은 WS-Trust 및 WS-Federation Active Requestor Profile을 기반으로합니다.

이러한 프로토콜은 스마트 클라이언트 (예 : Windows 기반 응용 프로그램)와 서비스 (예 : WCF 서비스) 간의 통신 흐름을 설명하여 발급자에게 토큰을 요청한 다음 해당 토큰을 인증을 위해 서비스에 전달합니다.

브라우저와의 페더레이션은 브라우저와 웹 응용 프로그램 간의 동일한 통신 흐름을 설명하는 WS-Federation 수동 요청자 프로필을 기반으로합니다. 브라우저 리디렉션, HTTP GET 및 POST를 사용하여 토큰을 요청하고 전달합니다.

SAMLP는 리디렉션 URL 등의 사물이 어떻게 전달되는지에 대한 다른 프로토콜이지만 차이점은 관련이 없으며 (대부분의 경우) 클라이언트가 지원하는 대상에 따라 달라집니다 (예 : Java에서 사용할 것임). SAML). 가장 큰 차이점은 내 의견으로는 SAMLP는 신원 제공 업체가 신원 제공 업체 (예 : 내 ADS 서버의 웹 프록시, 청구 요청 제공 업체)에서 시작하는 신원 제공 업체가 시작한 사용 사례 (내 의견으로는 가장 안전한 것)를 허용합니다. MS 용어) 대신 웹 서비스에서 시작한 다음 서비스 제공자 (= Relaying Party)로 리디렉션됩니다. 또한 SAML에 대해 이야기 할 때 우리는 일반적으로 SAML 2.0을 의미하지만 WS-Fed는 SAML 1.x 토큰을 사용합니다 (그리고 MS는 토큰이라고 부릅니다. SAML은 Assertion이라고 부릅니다 ...그저 서명되고 아마도 암호화 된 XML 일 것입니다, 이론적으로 여러분은 WS-Fed와 SAML에서 다른 토큰을 사용할 수 있다고 생각합니다. 그러나 실제로 그렇게하는 사람은 들어 본 적이 없습니다.)