허용 된 대상을 구체적으로 나열하고 해당 대상 중 하나에서 토큰이 왔는지 확인하고 X509 인증서의 손도장 및 발급자를 확인하는 사용자 지정 보안 토큰 서비스가있는 경우 WSFederation이 필요합니까?사용자 지정 STS가있는 경우 연합 인증이 필요합니까? 그렇다면 왜?
내 STS는 토큰이 이미 특정 응용 프로그램에서 왔고 내 ACS를 통해 라우팅되었음을 확인하기 때문에 필요한 모든 것을 확인하지 않습니까? 응용 프로그램 A가 사용자 지정 STS에서 응용 프로그램 B에 대한 요청을 보낸 ACS에 요청을 보냈으므로이 그림에 Federated Identity가 어디에 적합합니까? 선명도
편집 : 나는 시킴으로 빨리 게시물에 약간 불분명
죄송합니다. 보안 토큰 처리기 대신 STS를 사용했기 때문에 혼란이 왔다고 생각합니다 (다른 방식, 오타가 있습니다). 응용 프로그램 A는 사용자, google/facebook/yahoo/등의 로그인 옵션을 표시하는 사용자 정의 로그인 서비스입니다. 이 서비스를 통해 로그인하면 ACS에서 토큰을 가져 와서 응용 프로그램 B 인 신뢰 당사자에게 반환합니다. 이 RP에는 토큰을 받아들이고 응용 프로그램 A와 일치하는 대상 URI가 있는지 확인하는 사용자 지정 보안 토큰 처리기가 있습니다. 또한 발급자가 ACS 였고 지문이 토큰에 서명하는 데 사용 된 cert 중 하나와 일치하는지 확인합니다 ACS.
이것은 이론적으로 응용 프로그램 B가 응용 프로그램 A가 로그인에 사용되었고 (해당 audienceURI에서 온 것처럼) ACS가 토큰을 보냈 음을 의미합니다 (발급자와 손도장 일치와 같이). 내가 바라는 것은 응용 프로그램 B에 연합 ID가 필요한지 여부입니다. 토큰이 어디에서 왔는지 이미 증명했다면 정확히 무엇을 사용합니까?
네 번째 요점에 따라 Bertocci의 예를 사용했습니다. blogs.msdn.com/b/vbertocci/archive/2008/11/26/an-identity-provider-and-its-sts-writing-a -custom-sts-the-october-beta-of-the-geneva-framework.aspx 당신이 할 필요가있는 것처럼 보이게하는 것은 지문과 발급자를 확인하는 것입니다. –
아. 이 기사는 약간 날짜가 맞았으며, Vittorio 자신이이 게시물에서 말했듯이, 예제는 데모 목적만을위한 것이며 생산 준비가되어 있지 않다는 점에 유의해야합니다. 사용자 지정 보안 토큰 처리기가 필요하지 않으므로 큰 문제는 아니지만 WIF는 현재 X509 인증서 서명 확인을 수행 할 보안 토큰 처리기를 제공합니다. –
"WIF는 오늘 X509 인증서 서명 확인을 수행 할 수있는 보안 토큰 처리기를 제공합니다." 그럴 수도 있지만 사이트마다 web.config의 구성을 원하지 않았습니다. 따라서 잠재 고객 URI 태그를 제거하려면 기본 보안 토큰 처리기를 무시해야했습니다. 나는 당신의 충고를 받아 들여 다른 곳에서 적절한 검증을 찾았고이를 내 코드에 추가했습니다. 나는 여전히 연방 정체성이 필요한지에 대한 조언을 사용할 수 있습니다. –