제네바 프레임 워크의 RP-STS에 대한 간단한 청구 변환
-
03-07-2019 - |
문제
MSDN 기사를 읽은 후 (http://msdn.microsoft.com/en-us/magazine/2009.01.genevests.aspx) Microsoft Geneva 프레임 워크를 사용하여 커스텀 ST를 구현할 때 나는 여기에 다루는 시나리오 중 하나에 대해 약간 당황합니다. 이 시나리오는 위 참조 기사의 그림 13에 나와 있습니다.
내 질문은 IP-STS에서 이미 얻은 청구를 전달하기 위해 RP가 어떻게 RP-STS에 대한 호출을 시작합니까? 원하는 메소드 deleteorder ()는 어떻게 호출을 승인하는 값 삭제로 조치 클레임으로 응답하는 RP-STS의 조치 청구에 대한 클레임 요청으로 변하는가? 또한 RP-STS와 정책 엔진 사이의 상호 작용이 다른 방식으로 클레임과 화살표가 있어야한다는 점에서 그림이 약간 부정확하다고 생각합니다.
구조를 볼 수 있지만 Geneva/WCF가 제공하는 내용과 RP 내부의 코드에서 수행해야 할 사항은 명확하지 않습니다. 삭제에 대한 주요 제공 수요로 결실 방법을 보호 할 수 없기 때문에 약간 이상해 보일 것입니다. " 허가 "그러나 먼저 역할을 요구 한 다음 그 시점 이후 삭제 조치에 대한 세밀한 청구를 얻어야합니다.
요점을 놓친 경우 (웹 에서이 케이스가 쉽게 다루어 질 수 없기 때문에) 사과드립니다!
미리 감사드립니다.
해결책
제네바 포럼에서 같은 질문을했습니다.http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required그리고이 답장을 받았습니다.
안녕 Dokie,
나는 그 기사를 읽을 때 이와 똑같은 것을 궁금해했다. 그러한 시나리오가 어떻게 구현 될지 숙고하면서 두 가지 아이디어가 나왔습니다.
RP는 실제로 RP-STS의 청구를 요구하도록 구성됩니다. RP-STS에는 IP-STS의 보안 토큰이 필요합니다. 결과적으로, 주제가 RP의 자원을 요청하면 그를 IP-STS로 튕기는 RP-STS와 튀어 나옵니다. 그곳에서 인증 한 후, 그는 RP-STS로 되돌아 가면, 신원 중심의 주장은 승인 결정을 내리고 RP로 반환하는 데 필요한 청구로 전환됩니다.
RP는 전화를 잡고 신원 중심의 주장을보고, RST (WStrustClient를 사용하여)를 생성하고 해당 서비스를 전달하는 인터셉터 (예 : WCF 서비스 인 경우 권한 정책)가있는 것으로 구성됩니다. RP로 반환 된 새로운 클레임으로 클레임을 확장하고 RP는 승인 결정을 내립니다.
나는 이것을 구현 한 적이 없지만, 내가 가고 있다면, 나는 그 두 가지 아이디어를 더 탐구 할 것입니다.
HTH!
문안 인사,
트래비스 스펜서
그래서 나는 옵션 2를 먼저 시도하고 그것이 작동하는지 확인한 다음 여기서 답을 공식화 할 것입니다.
다른 팁
상황이 잘 작동합니다. 필자의 경우 AD FS는 ID 서비스 및 사용자 정의 자원입니다.
모든 WebApp은 동일한 리소스 ST를 사용하지만 사용자가 다른 응용 프로그램을 방문한 후에는 사용자가 이미 인증 된 이후에 ID FS에 의해 신분 위반 된 청구가 다시 AdDad가 아닙니다. AD FS의 기본 청구를 다시 강제하거나 요청하려면 어떻게해야합니까?
Actas와 함께 AD FS에 전화를 걸었습니다. 이제 내 식별 청구를 반환합니다. AD FS를 호출하는 데 사용되는 자격 증명에 대한 대표단 허용 규칙을 활성화해야합니다.
string stsEndpoint = "https://<ADFS>/adfs/services/trust/2005/usernamemixed";
var trustChannelFactory = new WSTrustChannelFactory(new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential), stsEndpoint);
trustChannelFactory.Credentials.UserName.UserName = @"DELEGATE";
trustChannelFactory.Credentials.UserName.Password = @"PASSWORD";
trustChannelFactory.TrustVersion = TrustVersion.WSTrustFeb2005;
//// Prepare the RST.
//var trustChannelFactory = new WSTrustChannelFactory(tokenParameters.IssuerBinding, tokenParameters.IssuerAddress);
var trustChannel = (WSTrustChannel)trustChannelFactory.CreateChannel();
var rst = new RequestSecurityToken(RequestTypes.Issue);
rst.AppliesTo = new EndpointAddress(@"https:<RPADDRESS>");
// If you're doing delegation, set the ActAs value.
var principal = Thread.CurrentPrincipal as IClaimsPrincipal;
var bootstrapToken = principal.Identities[0].BootstrapToken;
// The bootstraptoken is the token received from the AD FS after succesfull authentication, this can be reused to call the AD FS the the users credentials
if (bootstrapToken == null)
{
throw new Exception("Bootstraptoken is empty, make sure SaveBootstrapTokens = true at the RP");
}
rst.ActAs = new SecurityTokenElement(bootstrapToken);
// Beware, this mode make's sure that there is no certficiate needed for the RP -> AD FS communication
rst.KeyType = KeyTypes.Bearer;
// Disable the need for AD FS to crypt the data to R-STS
Scope.SymmetricKeyEncryptionRequired = false;
// Here's where you can look up claims requirements dynamically.
rst.Claims.Add(new RequestClaim(ClaimTypes.Name));
rst.Claims.Add(new RequestClaim(ClaimTypes.PrimarySid));
// Get the token and attach it to the channel before making a request.
RequestSecurityTokenResponse rstr = null;
var issuedToken = trustChannel.Issue(rst, out rstr);
var claims = GetClaimsFromToken((GenericXmlSecurityToken)issuedToken);
private static ClaimCollection GetClaimsFromToken(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(new StringReader(genericToken.TokenXml.OuterXml)));
return handlers.ValidateToken(token).First().Claims;
}