Как мне изменить файл моего WCF FederationMetadata.xml файл для различных развертываний?

#wcf #web-services #adfs2.0 #federated-identity

#wcf #веб-службы #adfs2.0 #федеративная идентификация

Вопрос:

У нас установлена ADFS 2.0, которая хорошо работает для наших приложений MVC в различных средах. Я полагаю, что он использует «пассивную аутентификацию» (я все еще привыкаю к правильной терминологии) — это определенно то, где он перенаправляет пользователя на наш прокси-сервер adfs, если пользователь не вошел в систему, и adfs перенаправляет пользователя обратно в наше приложение MVC после входа в систему.

Сейчас мы начинаем предоставлять некоторые защищенные веб-службы и хотим подключиться к этой же системе аутентификации. Я понимаю, что я хочу использовать ws2007FederationHttpBinding в качестве привязки для этого. Я полагаю, что для этого у меня есть web.config моего WCF, но теперь моя борьба сосредоточена вокруг FederationMetadata.xml файла.

Просматривая этот файл, я вижу некоторые вещи, которые, очевидно, необходимо изменить, такие как entityID="http://localhost/UserServices" и сертификат. Тогда есть некоторые вещи, о которых я понятия не имею, что это такое, и нужно ли их менять или нет, например, EntityDescriptor ID="_2b510fe8-98b8...... и <ds:SignatureValue>CZe5mEu19/bDNoZrY8f6C559CJ....... .

Где я могу получить лучшее представление о том, как я должен управлять этим файлом для своих различных сред? У меня есть следующие среды, в которых размещены эти службы, которые мы будем развертывать тем или иным способом:

  1. Отдельные рабочие станции разработчика (3 раза на данный момент, подробнее позже)
  2. Общая среда разработки для людей, пишущих приложения для этих служб, но не обязательно модифицирующих службы
  3. QA
  4. Промежуточный
  5. Производство (3 разные среды с разными сертификатами / доменами / и т. Д.)

Таким образом, у нас есть довольно упрощенный процесс управления нашими файлами web.config в разных средах с использованием преобразований и поиска / замены определенных токенов, поэтому я хотел бы сделать то же самое с этим XML-файлом. Итак, в конечном счете, все, что я ищу, — это некоторое понимание того, какие изменения необходимы при управлении этим FederationMetadata.xml файлом для моих различных сред.

Мой текущий FederationMetadata.base.xml файл ниже, и я СЧИТАЮ, что это правильно (мне просто нужны имена / роли), и мне просто нужно разумно заменить различные токены, например ~RootServiceUrlTokenToReplace~ , здесь:

 <?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor ID="~EntityDescriptorIdTokenToReplace~" entityID="http://~RootServiceUrlTokenToReplace~" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
      <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
      <ds:Reference URI="#~ReferenceURITokenToReplace~">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
        <ds:DigestValue>~DigestValueTokenToReplace~</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>~SignatureValueTokenToReplace~</ds:SignatureValue>
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>~CertificateTokenToReplace~</X509Certificate>
      </X509Data>
    </KeyInfo>
  </ds:Signature>
  <RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration="http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
    <KeyDescriptor use="encryption">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>~CertificateTokenToReplace~</X509Certificate>
        </X509Data>
      </KeyInfo>
    </KeyDescriptor>
    <fed:ClaimTypesRequested>
      <auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
      <auth:ClaimType Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
    </fed:ClaimTypesRequested>
    <fed:TargetScopes>
      <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
        <Address>http://~RootServiceUrlTokenToReplace~</Address>
      </EndpointReference>
    </fed:TargetScopes>
    <fed:ApplicationServiceEndpoint>
      <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
        <Address>http://~RootServiceUrlTokenToReplace~</Address>
      </EndpointReference>
    </fed:ApplicationServiceEndpoint>
  </RoleDescriptor>
</EntityDescriptor>
  

Ответ №1:

Приложение на основе WIF FederationMetadata.xml не связано с веб-службами на основе утверждений, которые оно предлагает.

(URL, указывающий на) FederationMetadata.xml используется AD FS для автоматического обновления информации, которая будет использоваться в доверии проверяющей стороны. AD FS может, например, регулярно запрашивать этот URL-адрес и соответствующим образом обновлять информацию о доверии проверяющей стороны.

Информация о веб-службе (на основе утверждений или иным образом), то есть ее метаданные, публикуются в виде документа WSDL. В службе на основе WCF это URL-адрес, который часто выглядит следующим образом: http://myhost.example.com/appName/serviceName.svc?wsdl . Этот документ WSDL часто не существует как физический файл, но автоматически создается WCF.

Комментарии:

1. Да, я знаю, что это не имеет ничего общего с WSDL. Однако это во многом связано со средой. Первоначально отображаемый FederationMetadata.xml в нем несколько раз было указано » localhost «, что явно неправильно и должно изменяться для каждого отдельного места развертывания. Я не знаю, на что изменить некоторые из них, например, идентификатор EntityDescriptor или значение SignatureValue. ЭТО то, что мне нужна помощь в понимании.

2. Похоже, вы хотите защитить веб-службы WCF с помощью WIF и AD FS. Я просто хочу сказать, что вам это не нужно FederationMetadata.xml : этот файл не используется ни в какой связи с веб-службой. Вы также можете удалить этот файл из своего приложения, и все по-прежнему будет работать.

3. Это означает, что мне придется вручную настраивать все с помощью ADFS 2.0 вместо того, чтобы настраивать XML, правильно? И он все равно будет нормально работать как RP? Если да, то это действительно только проецирует ту же проблему в другом месте. Итак, теперь, я думаю, мне нужно знать, как именно настроить RP вручную в инструменте управления ADFS.

4. Правильно. И у вас уже есть RPT в AD FS 2.0 для пользовательского интерфейса вашего веб-приложения, верно? Теперь конфигурация в AD FS 2.0 не изменится, если вы начнете использовать WCF, если часть пользовательского интерфейса вашего приложения уже работает. В web.config просто укажите привязку WCF (service? не помню сразу) на тот же экземпляр AD FS 2.0 с тем же идентификатором проверяющей стороны, и тогда и ваш веб-сервис, и пользовательский интерфейс вашего веб-приложения будут использовать один и тот же RPT.

5. Но с ASP.NET , это пассивная федерация, тогда как с WCF это активная федерация. Не нужно ли мне настроить RP по-другому? Или я что-то недопонимаю…

Ответ №2:

Я нашел частичный ответ на свой вопрос в этом сообщении в блоге. Я изучаю это подробнее, чтобы выяснить, отвечает ли это на все мои вопросы. Я только что нашел это. По-видимому, мне нужно изменить свой EntityId (который содержит URL-адрес) при повторном развертывании в разных средах, но SignatureValue содержит хэш этого URL-адреса (среди прочего?) таким образом, изменяя URL-адрес, я аннулирую значение SignatureValue, и его необходимо восстановить. По-видимому, этот генератор FederationMetadata может помочь мне в этом.