Экспорт (0) Печать
Развернуть все

Добавление единого входа в веб-приложение с помощью Azure AD

Обновлено: Май 2014 г.

noteПримечание
Этот образец устарел. Его технологии, методы и (или) инструкции пользовательского интерфейса были заменены более новыми функциями. Чтобы увидеть обновленный образец, создающий похожее приложение, см. раздел WebApp-OpenIDConnect-DotNet.

.

В этом пошаговом руководстве будет показана реализация единого входа через Интернет в приложение ASP.NET с помощью Azure AD. Основное внимание в инструкциях будет уделяться использованию преимуществ клиента каталога, связанного с подпиской Azure, поскольку это является очевидным выбором поставщиков удостоверений для бизнес-приложений в вашей организации.

Решение единого входа через Интернет обычно предусматривает передачу веб-приложением функций проверки подлинности внешнему исполнителю, который называется поставщиком удостоверений. Если говорить конкретнее, это означает, что приложение будет настроено для перенаправления не прошедших проверку подлинности запросов поставщику удостоверений в соответствии с определенным протоколом, таким как SAML-P, WS-Federation или OpenID Connect.

Центр (или поставщик удостоверений) обрабатывает процесс проверки подлинности, и для этого обычно требуется, чтобы веб-приложение уже было зарегистрировано в результате определенного процесса подготовки. После успешной проверки подлинности браузер перенаправляется обратно в веб-приложение вместе с маркером безопасности, содержащим сведения о входящем пользователе; приложение проверяет этот маркер, обычно с помощью ПО промежуточного слоя, предназначенного для проверки удостоверений, и если проверка выполняется успешно, то подлинность пользователя считается установленной, и пользователь входит в приложение.

Это высокоуровневое описание также применимо и к Azure AD. В этом документе будет показано, как использовать Visual Studio 2012 и классы Windows Identity Foundation (WIF) в .NET Framework 4.5, чтобы настроить приложение MVC 4 для использования протокола входа через Интернет. Также будет показано, как подготовить то же самое приложение в клиенте Azure AD, и как настроить параметры входа приложения для подключения к этому клиенту. Пройдя все это руководство до конца, вы получите функционирующее веб-приложение, полностью настроенное для единого входа в рамках организации.

Цель данного руководства заключается в том, чтобы помочь понять принципы работы Azure AD: для этого придется выйти за рамки этих инструкций, чтобы сформировать упрощенное решение, которое здесь описывается. Помимо конкретных инструкций по построению работающего примера, в документе также даются вводные сведения об артефактах и концепциях, которые помогут лучше узнать Azure AD и понять, как можно использовать преимущества этих функций за рамками конкретного сценария, который здесь рассматривается. Такие дополнительные разделы, оформленные в виде выделенных заметок, не являются строго обязательными для прохождения данного пошагового руководства; однако если вы планируете использовать Azure AD в своих собственных решениях, рекомендуется прочесть также и эти части.

Обучающая часть документа разбита на следующие разделы.

  • Предварительные требования. В этом разделе перечисляются все требования, которые необходимо выполнить, прежде чем приступить к изучению.

  • Архитектура решения. В этом разделе содержатся вводные сведения верхнего уровня о решении единого входа через Интернет для бизнес-приложений. Мы рассмотрим функциональные компоненты, позволяющие осуществить единый вход, и настроим каркас, который вы далее будете детализировать с помощью последующих инструкций.

  • Работа с клиентом каталога Azure AD. В этом разделе содержатся вводные сведения о клиентах и компонентах Azure AD, с которыми вы будете работать в рамках настоящего сценария. В нем также кратко описываются основные элементы раздела Active Directory на портале управления Azure.

  • Подключение приложения к Azure AD. В этом разделе показывается порядок использования средств удостоверений и доступа в Visual Studio 2012 для включения единого входа через Интернет в приложении MVC и привязки параметров проверки подлинности к конкретному клиенту Azure AD.

  • Дополнительные разделы. Этот раздел выходит за рамки основ; в нем глубже рассматриваются некоторые ключевые темы, а также охватываются и другие задачи, которые может потребоваться выполнить для перевода приложения на следующий уровень.

Для прохождения настоящего руководства должны быть выполнены следующие предварительные требования.

Если возникли вопросы или нужна помощь, см. статью Preparing for Azure AD Solutions and Scenarios

Архитектура приложения для одного клиента

В этом пошаговом руководстве подробно рассматривается следующий сценарий. Разработчик планирует развернуть свое веб-приложение в облаке, и хочет, чтобы доступ был разрешен только пользователям из клиента Azure Active Directory. Чтобы осуществить это, ему необходимо выполнить следующие действия.

  1. Зарегистрировать это веб-приложение в своем клиенте Azure AD. После регистрация приложения Azure AD будет принимать запросы пользователей на проверку подлинности для входа в это приложение.

  2. Добавить что-то перед приложением, чтобы:

    1. не прошедшие проверку подлинности запросы могли блокироваться и перенаправляться в правильный клиент Azure AD для проверки подлинности пользователя;

    2. пользователи, прошедшие проверку подлинности в Azure AD, могли распознаваться и получать доступ.

Мы будем реализовывать первый этап на портале управления Azure. Вы узнаете, как подготовить новый клиент Azure AD в своей подписке Azure, и как использовать функции портала управления Azure AD для регистрации приложения.

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

На платформе .NET второй этап сводится к настройке классов, которые .NET предлагает готовыми к работе с удостоверениями, основанными на утверждениях, и с федеративной проверкой подлинности. В совокупности эти классы называются Windows Identity Foundation (WIF). Они включают модули HTTP и параметры конфигурации, которые можно использовать для добавления перехватывающего уровня, выполняющего задачи перенаправления и проверки подлинности из второго этапа. Visual Studio 2012 предлагает средства, помогающие автоматически настроить веб-приложения, чтобы они использовали WIF для передачи проверки подлинности внешним центрам, поддерживающим специальные протоколы единого входа, такие как WS-Federation. В этом пошаговом руководстве будет показано, как использовать такие средства с Azure AD.

Azure Active Directory — это служба, обеспечивающая главную опору удостоверений в таких предложениях Майкрософт, как Office 365 и Windows Intune. Если вы подписаны на эти службы и хотите воспользоваться клиентом каталога, связанным с такой службой, создайте новую подписку Azure и с помощью компонента Добавить пользователя добавьте администратора из этого клиента. В данном руководстве не предусмотрены подробные рекомендации по этому процессу.

Каждая подписка имеет клиент Azure AD и соответствующий каталог. Если клиент был создан автоматически, то каталог будет называться Default Directory (Каталог по умолчанию), но это имя можно изменить. В этой части руководства мы добавим пользователя в каталог, а затем добавим приложение.

После создания клиента каталога он настраивается так, чтобы хранить пользователей и учетные данные в облаке. Подробное описание процесса интеграции клиента каталога с локальным развертыванием Windows Server Active Directory см. в статье Интеграция каталога.

Если возникли вопросы или нужна помощь, см. статью Preparing for Azure AD Solutions and Scenarios

