Простое преобразование утверждений для RP-STS в рамках Женевы - PullRequest
Новая
       19

Простое преобразование утверждений для RP-STS в рамках Женевы

3 голосов
/ 01 мая 2009

После прочтения статьи MSDN (http://msdn.microsoft.com/en-us/magazine/2009.01.genevests.aspx) о реализации Custom STS с использованием Microsoft Geneva Framework я немного озадачен одним из рассмотренных здесь сценариев. Этот сценарий показан на рисунке 13 вышеупомянутой статьи .

Мои вопросы касаются того, как RP инициирует вызов RP-STS, чтобы передать уже полученные претензии от IP-STS? Каким образом требуемый метод DeleteOrder () превращается в запрос заявки на утверждение действия от RP-STS, который отвечает утверждением действия значением Delete, которое разрешает вызов? Я также думаю, что эта цифра немного неверна в том смысле, что взаимодействие между RP-STS и механизмом политик должно иметь утверждения и стрелки наоборот.

Я могу видеть структуру, но неясно, что предоставлено Geneva / WCF и что нужно делать в коде внутри RP, что может показаться немного странным, поскольку мы не можем защитить метод DeleteOrder с требованием PrincipalPermission для «разрешение» на удаление, но сначала нужно будет запросить роль, а затем получить детальное требование действия удаления после этой точки.

Если я упустил момент (так как я не могу найти этот случай легко освещаемым в Интернете), тогда извинения!

Заранее спасибо.

Ответы [ 2 ]

1 голос
/ 09 мая 2009

Я задавал тот же вопрос на Женевском форуме в http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required и получил этот ответ:

Привет, Доки,

Я удивился тому же, когда прочитал эту статью. Размышляя о том, как будет реализован такой сценарий, я пришел с двумя идеями:

  1. RP на самом деле настроен на требование утверждений от RP-STS; RP-STS требует токен безопасности от IP-STS. В результате, когда субъект запрашивает ресурс у RP, он привязывает его к RP-STS, который привязывает его к IP-STS. После аутентификации он возвращается в RP-STS, претензии, ориентированные на идентификацию, преобразуются в те, которые необходимы для принятия решения об авторизации, и возвращаются в RP.

  2. RP настроен так, чтобы иметь перехватчик (например, AuthorizationPolicy, если это служба WCF), который захватывает вызов, видит заявки, ориентированные на идентичность, создает RST (используя WSTrustClient), передает его RP-STS, этот сервис расширяет заявки на новые, которые возвращаются в RP, и RP принимает решение об авторизации.

Я никогда не реализовывал это, но если бы я собирался, я бы изучил эти две идеи дальше.

НТН!

С уважением,

Трэвис Спенсер

Итак, я сначала попробую вариант 2 и посмотрю, сработает ли это, а затем сформулирую ответ здесь.

0 голосов
/ 11 мая 2011

У меня одна ситуация работает нормально. В моем случае AD FS - это служба идентификации, а пользовательская STS - ресурсная STS.

Все веб-приложения используют один и тот же Resource STS, но после того, как пользователь посещает другое приложение, выданные удостоверения утверждения не добавляются ADFS, поскольку пользователь уже аутентифицирован. Как я могу снова вызвать или запросить базовые требования от AD FS?

Я создал вызов в AD FS с ActAs, теперь он возвращает мои идентификационные претензии. Не забудьте включить правило разрешенного делегирования для учетных данных, используемых для вызова 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;
  }
...