Конфигурация Azure ACS для локальной и рабочей среды

Как лучше всего настроить Azure ACS, чтобы при локальном запуске в структуре разработки я все еще мог проходить аутентификацию?

Я просто хочу настроить один раз и иметь возможность разрабатывать локально и публиковать в Azure без внесения изменений в конфигурацию. Я даже был бы открыт для того, чтобы не использовать Federated Auth при локальной разработке, если бы я мог каким-то образом подделать требование.


azure acs wif azure-acs
person Zoltan    schedule 01.04.2013    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Вы можете иметь Web.Config и Web.Release.Config (файл преобразования для каждой конфигурации сборки). Web.Config предназначен для вашей локальной разработки, где у вас есть области, URL-адреса аудитории, указывающие на ваш локальный адрес, то есть 127.0.0.1. Затем вы можете написать файл преобразования для Web.Config, например. Web.Release.Config где вы должны написать преобразование, чтобы заменить вышеуказанное значение фактическими URL-адресами развертывания. Я предполагаю, что вы будете использовать сборку выпуска для развертывания в Azure.

Вот как будет выглядеть ваш web.config.release...

<microsoft.identityModel>
    <service>
      <audienceUris>
        <add value="https://abc.cloudapp.net/" xdt:Transform="Replace" />
      </audienceUris>
      <serviceCertificate xdt:Transform="Insert">
        <certificateReference x509FindType="FindByThumbprint" findValue="AAAAAAAAAAAAAAAAAAAAAAAAAAA" storeLocation="LocalMachine" storeName="My" />
      </serviceCertificate>
      <federatedAuthentication>
        <wsFederation passiveRedirectEnabled="true" issuer="https://myacs.accesscontrol.windows.net/v2/wsfederation" realm="https://abc.cloudapp.net/" requireHttps="true" xdt:Transform="Replace" />
        <cookieHandler requireSsl="true" xdt:Transform="Replace" />
      </federatedAuthentication>
    </service>   </microsoft.identityModel>
person bhavesh lad    schedule 01.04.2013
comment
Спасибо за ответ. Я пробовал это решение, но мне было интересно, есть ли другие способы обойти это. Я должен был упомянуть об этом в посте. - person Zoltan; 01.04.2013
comment
Это способ. И это не обходной путь. Так вы решаете дилемму местного производства. - person astaykov; 01.04.2013
comment
@astaykov Как насчет использования местного STS? Я пытался искать вокруг, но не нашел много информации об этом. - person Zoltan; 01.04.2013
comment
Я бы не стал использовать местную STS. Слишком много хлопот с настройкой и управлением... в то время как вы можете (в настоящее время) иметь столько пространств имен ACS, сколько пожелаете, и все в ACS бесплатно. Кроме того, даже с локальной службой STS вам все равно нужно иметь эти преобразования web.config. Вы ничего не получите, используя локальную STS, если только вы обычно не работаете в автономном режиме. Это была бы единственная причина, по которой я бы пошел на местный STS. - person astaykov; 02.04.2013

arrow_upward
2
arrow_downward

Самый простой способ - использовать преобразования конфигурации, как сказал Бхавеш, хотя опубликованный им web.config устарел с NET 4.5.

У вас может быть локальная конфигурация разработки в web.config, облачная конфигурация разработки в web.Debug.config и производственная конфигурация в web.Release.config.

Вот пример web.Debug.config (только соответствующие части):

<system.identityModel>
  <identityConfiguration>
    <audienceUris>
      <add xdt:Transform="RemoveAll" />
      <add value="http://myinstance.cloudapp.net/" xdt:Transform="Insert" />
    </audienceUris>
  </identityConfiguration>
</system.identityModel>

<system.identityModel.services>
  <federationConfiguration >
    <cookieHandler requireSsl="false" />
    <wsFederation passiveRedirectEnabled="true" issuer="https://mynamespace.accesscontrol.windows.net/v2/wsfederation" realm="http://myinstance.cloudapp.net/" reply="http://myinstance.cloudapp.net/" requireHttps="false" xdt:Transform="Replace"/>
  </federationConfiguration>
</system.identityModel.services>

Теперь осталось только настроить проверяющую сторону для каждой конфигурации на портале ACS.

На самом деле вы можете настроить один RP для всех трех конфигураций, но единственный способ добиться этого — программно использовать API управления службами, поскольку портал позволяет настроить только одно значение Realm/Return URL для каждой проверяющей стороны.

Обратите внимание, что если вы решите сделать это, вам нужно будет установить обратный URL-адрес в файле web.config (replyattribute), иначе ACS всегда будет перезаписывать его первым настроенным обратным URL-адресом (тот, который вы видите на портале).

person Shahin Dohan    schedule 01.04.2013