В сценариях и решениях Azure AD (а также для наших образцов кода и демонстрационных приложений) требуется учетная запись пользователя в вашем домене Azure Active Directory. Попытка входа в приложение с помощью учетной записи Майкрософт, такой как учетная запись Hotmail.com, Live.com или Outlook.com, завершится неудачно. Если пользователь с учетной записью в вашем домене Active Directory, например, с User@Contoso.onmicrosoft.com, уже существует, то эту учетную запись можно использовать для входа в данном сценарии. В противном случае необходимо создать нового пользователя.

  1. Перейдите на портал управления Microsoft Azure (https://manage.WindowsAzure.com), выполните вход и щелкните Active Directory. (Совет по устранению неполадок. "Active Directory" item is missing or not available (Элемент "Active Directory" отсутствует или недоступен))

  2. Если ваш каталог называется "Default Directory", добавьте каталог, например "ContosoEngineering". Чтобы добавить каталог, нажмите кнопку Добавить внизу страницы Active Directory и следуйте инструкциям по добавлению нового каталога.

  3. Дважды щелкните этот каталог и выберите пункт Домены. При создании пользовательских учетных записей используйте доменное имя, которое появляется на этой странице. Например, если домен ContosoEngineering@onmicrosoft.com, создайте в этом домене такие имена пользователей, как Test@ContosoEngineering@onmicrosoft.com.

  4. Чтобы создать пользовательскую учетную запись в этом домене, перейдите на вкладку Пользователи. (Если вы не видите вкладку Пользователи, дважды щелкните имя каталога. Вкладка Пользователи отображается на каждой странице, относящейся к каталогу.) Внизу страницы нажмите кнопку Добавить пользователя.

  5. Выберите пункт Новый пользователь в организации. Добавьте пользователя в своем домене, например Test@ContosoEngineering.onmicrosoft.com, а затем нажмите галочку внизу страницы.

    Введите имя пользователя и домен
  6. На странице профиля пользователя назначьте этому пользователю роль в организации. В целях тестирования рекомендуется иметь хотя бы одного пользователя с ролью глобального администратора и одного пользователя с ролью "Пользователь".

    Введите роль пользователя

На последнем этапе портал управления Azure создает временный пароль, с помощью которого пользователь выполняет первый вход. После первого входа пользователь должен изменить временный пароль. Обязательно сохраните этот временный пароль, поскольку он потребуется для тестирования сценария.

На данный момент у нас есть клиент каталога с действительным пользователем, которого можно предоставить центру проверки подлинности в нашем сценарии единого входа через Интернет.

Временный пароль

  1. Давайте начнем работу с частями приложения. Откройте Visual Studio, нажмите Создать проект и выберите пункт Веб-приложение MVC 4 ASP.NET. В окне создания проекта MVC 4 ASP.NET выберите Приложение интрасети, убедитесь, что выбран обработчик представлений Razor, и нажмите кнопку ОК. В этом руководстве в качестве имени проекта будет использоваться ExpenseReport.

    noteПримечание
    Также в этом руководстве предполагается, что установка Visual Studio настроена с использованием параметров по умолчанию. Если вы изменяли какие-либо базовые настройки (например, место размещения веб-приложений во время разработки), придется соответствующим образом изменять инструкции.



    Новый проект в среде Visual Studio

    Приводимые здесь инструкции можно применять к любому имеющемуся веб-приложению VS 2012, MVC или веб-форм, при условии, что отсутствует логика, существенно изменяющая конвейер обработки запросов ASP.NET. Однако здесь для ясности мы будем строить новый проект с нуля.

    noteПримечание
    В этом руководстве даются подробные инструкции по настройке решения .NET, однако те же самые результаты можно получить и для других платформ и программных стеков. В Azure AD используются функции единого входа через Интернет открытых протоколов, и все компоненты, библиотеки и средства основных платформ поддерживают такие протоколы. Детали действий следует скорректировать, чтобы приспособить их к синтаксису и методам каждого стека, однако деление задач на верхнем уровне будет применимо по всем направлениям.

    Visual Studio создает для вас новый проект MVC, уже настроенный для запуска в IIS Express: мы не будем добавлять в него дополнительную функциональность, так как имеющейся функциональности достаточно для демонстрации добавления единого входа через Интернет. Единственное исключение — конечная точка, используемая приложением. По умолчанию Visual Studio настраивает приложение для обслуживания контента по протоколу HTTP, однако это не подходит для установки защищенных сеансов, поскольку взаимодействия оказываются незащищенными, что позволяет потенциальным злоумышленникам похищать файлы cookie и токены. На этапе разработки это не обязательно, поскольку Azure не предписывает строгое использование HTTPS. Однако это всегда рекомендуется.

  2. С помощью IIS Express очень легко включить HTTPS непосредственно из Visual Studio. Выберите свой проект в обозревателе решений, затем в панели свойств переключите параметр SSL включен в значение True.

    Вы увидите, что URL-адрес SSL, ранее пустой, теперь заполнен новым адресом. Выделите этот адрес и скопируйте его в буфер.



    Копировать URL-адрес SSL

  3. Теперь нужно сообщить Visual Studio, что мы хотим всегда использовать конечные точки HTTPS во время отладки. Вернитесь в обозреватель решений, щелкните проект правой кнопкой мыши и выберите пункт Свойства. Выберите вкладку Интернет слева, прокрутите вниз до параметра Использовать локальный веб-сервер IIS и вставьте URL-адрес HTTPS в поле URL-адрес проекта. Сохраните настройки (нажав клавиши CTRL+S) и закройте вкладку свойств.



    Изменить URL-адрес проекта

    На данный момент у нас есть приложение, которое уже можно настраивать, чтобы оно использовало Azure AD для единого входа. На следующем шаге мы сообщим вашему клиенту Azure AD об этом приложении.

  1. Сверните Visual Studio и вернитесь на вкладку Active Directory на портале управления Azure. Ранее в этом руководстве мы работали в области пользователей; теперь будем работать в области приложений. Нажмите Приложения в верхней части страницы.



    Интегрированные приложения

    В этой области перечислены все приложения, зарегистрированные в вашем клиенте каталога. Мы говорим, что приложение зарегистрировано в клиенте, если выполнены следующие условия.

    • Приложение имеет в каталоге запись, описывающую его основные координаты: имя, связанные конечные точки и т. п. Дополнительные сведения см. ниже.

    • Самому приложению дается разрешение на выполнение некоторых операций в текущем клиенте каталога: от запроса токена входа до возможности запроса каталога. Дополнительные сведения см. ниже.

    ImportantВажно!
    Ни одно приложение не может использовать преимущества Azure AD без регистрации: это обусловлено как соображениями безопасности (разрешение получают только приложения, утвержденные администратором), так и практическими соображениями (взаимодействие с Azure AD влечет за собой использование определенных протоколов, что в свою очередь требует знания ключевых параметров, описывающих приложение).

  2. Учитывая, что мы только что создали этот клиент каталога из шаблона, список зарегистрированных приложений пока пуст. Фактически первой будет запись для приложения, только что созданного в Visual Studio: этот раздел полностью посвящен регистрации этого приложения.

    Поскольку это самое первое приложение, начните процесс, нажав кнопку Добавить в панели команд внизу экрана на портале управления Azure. Появится экран, показанный ниже.



    Расскажите о своем приложении

    Процесс регистрации одного приложения через портал управления Azure оформлен в виде классического мастера, в котором на последовательных экранах собираются необходимые сведения в соответствии с вашим выбором.

    На рисунке выше показан первый из этих экранов. Здесь предлагается заполнить простые параметры.

    • Отображаемое имя: введенный здесь текст используется как понятное специальное имя для ссылок на приложение везде, где пользователю — будь это администратор, управляющий списком зарегистрированных приложений, или клиент, решивший предоставить приложению доступ к каталогу — необходимо что-либо с ним сделать. Дополнительные сведения см. в документе Разработка мультитенантных веб-приложений с помощью Azure AD.

    • Тип доступа: этот ряд переключателей позволяет указать операции, которые разрешено выполнять приложению в клиенте каталога. Поскольку здесь наша цель состоит в том, чтобы просто настроить в приложении единый вход через Интернет, выберите вариант Единый вход.

      noteПримечание
      Тема разрешений приложения более глубоко рассматривается в других документах; однако здесь мы кратко коснемся лежащих в основе принципов, чтобы вы могли знать, что происходит за сценой.

      Azure AD представляет приложения с помощью сущности, называемой ServicePrincipal. Как можно предположить из названия, это аналог более известных участников-пользователей, но предназначенный для описания приложений.

      Акт регистрации приложения — это фактически создание ServicePrincipal для приложения в клиенте экземпляра каталога, доступ в который предполагается предоставить приложению.

      Уровень доступа, который необходимо предоставить конкретному приложению, определяется ролями, к которым принадлежит его ServicePrincipal. Хотя в данном руководстве это не требуется, но если вы выберете уровни доступа на чтение и запись, то в процесс регистрации будет добавлено несколько дополнительных шагов для сбора дополнительных сведений, например, о ключах, которые должны использоваться для проверки подлинности при выполнении таких запросов: в этом случае ключи тоже должны сохраняться в ServicePrincipal, описывающем приложение. Дополнительные сведения об этом см. в разделе Использование API Graph для запроса в Azure AD.

      Разрешения, предоставленные в процессе регистрации приложения, действуют только при доступе к самому каталогу; они не определяют политики доступа к другим ресурсам Azure, таким как базы данных SQL Azure, разделы портала управления и пр.

  3. После ввода имени приложения и выбора типа доступа Единый вход щелкните стрелку в нижнем правом углу для перехода в следующий экран.

    Свойства приложения На этом экране портал управления Azure собирает важные координаты, необходимые службе для управления потоком протокола входа. Вот что необходимо указать.

    • APP URL (URL-адрес приложения): этот параметр представляет address веб-приложения. В данном примере это https://localhost:44341/, адрес, назначенный IIS Express вашему приложению. Если вы до настоящего момента точно следовали инструкциям, то этот адрес еще находится в буфере, и его можно просто вставить. Введенное значение будет действовать на протяжении всего этапа разработки. После развертывания приложения в целевой промежуточной или рабочей среде нужно будет вернуться на портал управления и изменить этот адрес, чтобы он соответствовал новому расположению приложения. Ниже в этом руководстве мы обсудим, как это сделать.

      WarningПредупреждение
      Azure AD необходимо знать адрес приложения, чтобы после успешной проверки подлинности пользователя на страницах Azure AD можно было перенаправить поток обратно в приложение.

      Этот адрес должен быть предоставлен заблаговременно: если Azure AD будет перенаправлять потоки проверки подлинности на любой адрес, злоумышленникам будет проще перехватывать эти потоки и похищать токены. Заблаговременная регистрация URL-адреса приложения гарантирует, что токены проверки подлинности, предназначенные для вашего приложения, будут отправляться только в это приложение.

    • APP ID URI (URI ИД приложения): этот параметр представляет identifier веб-приложения. Azure AD использует это значение во время входа для определения, что запрос проверки подлинности предназначен для предоставления доступа пользователю именно в это конкретное приложение, чтобы можно было применить правильные параметры.

    noteПримечание
    URI ИД приложения должен быть уникальным в рамках клиента каталога. Подходящее значение по умолчанию для этого параметра — сам URL-адрес приложения, однако с этой стратегией не всегда просто соблюсти требование уникальности: при разработке приложений в локальных средах размещения, таких как IIS Express и Azure Fabric Emulator, обычно создается ограниченный диапазон адресов, которые будут многократно использоваться несколькими разработчиками или даже в нескольких проектах одного разработчика. Единственная возможная стратегия заключается в том, чтобы добавлять что-либо к значению URL-адреса приложения в качестве дифференцирующего фактора.

    Также следует отметить следующее. URI ИД приложения — это универсальный код ресурса, и как таковой он не должен соответствовать какой-либо сетевой адресуемой конечной точке. Это означает, что можно выбрать что-либо, не имеющее никакого отношения к URL-адресу приложения: фактически, хотя в этом руководстве мы работаем с совершенно новым приложением, иногда вы будете регистрировать приложения, которые уже имеют свой собственный URI ИД приложения (в используемом здесь протоколе входа WS-Federation URI ИД приложения называется realm), и в этом случае вы вероятно захотите использовать именно его. В разделе Разработка мультитенантных веб-приложений с помощью Azure AD будут рассматриваться некоторые дополнительные ограничения, которые вводит мультитенантность.

  4. После ввода URL-адреса приложения и URI ИД приложения можно нажать кнопку с флажком в нижнем правом углу.

    Быстрый запуск Это завершает процесс регистрации, приложение теперь имеет собственную запись в клиенте каталога, и Azure AD может обрабатывать веб-проверку подлинности от его имени.

    Экран, сообщающий об успешной регистрации, предоставляет сведения, необходимые для настройки веб-приложения, чтобы оно использовало Azure AD для входа, а именно: в разделе Включить единый вход через Azure AD содержится ряд параметров, которые нужно будет вставить в Visual Studio.

    Оставьте свой браузер открытым на этой странице и вернитесь в Visual Studio, чтобы приступить к следующей задаче из этого пошагового руководства.

Теперь, когда Azure AD может выдавать токены проверки подлинности для вашего приложения, для включения единого входа через Интернет осталось настроить само приложение, чтобы оно обрабатывало запросы с использованием правильного протокола проверки подлинности. Исполнение протокола — это то, что позволяет приложению вызывать Azure AD, и в частности ваш клиент каталога, для обеспечения проверки подлинности пользователя в начале рабочего сеанса пользователя с приложением.

При использовании протоколов входа через Интернет важно понимать основы механизмов проверки подлинности. Подробное описание см. в дополнительном разделе.

В качестве шаблона проекта мы выбрали приложение интрасети MVC 4. Этот шаблон обычно опирается на интегрированную проверку подлинности Windows для обеспечения проверки подлинности пользователя приложения. Этот механизм функционирует на сетевом уровне: он применяется ко всем службам, опубликованным в Интернете, без необходимости добавления какой-либо логики проверки подлинности в само приложение.

При развертывании приложения за пределами интрасети, как в случае облачного приложения, больше нельзя опираться на проверку подлинности на уровне сети. Наиболее распространенная стратегия работы с проверкой подлинности в таких случаях включает добавление перед приложением некоторой разновидности ПО промежуточного слоя, которое воссоздает необходимую проверку подлинности на более высоком уровне. Этот дополнительный уровень может выполнять перехват не прошедших проверку подлинности запросов, обеспечивать выполнение протоколов проверки подлинности, перенаправлять пользователей для проверки подлинности вне приложения, возвращать в приложение сведения о прошедшем проверку подлинности пользователе, управлять сеансами и в целом выполнять все задачи, необходимые для обеспечения контроля доступа.

Эта стратегия последовательно применяется в отрасли во всех вариантах платформ, стеках разработки и протоколах входа; что бы ни происходило, и как бы ни менялась модель программирования, общая модель остается в основном прежней.

В этом руководстве мы собираемся подключать приложение к Azure AD по протоколу WS-Federation: это только один из возможных вариантов для реализации единого входа через Интернет; другой распространенный вариант — SAML-P.

Платформа .NET Framework 4.5 имеет собственную поддержку WS-Federation: присутствуют все классы, необходимые для обеспечения выполнения протокола, обработки проверки подлинности и обработки сеансов в контексте приложений ASP.NET.

Если говорить кратко, то .NET 4.5 предлагает ряд модулей HTTP, предназначенных для реализации в конвейере HTTP приложения. Эти модули разрабатывались для ссылок на хорошо известные разделы конфигурации, содержащие координаты протокола как для приложения, так и для центра проверки подлинности (в данном случае вашего клиента Azure AD). По мере поступления запросов модули проверяют их и обеспечивают выполнение протокола проверки подлинности соответствующим образом. Например, при получении непроверенного запроса модули будут читать координаты клиента Azure AD из файла конфигурации, использовать их для составления сообщения для входа WS-Federation, и с его помощью автоматически перенаправлять пользователя для проверки подлинности в Azure AD.

noteПримечание
Подмножество классов в .NET Framework 4.5, выделенное для задач, связанных с удостоверениями, основанными на утверждениях, называется Windows Identity Foundation (WIF). Приложения, предназначенные для предыдущих версий платформы (3.5 и 4.0), также могут реализовывать действия, описанные в данном руководстве, используя преимущества предыдущей версии WIF выпущенной отдельно в качестве автономной библиотеки (загрузить можно здесь). Однако следует отметить, что пошаговые инструкции будут отличаться, учитывая, что эти две версии не полностью совместимы (классы существуют в разных пространствах имен), и что пришлось бы использовать инструментарий для разных версий Visual Studio (2008 и 2010, загрузить можно здесь).

Visual Studio 2012 предлагает инструменты типа "укажи и выбери", помогающие настраивать приложения, чтобы они использовали WS-Federation для единого входа через Интернет: с помощью пользовательского интерфейса этого инструмента можно предоставлять ключевые сведения о центре, которому планируется доверить проверку подлинности, и инструмент будет создавать соответствующие элементы конфигурации. В этом пошаговом руководстве придется писать очень мало кода, поскольку инструментарий будет автоматически создавать большую его часть.

  1. Теперь, когда вы знаете, как мы собираемся реализовать единый вход через Интернет, давайте настроим приложение с помощью инструмента идентификации и доступа. В обозревателе решений щелкните правой кнопкой мыши проект приложения и выберите в контекстном меню пункт Идентификация и доступ….

    Доступ и удостоверения Visual Studio отобразит диалоговое окно, показанное ниже.

    Поставщики доступа и удостоверений Вся работа будет выполняться на вкладке "Поставщики", той, которая показывается в настоящий момент. Для целей данного руководства мы будем игнорировать все параметры, которые не нужны для текущей задачи.

  2. В инструменте перечислены разные типы центров, которые можно использовать для передачи выполнения проверки подлинности. В нашем конкретном случае нам нужен поставщик бизнес-удостоверений: Щелкните соответствующую запись, вторую сверху.

    Конфигурация доступа и удостоверений После выбора этого параметра в нижней области появятся соответствующие элементы пользовательского интерфейса. Информация, запрашиваемая этими элементами управления, в точности соответствует записям, которые отображались в конце процесса регистрации приложения, рассматриваемого в предыдущем разделе. Вот что необходимо ввести, снизу вверх.

    • Введите URI ИД (область) приложения. Это идентификатор вашего приложения, заданный во время регистрации. Вернитесь в окно браузера, показывающее портал управления, скопируйте соответствующее значение в поле Обновите код с помощью URI ИД приложения и вставьте его здесь.

    • Введите путь к документу метаданных STS. Документ метаданных STS — это файл, содержащий машинно-считываемое описание центра, который планируется подключить. Инструмент будет использовать его для определения значений параметров, важных для выполнения входа (более подробное описание ниже). Каждый клиент Azure AD предоставляет один такой документ; его местоположение сообщается в конце процесса регистрации. Переключитесь на портал управления, скопируйте соответствующее значение со страницы регистрации приложения, вернитесь в инструмент и вставьте путь в данное поле.

      noteПримечание
      После вставки пути к документу метаданных в текстовое поле инструмент отобразит предупреждение о недопустимом сертификате. Это происходит потому, что документ метаданных подписан с помощью самозаверяющего сертификата, и не должно приниматься во внимание.

    Нажмите кнопку ОК. Средство будет пытаться связаться с указанным документом метаданных, считать координаты центра (адрес конечных точек, которые будут использоваться для входа; сертификат X.509, необходимый для проверки подписи токенов проверки подлинности; формат и версию выданных токенов проверки подлинности и т. д.) и использовать эти сведения для создания и добавления в файл web.config записей, необходимых для подключения приложения к Azure AD.

в следующем списке дается описание основных записей, добавляемых инструментом в файл web.config. Более подробное описание см. в дополнительном разделе этого документа.

  • Записи <section> для system.identityModel и system.identityModel.services: эти записи нужны файлу конфигурации для понимания параметров конфигурации, относящихся к идентификации.

  • Параметры <authorization> в <system.web>: инструмент автоматически изменяет параметры проверки подлинности ASP.NET, чтобы требовать проверку подлинности каждого запроса, направленного в приложение. Это обеспечивает поведение, называемое "сплошным перенаправлением", когда каждый непроверенный запрос перенаправляется в центр проверки подлинности (в отличие от поведения, когда части приложения доступны непроверенным пользователям). Такое поведение используется по умолчанию в бизнес-приложениях, где проверка подлинности часто автоматическая, с учетом того, что пользователь уже вошел с помощью центра. Если разработчик желает изменить это поведение, чтобы обеспечить требования к проверке подлинности на индивидуальной основе, он может просто соответствующим образом изменить параметры <authorization>.

  • WSFederationAuthenticationModule (FAM) и SessionAuthenticationModule (SAM) в <system.webServer/modules>: Эти записи добавляют в конвейер HTTP модули HTTP, которые обеспечивают использование WS-Federation для проверки подлинности. FAM — это модуль, отвечающий за выполнение протокола. Основные потоки, за которые он отвечает, это запросы входа, управление выходом проверки токенов. Модуль SAM обрабатывает сеансы. В частности, он создает файлы cookie сеанса, проверяет их и обеспечивает их присутствие в каждом запросе, обрабатывает длительность сеанса и т. п.. Их поведение управляется элементом конфигурации, который описывается ниже.

  • Раздел <system.identitymodel/identityConfiguration>: этот элемент определяет поведение приложения на этапе проверки подлинности. Например: в дочернем элементе ValidatingIssuerNameRegistry он сохраняет список центров, которым доверено предоставление услуг проверки подлинности, путем записи их имен и сертификатов для подписи.

  • Раздел <system.identitymodel.services/federationConfiguration>: предоставляет координаты, необходимые для управления потоками WS-Federation — адрес центра, используемого в запросах входа, идентификатор самого приложения для включения в запросы и пр.

Автоматически созданный файл конфигурации — это все, что нужно, чтобы использовать преимущества Azure AD для входа через Интернет. В самом приложении не требуется писать никакой код специально для приложения. Если требуется получить сведения из удостоверения пользователя, это можно легко сделать, запросив утверждения в текущем субъекте. Например, предположим, что нужно узнать имя и фамилию текущего пользователя. Это можно будет сделать с помощью следующего кода, не зная ничего о том, как прошла проверка подлинности:

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

Начиная с .NET 4.5, каждое удостоверение в .NET представляется с ClaimsPrincipal. В данном случае текущий ClaimsPrincipal был построен во время проверки токена проверки подлинности, созданного Azure AD и представленного пользователям во время входа.

Каждый ClaimsPrincipal содержит коллекцию утверждений, атрибутов, описывающих текущего пользователя, как заявлено центром, выполнившим его проверку подлинности. В нашем руководстве утверждения в субъекте — это те, что были выданы в токене Azure Active Directory. Полный список доступных утверждений см. в электронной документации.

Azure AD выдает фиксированный набор утверждений для пользователей, прошедших проверку подлинности. Далее приводится краткий справочник по всем утверждениям, которые можно ожидать от Azure AD; полное описание см. в документации.

 

Тип Значение в примере Описание

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

Уникальный, неизменяемый, однократного использования, целевой идентификатор проверенного пользователя для текущего приложения.

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

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

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

Идентификатор клиента каталога.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

Имя пользователя.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

Имя участника-пользователя для этого пользователя.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

Фамилия пользователя.

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

Идентификатор центра, выполнившего проверку подлинности пользователя, из протокола входа через Интернет (в данном случае WS_Federation).

Теперь ваше приложение имеет все, что нужно для демонстрации входа через Интернет с помощью Azure AD, однако оно еще не завершено. Имеется по крайней мере две другие важные функции, которые вы захотите добавить: поддержка выхода и автоматическое обновление координат протокола центра.

В следующих двух разделах будет показано, как добавить эти две функции. Рекомендуется пройти и эти разделы, прежде чем перейти к разделу "Запуск приложения".

Используемые сегодня протоколы входа через Интернет часто включают подготовку для выполнения распределенных операций выхода: это потоки, в которых текущее приложение не только прекращает текущий сеанс с пользователем, но также сигнализирует в центр, что команду выхода следует распространить на все другие сеансы приложения, установленные этим центром. WS-Federation не является исключением и предлагает поток полного выхода, полностью реализованный в объектной модели WIF. В этом разделе мы обсудим, как добавить возможности распределенного выхода в наше приложение: это сводится к включению правильных приемов во взаимодействие с пользователем, чтобы вызвать поток выхода и создать соответствующее сообщение выхода для установки в клиенте Azure AD.

  1. Начнем с добавления в приложение контроллера SignOut. Это легко сделать: найдите папку Контроллеры в проекте в обозревателе решений, щелкните ее правой кнопкой мыши и выберите пункт Добавить, а затем выберите Контроллер. Дайте ему имя SignOutController, выберите параметр Пустой контроллер MVC (обычно это параметр по умолчанию) и нажмите кнопку Добавить.

  2. Нам потребуется использовать классы из некоторых новых сборок, поэтому следует добавить на них ссылки. Снова перейдите в обозреватель решений, щелкните правой кнопкой мыши узел Ссылки, выберите команду Добавить ссылку…, введите system.identitymodel.services в поле Поиск сборок и выберите соответствующую сборку из основного списка. Нажмите кнопку ОК.

  3. Вернитесь в только что созданный файл SignOutController.cs. Добавьте в директивы using следующие записи:

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    Теперь измените реализацию класса SignOutController следующим образом:

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    Дадим краткое объяснение того, что делает этот код.

    • Первый метод Index() подает запрос формы https://localhost:44341/SignOut. Это адрес представление, которое будет добавляться через несколько шагов в этом руководстве. Его задача в том, чтобы сигнализировать об успешном выходе, и мы будем использовать его как таковой в следующем методе.

    • Метод SignOut() подает запрос формы https://localhost:44341/SignOut/SignOut и содержит основную логику выхода.

    • Первая строка извлекает объект, используемый WIF для отслеживания параметров WS-Federation в файле web.config: он нам понадобится для создания сообщения выхода специально для текущего приложения.

      noteПримечание
      Обычно рекомендуется ссылаться на значения в файле конфигурации, вместо того чтобы жестко задавать их или получать из пользовательских репозиториев, поскольку это повышает адаптивность кода и приводит его в соответствие с остальными параметрами протокола: логика продолжает работать независимо от того, сколько раз менялись параметры в файле конфигурации, до и после развертывания.

    • Вторая и третья строки создают обратный адрес, который должен использовать центр в конце выполнения выхода. Мы хотим, чтобы этот адрес указывал не представление, которое рассматривалось ранее. Следовательно, код получает URL-адрес текущего запроса и устраняет завершающую строку ‘SignOut’. Извлечение адреса из запроса гарантирует его правильное разрешение для клиента, в то время как получение адреса из уровня размещения может привести к проблемам внутренних портов при использовании подсистемы балансировки нагрузки.

    • Четвертая строка использует WIF для создания сообщения выхода по протоколу WS-Federation, передавая URL-адрес центра и обратный адрес, заданные строкой выше. Это сообщение можно было бы легко создать непосредственно в его шаблоне, однако использование объектной модели WIF поможет создавать более лаконичный код и игнорировать большую часть деталей синтаксиса. Если вы хотите увидеть, как выглядит сообщение выхода, убедитесь, что выполняется сбор данных трассировки HTTP, при запуске приложения в следующем разделе либо просмотрите спецификацию здесь.

    • Четвертая строка добавляет в сообщение идентификатор текущего приложения, зарегистрированный в атрибуте realm элемента конфигурации <wsFederation>.

    • Пятая строка использует модуль SAM (который рассматривался выше в описании автоматически создаваемой конфигурации) для очистки локального сеанса. Сюда входит удаление файла cookie сеанса. созданного во время входа, и очистка всех локальных ресурсов, которая может понадобиться.

      noteПримечание
      Это демонстрационное приложение мало что делает, но реальные приложения могут распределять ресурсы во время пользовательского сеанса. В таком случае можно воспользоваться преимуществами событий SigningOut и SignedOut модуля SAM, добавив соответствующие обработчики событий в файл Global.asax для очистки всех ресурсов, которые должны быть освобождены при закрытии сеанса.

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

  1. В обозревателе решений щелкните правой кнопкой мыши узел Представления и добавьте папку SignOut.

  2. В этой папке добавьте представление, щелкнув папку правой кнопкой мыши и последовательно выбрав в меню пункты Добавить и Представление. Дайте новому представлению имя SignOut. Поместите некоторый замещающий код в файл представления (SignOut.cshtml) для сообщения о произошедшем выходе. Например:

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. Как вы, наверное, помните из предыдущего раздела, мы настраивали приложение для обработки проверки подлинности посредством сплошных перенаправлений. Это означает, что если мы попытаемся получить доступ к этому представлению после успешного выхода, то будем немедленно перенаправлены в Azure AD для повторного входа! Чтобы не допустить такое поведение, можно использовать элемент <location> в файле web.config, чтобы создать одно исключение в политике проверки подлинности.

    Найдите первое вхождение элемента <system.web> и непосредственно над ним вставьте следующий фрагмент кода:

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    Этот фрагмент кода сообщает ASP.NET, что путь SignOut может быть доступен всем, включая пользователей, не прошедших проверку подлинности. Это дополнение позволит видеть данное представление в своем браузере даже после успешного выхода.

  1. Теперь, когда приложение имеет возможность выполнения выхода, осталось только обработать эту функцию для создания пользовательского интерфейса. Это можно сделать очень просто. Откройте файл _layout.cshtml по пути Представления\Общие в обозревателе решений. Найдите строку "Hello", чтобы найти код, выполняющий отрисовку сведений для входа вверху типичного макета MVC 4, а затем измените раздел входа следующим образом:

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

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

Средство удостоверений и доступа настроило приложение так, чтобы оно принимало токены, поступающие от выбранного клиента Azure AD. Для этого оно кэшировало в файле web.config необходимые координаты протокола для подключения к заданным конечным точкам Azure AD. Более того, это средство сохранило ключевые сведения, используемые во время проверки подлинности, для проверки, действительно ли поступающий токен исходит от клиента Azure AD: это имя издателя, представляющее клиент, и открытый ключ (в форме сертификата X.509), который должен использоваться для проверки подписи токена.

Обычная практика безопасности подразумевает регулярное обновление криптографических ключей, и ключи подписывания Azure AD не являются исключением: через определенные периоды времени старые ключи будут отменяться, а их место в логике подписывания издателя и в документе метаданных клиента будут занимать новые ключи. В экстренных случаях ключи могут быть обновлены вне цикла, с минимальным временем предупреждения или без оного.

Каждый раз, когда ключ подписывания меняется, необходимо согласованно изменять настройки приложения: в соответствии с подходом, показанным в данном руководстве, это означает повторный запуск инструмента для чтения нового документа метаданных и обновления записей файла web.config.

Чтобы минимизировать время простоя, рекомендуется добавить логику самоисправления непосредственно в приложение, чтобы можно было использовать документ метаданных программными средствами и реагировать на смену ключей без необходимости вмешательства оператора. Далее приводится пример реализации такой функции.

  1. С помощью обозревателя решений добавьте ссылку в сборку System.IdentityModel, как описывалось ранее в этом документе.

  2. Добавьте в файл Global.asax следующие директивы using:

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. Затем добавьте в файл Global.asax следующий метод:

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    Эта логика очень простая. ValidatingIssuerNameRegistry — это класс, используемый инструментом идентификации и доступа для регистрации сведений о доверенных центрах и о ключах, которые должны использоваться для проверки токенов, выдаваемых этими центрами. WriteToConfig — это статический метод, который считывает параметры издателя из документа метаданных (в данном случае извлекаемого из файла конфигурации, где он был сохранен при первом запуске инструмента, второй строкой метода) и использует их для создания или обновления соответствующего раздела конфигурации в файле по указанному пути (построенному из текущего домена AppDomain в первой строке метода).

  4. Чтобы вставить RefreshValidationSettings() в жизненный цикл приложения, вызовите его из Application_Start(), как показано ниже.

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    Вызов RefreshValidationSettings из Application_Start гарантирует, что файл web.config будет изменен в безопасное время, в то время как вызов его позднее в жизненном цикле приложения может привести к запуску обновления.

ImportantВажно!
При автоматическом обновлении ключей проверки из приложения необходимо предпринять несколько дополнительных мер предосторожности. Основная угроза, которую нужно предотвратить, это перехват DNS, когда злоумышленник с помощью вредоносной программы направляет вас к вредоносному документу метаданных и вынуждает приложение с доверием принять неправильные ключи.

Если значения по умолчанию .NET для обработки HTTP-запросов не переопределялись, то приведенная выше угроза уже смягчена благодаря тому, что документы метаданных размещаются в конечных точках HTTPS. В результате перехвата DNS можно перенаправить запросы во вредоносную конечную точку, но такая конечная точка не может пройти проверку сервера HTTPS: не владея фактически доменом, в котором размещены документы метаданных, злоумышленник не может получить выданный для него сертификат, следовательно, клиент сможет обнаружить проблему с сервером и избежать неправильного направления.

Иногда в некоторых сценариях разработки требуется отключить проверку HTTPS (обычно с помощью класса ServicePoint). При использовании логики автоматического обновления метаданных, показанной в этом разделе, исключительно важно восстановить параметры проверки HTTPS перед развертыванием приложения в рабочей среде.

  1. Теперь, наконец, мы имеем возможность наблюдать приложение в действии. Нажмите клавишу F5. Откроется окно браузера, который будет пытаться перейти на URL-адрес, заданный в параметрах проекта в разделе "Создание приложения MVC".

    Сначала вы получите сообщение об ошибке сертификата. Это ожидаемое поведение; нажмите Перейти на этот веб-сайт (не рекомендуется). В рабочем приложении эту ошибку игнорировать не следует, но для целей настоящего руководства это приемлемо.

    CertificateError Если наблюдать за адресной строкой, можно заметить краткий момент появления URL-адреса приложения; однако модуль FAM перед приложением немедленно распознает непроверенный вызов, считывает из файла конфигурации, что нужно делать, и инициирует перенаправление входа в Azure AD. В адресной строке появляется URL-адрес центра, и пользователю предлагается пройти проверку подлинности с помощью пользовательского интерфейса Azure AD.

    noteПримечание
    Новая учетная запись пользователя, созданная ранее, не может использоваться для управления подпиской Azure, если вы изначально вошли на портал управления с помощью учетной записи Майкрософт. Если попытаться вернуться на портал управления после входа в приложение в качестве нового пользователя, то появится сообщение об ошибке. Вместо этого необходимо войти на портал управления с помощью учетной записи, которая использовалась для создания клиента каталога. Если вы изначально вошли на портал управления с помощью учетной записи Azure AD, и если созданный ранее новый пользователь получил роль глобального администратора, то этот пользователь может управлять подпиской Azure.

    Войти в AAD
  2. Введите учетные данные пользователя, созданного в клиенте Azure в первом разделе данного пошагового руководства. Нажмите кнопку Войти.

    Возможно, вы помните, что при создании пользователя в клиенте Azure AD портал управления назначил ему временный пароль. Необходимо пройти проверку подлинности с помощью этого пароля. Однако учитывая, что этот пароль временный, в течение этой самой первой операции входа вам будет предложено выбрать соответствующий пароль пользователя, прежде чем можно будет двигаться дальше в процессе проверки подлинности. После того как это будет сделано, восстановится обычный процесс входа в приложение.

    Домашняя страница приложения После успешной проверки подлинности WIF обрабатывает утверждения из поступившего токена проверки подлинности, которые в свою очередь используются простым кодом отображения, который мы добавили в домашний контроллер. С этого момента можно перемещаться по сайту без необходимости повторного прохождения проверки подлинности: каждая обратная передача будет нести файл cookie сеанса, обработанный модулем SAM.

  3. Чтобы посмотреть, что происходит при завершении сеанса, нажмите ссылку выхода в верхнем правом углу. Вы будете наблюдать перенаправления, запрограммированные ранее, которые в итоге приведут к представлению, показанному ниже.

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

В части пошагового руководства этого документа были показаны обязательные действия, которые необходимо выполнить для добавления в веб-приложение входа через Интернет. В остальной части документа мы выходит за рамки основ и глубже рассматриваем некоторые ключевые темы, а также охватываем и другие задачи, которые может потребоваться выполнить для перевода приложения на следующий уровень.

В этом разделе описывается, как изменить параметры приложения для его развертывания и запуска на веб-сайтах Azure. Само приложение в основном остается неизмененным: единственное, что требует внимания — это согласование нового адреса приложения и управления сеансами.

Для этой части документа требуется наличие веб-сайта Azure, на котором будет развернуто приложение. Если доступный веб-сайт уже имеется, можно его использовать, а если нет — то сведения о том, как создать и опубликовать веб-сайт Azure, см. в этом документе. Если вы выполняете практическое занятие из этого документа, остановитесь сразу после загрузки профиля публикации: необходимо настроить ряд моментов перед развертыванием приложения.

Настройка параметров приложения на портале управления Azure

Если вернуться к разделу, посвященному регистрации приложения, то можно вспомнить, что одним из ключевых параметров, определяющих приложение в пользовательском интерфейсе Azure AD, является URL-адрес самого приложения. До этого момента во всех действиях пошагового руководства предполагалось, что приложение размещается локально в IIS Express, однако развертывание на веб-сайтах Azure означает, что URL-адрес приложения изменится, и соответствующие параметры в Azure AD должны это отразить.

  1. Вернитесь на портал управления и выберите вкладку Active Directory слева; выберите заголовок Приложения; щелкните запись, соответствующую приложению, с которым вы работаете. Щелкните заголовок Настроить; вы перейдете в экран, в котором можно изменить параметры приложения, указанные во время создания, Для данного практического занятия пропустите верхние области экрана и перейдите вниз к разделу единого входа.

    Единый вход
  2. Найдите текстовое поле REPLY URL (URL-адрес ответа) и введите адрес целевого веб-сайта Azure (например, https://aadga.windowsazure.net/). Это позволит Azure AD возвращать токены на данный веб-сайт Azure (а не в расположение, использовавшееся ранее во время разработки) при успешной проверке подлинности. После обновления этого значения нажмите СОХРАНИТЬ в панели команд внизу экрана.

noteПримечание
Может появиться уведомление, что параметр APP ID URI (URI ИД приложения) еще использует локальное значение, созданное ранее в этом документе.

Технически, поскольку этот идентификатор присутствует в форме URI и уникален в рамках всех приложений в текущем клиенте каталога, для рассматриваемой здесь разновидности приложений будет работать любое значение; вот почему в основных инструкциях отсутствует обновление этого значения.

Однако из соображений управляемости можно изменить APP ID URI (URI ИД приложения) и предоставить значение, более подходящее для приложения. Типичным примером может быть значение, производное от URL-адреса ответа.

Обратите внимание, что если изменить значение APP ID URI (URI ИД приложения), то перед развертыванием придется вносить в приложение более существенные изменения. Дополнительные сведения см. ниже.

Подготовка приложения для запуска на веб-сайтах Azure

Конфигурация входа через Интернет большей частью готова для использования в облаке: нужно внести только одно изменение, в основном из-за особенностей веб-сайтов Azure.

Процесс входа через Интернет приводит к созданию файла cookie сеанса, который отправляется на каждый запрос с момента выполнения проверки подлинности. Этот файл cookie сеанса создается ПО промежуточного слоя WIF, и по умолчанию подписывается и шифруется посредством DPAPI (справочную информацию см. в этом документе) во избежание нарушений от клиента (таких как изменение списка утверждений для повышения привилегий). Однако параметры IIS на веб-сайтах Azure запрещают использовать DPAPI для защиты сеансов, следовательно, необходимо изменить способ, которым WIF защищает соответствующий файл cookie. Платформа .NET Framework 4.5 предлагает альтернативный подход, использующий MachineKey (см. документацию здесь) и без проблем работает с веб-сайтами Azure.

Инструмент идентификации и доступа делает это изменение очень простым.

  1. В обозревателе решений щелкните проект правой кнопкой мыши, выберите в меню пункт Идентификация и доступ…, а затем перейдите на вкладку Настройка. Появится нечто похожее на следующий снимок экрана:

    Идентификация и доступ к веб-сайтам Azure
  2. Просто установите флажок Enable web farm ready cookies (Разрешить веб-ферме готовые файлы cookie) и нажмите кнопку ОК. Инструмент позаботится о добавлении необходимых элементов в файл web.config (фактически заменит класс по умолчанию SessionSecurityTokenHandler на MachineKeySessionSecurityTokenHandler), чтобы переключиться на метод MachineKey защиты файла cookie.

    noteПримечание
    Если на предыдущем этапе параметр APP ID URI (Универсальный код ресурса ИД приложения) на портале управления Azure был изменен, то можно использовать этот пользовательский интерфейс, чтобы применить эти изменения в проекте: достаточно вставить значение APP ID URI (URI ИД приложения) в верхние два текстовых поля и нажать кнопку "ОК". Инструмент идентификации и доступа применит эти изменения в нужных местах файла конфигурации.

    Дополнительно можно рассмотреть возможность временного отключения настраиваемых сообщений об ошибках ASP.NET путем добавления записи <customErrors mode="Off" /> в раздел <system.web> файла web.config. Это поможет устранять неполадки при возникновении проблем во время разработки, однако не забудьте включить их обратно перед переходом в рабочую среду — злоумышленники могут использовать подробные сообщения об ошибках для обнаружения уязвимостей приложения, а режим customError предотвращает это.

Это все, что нужно для подготовки приложения к запуску на веб-сайте Azure. Используйте параметры публикации для развертывания приложения, затем откройте браузер, перейдите на адрес azurewebsite.net вашего приложения и выполните действия, которые рассматривались в разделе тестирования приложения данного руководства: поскольку мы построили всю пользовательскую логику как независимую от расположения, можно будет выполнять те же операции, которые испытывались локально.

Средство удостоверений и доступа автоматически создает параметры конфигурации, необходимые для интеграции приложения с клиентом Azure AD посредством протокола WS-Federation. В идеальном случае вам никогда не потребуется в действительности видеть эти параметры; однако бывают ситуации, в которых требуется изменить поведение по умолчанию, или когда необходимо устранить проблему. В таких случаях может помочь поиск собственного подхода к параметрам конфигурации WIF.

Классы WIF и метод, используемый в процессе входа через Интернет, полностью задокументированы в MSDN; здесь мы представим версию с комментариями файла web.config после его изменения инструментом идентификации и доступа. Для удобства мы также включили изменения, возникшие после действий из раздела, посвященного публикации на веб-сайтах Azure.

noteПримечание
Для полной ясности документ также включает полный исходный файл Web.config, но комментариями сопровождаются только разделы, относящиеся к WIF.

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

Для этого раздела конфигурации комментарии отсутствуют.

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

В этом разделе конфигурации данная область загружает классы, необходимые ASP.NET для чтения и интерпретации разделов конфигурации, используемых WIF для моделирования потока WS-Federation, и параметров проверки подлинности.

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

Для этого раздела конфигурации комментарии отсутствуют.

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

В этом фрагменте конфигурации записи appSettings захватываются инструментом идентификации и доступа, чтобы отслеживать важные параметры (например, адрес документа метаданных, который использовался в разделе обновления ключей), которые не сохраняются больше нигде.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

В этом разделе конфигурации два элемента <location> вырезают две области в веб-приложении, доступ к которым возможен без выполнения требований проверки подлинности (см. ниже). Раздел FederationMetadata создается инструментом идентификации и доступа. Этот инструмент создает документ метаданных, описывающий приложение, который может использоваться центрами для подготовки приложения. Раздел SignOut вы добавили сами в процессе выполнения инструкций по реализации выхода через Интернет.

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

В этом разделе конфигурации инструмент идентификации и доступа по умолчанию устанавливает параметры проверки подлинности и авторизации ASP.NET, чтобы каждая часть веб-приложения (кроме вышеуказанных исключений) требовала проверку подлинности пользователей перед обслуживанием запросов. Хотя это обычно подходит для бизнес-приложений, порой разработчики хотят сохранить области, которые могут быть доступны анонимно. В таком случае следует соответствующим образом изменить упомянутые здесь параметры.

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

Для этого раздела конфигурации комментарии отсутствуют.

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

Записи в этом разделе конфигурации вставляют в конвейер SP.NET модули HTTP, реализующие основные функции протокола и обработки сеансов. Модуль WSFederationAuthenticationModule (FAM) обеспечивает выполнение протокола WS-Federation путем проверки входящих токенов и создания сообщений входа для центра в соответствии со спецификациями протокола. Модуль SessionAuthenticationModule (SAM) создает и проверяет файлы cookie сеансов во взаимодействии с модулем FAM.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

Для этого раздела конфигурации комментарии отсутствуют.

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

В этом разделе конфигурации <system.identityModel> группирует все параметры, относящиеся к классам WIF. Первый дочерний элемент IdentityConfiguration предоставляет не зависящее от протокола описание поведения приложения. Список AudienceUris предоставляет все значения, которые будут рассматриваться WIF как приемлемые области во входящих токенах для текущего приложения; обычно они соответствуют области приложения (или универсальному коду ресурса ИД приложения в терминологии Azure AD). Входящий токен должен объявлять, что его получатель соответствует одному из перечисленных здесь значений; если это не так, то WIF будет предполагать, что это украденный токен, и отклонять вызов.

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

В этом разделе конфигурации элемент ValidatingIssuerNameRegistry содержит список допустимых кортежей ключей проверки подписи и имени издателя. В настоящем руководстве эти параметры будут отражать значения, связанные с вашим клиентом Azure AD: этот элемент гарантирует, что никакой другой издатель, включая другие клиенты Azure AD, принадлежащие другим компаниям, не может получить доступ к вашему приложению.

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

В этом разделе конфигурации данный элемент отключает проверку сертификата в конвейере WIF. Этот параметр необходим в случае Azure AD, поскольку используется самозаверяющий сертификат: при отсутствии установки самого сертификата в локальном хранилище проверка цепочки сертификатов или одноранговая проверка завершится неудачно. Обратите внимание: в действительности это не снижает безопасность проверки подлинности в Azure AD, учитывая, что параметр ValidatingIssuerNameRegistry гарантирует применение правильного сертификата; однако при использовании в том же приложении WIF для установки доверия к другим издателям учитывайте, что эти параметры будут распространяться также и на них.

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

В этом разделе можно управлять коллекцией классов, используемых WIF для обработки входящих токенов безопасности (так называемых обработчиков токенов). Его можно использовать для воздействия на поведение отдельных обработчиков либо для добавления и удаления типов обработчиков. В данном случае средство удалило обработчик сеанса по умолчанию (который основан на DPAPI и не может работать с веб-сайтами Azure) и заменило его на тот, который работает с MachineKey.

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

В этом разделе конфигурации <system.identityModel.services> используется для хранения координат, относящихся к WS-Federation.

В частности, элемент wsFederation, который используется здесь для регистрации конечной точки входа WS-Federation вашего клиента Azure AD; области (универсальный код ресурса ИД приложения) этого приложения, которая отправляется в качестве идентификатора во время входа; прочих флагов, влияющих на локальное поведение WIF, таких, как инициация сообщения входа для центра при получении ошибок 401 от приложения (passiveRedirectEnabled) или разрешение eb в случае транзакций по открытому протоколу HTTP.

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

В центре внимания этого документа находится довольно узкая задача — подключение приложения .NET к Azure AD для выполнения входа через Интернет посредством WS-Federation. Существует множество других сценариев, которые можно осуществить с помощью разных открытых протоколов, используя какой-либо программный стек на любой современной платформе или работая непосредственно на уровне протокола.

В разделе, посвященном развертыванию приложения в Azure, вы видели, что портал управления предлагает возможность изменения многих других аспектов параметров регистрации приложения. С большинством из этих дополнительных элементов управления можно будет познакомиться в следующих пошаговых руководствах из этой серии. Здесь мы только кратко упомянем, как вы можете получить нужную информацию, если решите взаимодействовать с Azure AD на уровне протокола, для входа через Интернет или для любых других поддерживаемых процедур.

  1. Откройте портал управления Azure в окне браузера и перейдите к заголовку Приложения в разделе Azure AD. Вы заметите, что панель команд внизу экрана содержит один элемент: Просмотр конечных точек. Щелкните его.

    Конечные точки приложения Появится диалоговое окно со списком конечных точек, которые можно использовать для взаимодействия с клиентом Azure AD программными средствами. Далее приводится краткое описание всех этих элементов.

    • Документ метаданных федерации. Расположение документа метаданных, описывающего клиент Azure AD как центр входа через Интернет. Как можно было видеть в разделе данного руководства, посвященном автоматическому обновлению ключей, этот документ содержит координаты метаданных WS-Federation; он также содержит метаданные протокола SAML в том же пакете. Дополнительные сведения см. в Federation Metadata.

    • Конечная точка входа WS-Federation. Точка входа для всех транзакций WS-Federation. Это конечная точка, которая использовалась в данном руководстве для потоков входа и выхода. Дополнительные сведения см. в WS-Federation Endpoint URL.

    • Конечная точка входа SAML-P. Конечная точка, используемая для реализации потоков входа в протоколе SAML. Дополнительные сведения см. в SAML Protocol Metadata and Endpoints.

    • Конечная точка выхода SAML-P. Конечная точка, используемая для реализации потоков выхода в протоколе SAML. Дополнительные сведения см. в SAML Protocol Metadata and Endpoints.

    • Конечная точка Graph Azure AD. Запросы на получение сведений о каталоге, хранящихся в текущем клиенте Azure AD, должны направляться в эту конечную точку с использованием синтаксиса API Graph. Дополнительные сведения см. в разделе Использование API Graph для запроса в Azure AD.

    • Конечная точка токенов OAuth2. Эта конечная точка используется для потоков проверки подлинности от сервера к серверу. Например, с ее помощью можно получать токены доступа для вызова конечной точки Graph. Дополнительные сведения см. в OAuth 2.0 (Preview Version).

Добавления сообщества

Показ:
© 2014 Microsoft