Планирование развертывания единого входа

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

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

Административные роли

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

Пользователь Роли Роль Azure AD (при необходимости)
Администратор службы поддержки Поддержка уровня 1 Нет
Администратор удостоверений Настройка и отладка при проблемах, касающихся Azure AD Глобальный администратор
Администратор приложения Аттестация пользователей в приложении, настройка для пользователей с разрешениями Нет
Администраторы инфраструктуры Владелец смены сертификатов Глобальный администратор
Владелец бизнеса или заинтересованное лицо Аттестация пользователей в приложении, настройка для пользователей с разрешениями Нет

Дополнительные сведения об административных ролях Azure AD см. в статье о встроенных ролях Azure AD.

Сертификаты

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

Длительность действия сертификата можно изменить на портале Azure. Обязательно запишите срок действия и узнайте, как вы будете выполнять продление сертификата. Важно правильно определить роли и списки рассылки, связанные с управлением жизненным циклом сертификата для подписи. Рекомендуем использовать следующие:

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

Настройте процесс обработки смены сертификата между Azure AD и приложением. Таким образом можно предотвратить или свести к минимуму перебои в работе из-за истечения срока действия сертификата или принудительной смены сертификата. Дополнительные сведения см. в статье Управление сертификатами для федеративного единого входа в Azure Active Directory.

Коммуникации

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

Реализуйте план предоставления информации. Обязательно сообщите пользователям о том, что ожидается изменение, когда оно вступит в силу и что делать сейчас. Кроме того, обязательно расскажите, как обратиться за помощью.

Лицензирование

Убедитесь, что приложение соответствует следующим лицензионным требованиям:

  • Лицензирование Azure AD ― единый вход для предварительно интегрированных корпоративных приложений предоставляется бесплатно. Однако количество объектов в каталоге и компоненты, которые вы хотите развернуть, может потребовать дополнительных лицензий. Полный список требований к лицензиям см. в разделе Цены на Azure Active Directory.

  • Лицензирование приложений ― вам понадобятся соответствующие лицензии для приложений в соответствии с бизнес-потребностями. Обратитесь к владельцу приложения, чтобы определить, имеют ли пользователи, назначенные приложению, соответствующие лицензии для своих ролей в приложении. Если Azure Active Directory управляет автоматической подготовкой на основе ролей, роли, назначенные в Azure AD, должны совпадать с количеством лицензий, принадлежащих приложению. Неправильное количество лицензий, принадлежащих приложению, может привести к ошибкам во время подготовки или обновления учетной записи пользователя.

Общие учетные записи

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

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

Варианты реализации единого входа

Настроить приложение для единого входа можно несколькими способами. Выбор способа единого входа зависит от того, как приложение настраивается для аутентификации.

  • В облачных приложениях для единого входа можно использовать OpenID Connect, OAuth, SAML, пароль или ссылку. Кроме того, единый вход можно отключить.
  • В локальных приложениях можно использовать единый вход на основе паролей, встроенной проверки подлинности Windows или заголовков, а также на основе ссылки. Локальные варианты работают в том случае, если приложения настроены для работы с Application Proxy.

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

Decision flowchart for single sign-on method

Можно использовать следующие протоколы единого входа:

  • OpenID Connect и OAuth. Выбирайте протоколы OpenID Connect и OAuth 2.0, если приложение, к которому вы подключаетесь, их поддерживает. Для получения дополнительных сведений см. статью Использование протоколов OAuth 2.0 и OpenID Connect на платформе удостоверений Майкрософт. Инструкции по реализации единого входа на основе OpenID Connect см. в статье Добавление приложения на основе единого входа OpenID Connect в Azure Active Directory.

  • SAML. По возможности выбирайте SAML для существующих приложений, которые не используют OpenID Connect или OAuth. Дополнительные сведения см. в разделе Протокол единого входа SAML. Краткое введение к реализации единого входа на основе SAML см. в статье Краткое руководство. Включение единого входа для корпоративного приложения в Azure Active Directory.

  • По паролю. Выберите этот вариант, если для входа в приложение используется страница в HTML. Единый вход на основе пароля также называют методом хранения паролей. Этот метод позволяет управлять доступом и паролями для веб-приложений, которые не поддерживают федерацию удостоверений. Также он полезен в ситуациях, когда несколько пользователей работают под одной учетной записью (например, с корпоративными страницами в социальных сетях).

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

  • Вход по ссылке. Используйте этот вариант, если для приложения настроен единый вход через службу другого поставщика удостоверений. Применение параметра "Вход по ссылке" позволяет настроить целевое расположение, чтобы пользователь мог выбрать приложение организации на каком-либо из порталов. Вы можете добавить ссылку на настраиваемое веб-приложение, которое используется в рамках федерации, например служб федерации Active Directory (AD FS).

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

  • Выключено. Выберите этот вариант, если приложение не готово к настройке единого входа.

  • Встроенная проверка подлинности Windows (IWA). Используйте этот способ единого входа для приложений, использующих IWA или поддерживающих утверждения. Дополнительные сведения см. в статье Ограниченное делегирование Kerberos для единого входа в приложения с помощью Application Proxy.

  • На основе заголовков. Используйте этот вариант, если приложение использует заголовки для проверки подлинности. Дополнительные сведения см. в статье Реализация единого входа на основе заголовков в локальных приложениях с помощью Azure AD Application Proxy.

Дальнейшие действия