Эта документация перемещена в архив и не поддерживается.

Заметки о выпуске

Опубликовано: Апрель 2011 г.

Обновлено: Июнь 2015 г.

Назначение: Azure

В этом разделе содержится описание новых возможностей каждого выпуска Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS), приводятся отличия каждого выпуска продукта от предшествующих выпусков и выделяются изменения, которые могут повлиять на работу кода, написанного для более раннего выпуска.

Служба ACS внедрила функцию, которая поможет владельцам пространств имен ACS перенести свои конфигурации поставщика удостоверений Google из OpenID 2.0 в OpenID Connect. Клиенты должны перенести свои пространства имен ACS в OpenID Connect до 1 июня 2015 года и свой код серверной части, чтобы использовать идентификаторы OpenID Connect, до 1 января 2017 года.Невыполнение соответствующих действий до наступления каждого крайнего срока приведет к нарушению работы ваших приложений. Подробное руководство см. в разделе Перенос пространств имен ACS в Google OpenID Connect.

С 19 мая 2014 г. новые пространства имен ACS не могут использовать Google как поставщик удостоверений. Пространства имен ACS, использующие Google и зарегистрированные до этой даты, не будут затронуты. Это нового ограничение связано с тем, что Google постепенно сворачивает поддержку протокола OpenID 2.0, от которого зависит служба ACS, и прекратил регистрацию новых приложений. Существующие пространства имен ACS, которые использовали Google, продолжат работать до 20 апреля 2015 г. Если вашему приложению требуется поддержка учетных записей Google, рекомендуется зарегистрировать приложение с ними напрямую.

Пользователь, пытающийся выполнить вход в новое пространство имен ACS с помощью учетной записи Google, будет перенаправлен на страницу с ошибкой HTTP 400.

Новое пространство имен ACS и ошибка Google

С целью повышения уровня доступности и производительности ACS для всех пользователей в службе ACS было установлено ограничение в 30 запросов маркера в секунду для каждого пространства имен. Если пространство имен превышает это ограничение в течение длительного времени, ACS отклонит запросы маркера из пространства имен на время интервала и вернет ошибку HTTP 429 / ACS90055 "Слишком много запросов". Дополнительные сведения см. в разделах Ограничения службы ACS и Коды ошибок ACS.

Новые функции

Вышедшее в декабре 2012 г. обновление Служба управления доступом предлагает следующие новые возможности.

Поддержка федеративного единого выхода с помощью протокола WS-Federation

Веб-приложениям, использующим Служба управления доступом для включения единого входа (SSO) с помощью поставщиков удостоверений с протоколом WS-Federation, теперь доступны преимущества единого выхода. Когда пользователь выходит из веб-приложения, Служба управления доступом может автоматически вывести его из поставщика удостоверений и из других приложений проверяющей стороны, которые работают с этим же поставщиком удостоверений.

Эта возможность действует для поставщиков удостоверений WS-Federation, включая Active Directory Federation Services 2.0 и Идентификатор Windows Live ID (учетная запись Майкрософт). Чтобы активировать единый выход, Служба управления доступом выполняет следующие задачи для конечных точек, применяющих протокол WS-Federation.

  • Служба управления доступом распознает сообщения wsignoutcleanup1.0 от поставщиков удостоверений и отвечает, отправляя сообщение wsignoutcleanup1.0 в приложения проверяющей стороны.

  • Служба управления доступом распознает сообщения wsignout1.0 и wreply из приложений проверяющей стороны и отвечает, отправляя сообщения wsignout1.0 поставщиками услуг и сообщения wsignoutcleanup1.0 в приложения проверяющей стороны.

Дополнительные сведения см. в разделах Образец кода: ASP.NET MVC 4 с федеративным выходом и Пассивная аутентификация для ASP.NET с применением WIF.

Прекращена поддержка ACS 1.0

В этом выпуске не поддерживается служба Access Control Service 1.0, а также отсутствует поддержка перехода с Access Control Service 1.0 на Access Control Service 2.0.

Переход к Пространство имен Access Control на новом портале управления Azure

Новый портал управления Azure (http://manage.WindowsAzure.com) содержит путь к знакомому порталу управления ACS, где выполняется создание Пространство имен Access Control и управление ими.

Переход на портал управления ACS

  1. Перейдите на портал управления Microsoft Azure, выполните вход и щелкните Active Directory. (Совет по устранению неполадок. Элемент "Active Directory" отсутствует или недоступен)

  2. Последовательно щелкните Пространство имен Access Control и Управлять.

Чтобы создать пространство имен Access Control, щелкните Создать, Службы приложений, Управление доступом, а затем выберите Быстрое создание. (Или щелкните Пространства имен Access Control перед тем, как щелкнуть Создать.)

Чтобы получить справку по задачам управления ACS на портале управления Microsoft Azure, щелкните Active Directory, а затем Справка (?). (Или щелкните Active Directory, пространства имен Access Control, а затем Справка.)

Переход к Пространство имен Access Control для служебной шины

Когда пользователь создает пространство имен служебной шины на , портал автоматически создаст Пространство имен Access Control для служебной шины.

Настройка Пространство имен Access Control для служебной шины и управление им

  1. Войдите на портал управления платформой Azure.

  2. Щелкните Служебная шина и выберите служебную шину.

  3. Щелкните Ключ доступа, а затем —Открыть портал управления ACS.

Чтобы проверить связь Пространство имен Access Control со служебной шиной, просмотрите поле "Пространство имен службы" в верхней части страницы службы Access Control Service. Имя пространства имен состоит из имени служебной шины с суффиксом -sb.

Дополнительные сведения см. в Инструкции Управление пространством имен Access Control для служебной шины.

Усовершенствования портала управления ACS для просмотра ключей поставщика удостоверений WS-Federation, возможности скрытия паролей

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

  • Сертификаты для подписи теперь отображаются в разделе "Изменение поставщика удостоверений WS-Federation". Ранее сертификаты, импортированные из метаданных WS-Federation, которые используются для проверки подписи маркеров, выданных этим поставщиком удостоверений, не отображались на портале управления ACS. Теперь в разделе "Изменение поставщика удостоверений WS-Federation" представлены сведения об импортированных сертификатах, включая даты окончания срока действия и состояние. Для обновления этих сертификатов можно использовать новый параметр «Повторный импорт данных с URL-адреса метаданных WS-Federation перед сохранением».

  • Пароли и симметричные ключи подписи скрыты по умолчанию. Чтобы предотвратить непреднамеренное разглашение паролей и симметричных ключей, их значения скрыты по умолчанию на всех экранах редактирования на портале. Чтобы намеренно отобразить значений пароля или симметричного ключа (например, для копирования в приложение), нужно нажать кнопку «Показать пароль» или «Показать ключ».

Возможность интеграции клиентов Directory с Пространство имен Access Control

Теперь клиенты Azure Active Directory могут выступать в качестве поставщиков удостоверений в Пространство имен Access Control. Это позволяет реализовать множество сценариев, таких как настройка веб-приложения для принятия удостоверений организации от клиентов Directory и удостоверений потребителей от поставщиков социальных сетей, например Facebook, Google, Yahoo!, Microsoft или других поставщиков OpenID. Подробные инструкции о реализации сценария см. в записи Подготовка клиента Azure Active Directory в качестве поставщика удостоверений в пространстве имен ACS.

Поддержка протокола SAML 2.0 для приложений проверяющей стороны (Developer Preview)

Теперь служба ACS поддерживает протокол SAML 2.0 для выдачи маркеров для приложений проверяющей стороны. Поддержка протокола SAML 2.0 была выпущена в виде Developer Preview, что значит, что сведения о реализации протокола SAML 2.0 могут быть изменены. Дополнительные сведения см. в статье Developer Preview: SAMLProtocol.

Известные проблемы

В обновлении Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS), вышедшем в декабре 2012 г., были выявлены следующие известные проблемы.

Теперь соадминистраторы Azure могут управлять Пространство имен Access Control. Однако для ввода существующих соадминистраторов в уже существующие Пространство имен Access Control требуется выполнить определенное действие.

До выхода обновления в ноябре 2012 г. была решена проблема, когда по умолчанию управлять созданными в подписке Пространство имен Access Control мог только главный администратор службы Azure. Если соадминистратор Azure пытался получить доступ к порталу управления ACS для обращения к Пространство имен Access Control, отображался один из следующих кодов ошибок ACS.

  • ACS50000: При выдаче токена произошла ошибка.

  • ACS60000: Ошибка во время обработке правил для проверяющей стороны с использованием "uri:WindowsLiveID" издателя.

  • ACS60001: Выходные утверждения не были созданы во время обработки правил.

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

  1. Войдите на портал Azure (https://windows.azure.com/) с помощью учетных данных администратора службы или администратора учетной записи.

  2. Удалите и заново добавьте соадминистратора, следуя рекомендациям в статье Добавление соадминистратора в подписку Azure (http://msdn.microsoft.com/en-us/library/windowsazure/gg456328.aspx)

  3. Выйдите с портала. Войдите в портал Azure с использованием учетных данных соадминистратора. После этого вы сможете управлять Пространство имен Access Control.

В сентябре 2012 г. вышло обновление для Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS) со следующими изменениями.

Для атрибута entityID, публикуемого в метаданных WS-Federation, созданных службой ACS, теперь используются символы нижнего регистра

Теперь для атрибута "entityID" в метаданных WS-Federation, публикуемых Пространство имен Access Control всегда используется нижний регистр. В предыдущих выпусках использовался тот регистр букв, который применялся при создании пространства имен на портале Azure. Атрибут entityID определяет Пространство имен Access Control для приложений проверяющей стороны. Далее приводится пример атрибута:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Это изменение было необходимо для решения проблем, связанных с проверкой маркера, когда регистр букв Пространство имен Access Control в маркере, выданном Служба управления доступом (всегда в нижнем регистре) не совпадал с регистром Пространство имен Access Control, импортированного проверяющей стороной. Проблемы относительно учета регистра не затрагивают проверяющие стороны, работающие с Windows Identity Foundation.

Теперь для сертификатов X.509, отправляемых в ACS, действует ограничение размера открытого ключа в 4096 бит

Теперь все сертификаты X.509, отправляемые в Пространство имен Access Control через портал управления ACS или службу управления, должны иметь открытый ключ, размер которого не превышает 4096 бит. В их число входят сертификаты, используемые для подписи, шифрования и расшифровки маркера.

Чтобы проверить размер открытого ключа в Windows, следует открыть файл сертификата (CER), перейти на вкладку «Сведения» и просмотреть значение в поле «Открытый ключ». Сертификаты, применяющие защищенный алгоритм подписи sha256RSA, будут иметь открытый ключ размером 2048 бит.

Все существующие сертификаты, размер ключа которых превышает 4096 бит, будут и далее работать с ACS, однако их повторное сохранение в ACS будет возможно только после замены на совместимый сертификат.

Незначительное изменение алгоритма выбора первичного ключа, используемого во время подписи маркера с помощью сертификата X.509

На портале управления ACS и в службе управления есть параметр «Сделать основным» для сертификатов подписи маркеров. Если этот параметр выбран, служба ACS подписывает маркеры с помощью этого сертификата. Начиная с данного выпуска, если параметр "Сделать основным" не выбран ни для одного настроенного сертификата подписи маркеров, Пространство имен Access Control будет использовать существующий неосновной сертификат подписи с самой ранней датой начала подписи маркеров. ACS по-прежнему не подписывает маркеры с помощью неосновного сертификата подписи, если основной сертификат существует, но является недействительным или истек срок его действия.

Бета-версия JWT: изменение поведения подписания при подписи маркера JWT с использованием сертификата глобального пространства имен или ключа

До выхода бета-версии поддержки формата JSON Web Token (JWT) в июне 2012 г. служба ACS использовала следующий порядок очередности для определения ключа, который должен был применяться для подписи каждого маркера JWT, выданного каждому приложению проверяющей стороны.

  • Симметричный ключ подписи, назначенный проверяющей стороне (если доступен)

  • Сертификат подписи X.509, назначенный проверяющей стороне (если доступен)

  • Симметричный ключ подписи, назначенный Пространство имен Access Control

  • Сертификат подписи X.509, назначенный Пространство имен Access Control

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

  • Симметричный ключ подписи, назначенный проверяющей стороне (если доступен)

  • Сертификат подписи X.509, назначенный проверяющей стороне (если доступен)

  • Сертификат подписи X.509, назначенный Пространство имен Access Control

В июне 2012 г. вышло обновление для Служба управления доступом со следующими новыми возможностями.

Доступность формата JWT для приложений проверяющей стороны (бета-версия)

В этом обновлении представлена поддержка бета-версии формата JSON Web Token (JWT) в Служба управления доступом. JWT представляет собой упрощенный формат маркера, закодированный в JSON, для подписи которого можно использовать сертификат X.509 или симметричный ключ и который может выдаваться Служба управления доступом приложениям провер��ющей стороны по следующим протоколам:

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

Теперь формат маркера JWT является выбираемым параметром в разделе "Приложения проверяющей стороны" в Портал управления ACS и может быть настроен в Служба управления ACS.

Дополнительные сведения о формате маркера JWT см. в статье Спецификация JSON Web Token. Образцы кода ACS с использованием маркеров JWT будут представлены позднее.

ImportantВажно!
Поддержка JWT в Служба управления доступом доступна в виде бета-версии. Это значит, что все действия по реализации JWT могут быть изменены. Разработчикам рекомендуется поэкспериментировать с этом форматом. Однако JWT нельзя использовать в выпущенных в производство службах, поскольку действие маркера может быть изменено без уведомления.

В начале мая 2012 г. вышло обновление для Служба управления доступом со следующими изменениями.

Изменения свойств ИД объекта, предоставленных через службу управления

В настоящее время служба управления Служба управления доступом предоставляет свойство ИД для каждого поддерживаемого типа объекта, как описано в разделе Справочник по API службы управления ACS. Эти свойства ИД автоматически задаются и управляются Служба управления доступом.

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

Как правило, не рекомендуется, чтобы приложения хранили или использовали встроенные зависимости этих ИД для запроса конкретных объектов через службу управления. Вместо этого рекомендуется, чтобы типы объектов RelyingParty, ServiceIdentity, RuleGroup и Issuer запрашивались с помощью свойства Name, а другие типы объектов запрашивались с помощью ИД родительского объекта (например, RuleGroupId для правил или IssuerId для поставщиков удостоверений).

Изменения параметров сортировки базы данных для обработки правил

Чтобы расширить поддержку международных языковых пакетов и повысить уровень безопасности, в этом выпуске Служба управления доступом обновляет базовые параметры сортировки базы данных SQL, используемую для сравнения входящих утверждений из SQL_Latin1_General_CP1_CI_AS с Latin1_General_100_BIN2. Благодаря этому изменению Служба управления доступом может поддерживать дополнительные наборы знаков и сочетания наборов знаков. В приложениях, которые зависят от входящих утверждений со строками с несколькими наборами знаков, не поддерживаемыми SQL_Latin1_General_CP1_CI_AS, могут появиться другие или дополнительные утверждения, являющиеся результатом новой сортировки. Клиентам, которые хотят воспользоваться этой новой возможностью, рекомендуется проверить имеющиеся приложения на совместимость с новыми параметрами сортировки SQL.

25 января 2012 г. вышло обновление для Служба управления доступом 2.0 со следующими изменениями.

В предыдущем выпуске служба Служба управления доступом выводила различные коды ошибок, когда клиент проходил проверку подлинности с несуществующим издателем (код ошибки: ACS50026) или неправильными учетными данными (код ошибки: ACS50006). Эти коды ошибок отображались, если клиент пытался пройти проверку подлинности с помощью недопустимого имени удостоверения службы или с помощью маркера SWT или SAML, выданного недопустимым поставщиком удостоверений.

Служба управления доступом вернет коды ошибок ACS50008, ACS50009 или ACS50012 для неудачной проверки подлинности в случаях с неверными SWT, SAML и именем пользователя/пароля, соответственно. Подробные сведения представлены в таблице ниже.

 

Ответ при проверке подлинности До После

Издатель не существует

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml ИЛИ

ACS50012 AuthenticationFailed

Неправильные учетные данные

ACS50006 InvalidSignature

В предыдущем выпуске служба Служба управления доступом выводила различные коды ошибок OAuth 2.0, когда клиент проходил проверку подлинности с несуществующим издателем ((invalid_client) или неправильными учетными данными (invalid_grant). Это поведение также было обновлено. Служба управления доступом будет возвращать invalid_request в случае неправильно сформированного запроса OAuth 2.0, invalid_client в случае ошибки проверки подлинности клиента или неправильно сформированного или недопустимого утверждения и invalid_grant в случае неправильно сформированного или недопустимого кода авторизации. Подробные сведения представлены в таблице ниже.

 

Ответ при проверке подлинности Примеры До После

Издатель не существует

invalid_client

invalid_client

Неправильные учетные данные

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

invalid_grant

Не удалось выполнить проверку подлинности

Ошибка проверки URI аудитории. Ошибка проверки сертификата. Утверждение из удостоверения службы содержит самостоятельно выданные утверждения.

invalid_grant

Неверно сформированное утверждение

В SWT отсутствует подпись. Утверждение SAML является недопустимым XML.

invalid_request

Неверно сформирован код авторизации

invalid_grant

invalid_grant

Неверный код авторизации

invalid_grant

Неверно сформирован запрос OAuth2

invalid_request

invalid_request

В заметках о выпуске обновления Служба управления доступом 2.0 в июле 2011 г. рассматриваются следующие темы.

Все Пространство имен Access Control автоматически получают июльское обновление 2011 г. В этом обновление необходимые условия Служба управления доступом для новых или существующих клиентов остались без изменений. Дополнительные сведения о текущих необходимых условиях Служба управления доступом см. в разделе Предварительные требования для ACS.

Вышедшее в июле 2011 г. обновление Служба управления доступом предлагает следующие новые возможности.

1. Теперь правила поддерживают два входящих утверждения

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

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

Дополнительные сведения о правилах с двумя входящими утверждениями см. в разделе Группы правил и правила.

2. Локализация на одиннадцати языках

Теперь портал управления Служба управления доступом и страница входа в Служба управления доступом для приложений проверяющей стороны поддерживают локализацию на одиннадцати письменных языках, включая английский, французский, немецкий, итальянский, японский, корейский, русский, испанский, португальский (Бразилия), китайский (упрощенное и традиционное письмо). Также доступен вариант «английский (международная версия)», использующий альтернативный формат даты для установки и отображения дат действия и окончания срока действия ключей. Для изменения письменного языка отображения пользовательских интерфейсов можно использовать один из следующих трех способов.

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

  • URL-адрес. Язык интерфейса портала Служба управления доступом можно изменить путем добавления параметра lang в конец URL-адреса запроса. Допустимыми значениями этого параметра являются языковые коды ISO 639-1/3166, соответствующие поддерживаемым языкам. Примеры значений: en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn и zh-tw. Далее приводится пример URL-адреса портала управления Служба управления доступом с параметром, задающим в качестве отображаемого языка французский язык:

    https://your-namespace.accesscontrol.windows.net/?lang=fr

  • Параметры веб-браузера. Если для установки языка никогда не использовался параметр URL-адреса "lang" или меню выбора языка, портал управления Служба управления доступом или страницы входа в Служба управления доступом определят отображаемый по умолчанию язык на основе языковых параметров, заданных в настройках веб-браузера.

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

1. Теперь все ответы OAuth 2.0 кодируются в формате UTF-8.

В первоначальном выпуске Служба управления доступом в качестве кодировки набора знаков для всех ответов HTTP с конечной точки OAuth 2.0 использовался формат US-ASCII. В выпуске обновления в июле 2011 г. все ответы HTTP кодируются в формате UTF-8, поддерживающем расширенные наборы знаков.

В данном выпуске присутствует следующая известная проблема.

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

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

  • ACS80001: Это правило настроено для использования типа издателя утверждения, который не поддерживается порталом управления. Изучите и измените это правило в службе управления.

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

  • В сценарии делегирования OAuth 2.0 запись издателя создается в Пространство имен Access Control с помощью службы управления ACS, и у этого издателя нет связанного поставщика удостоверений.

  • Когда издатель создается с целью подтверждения утверждений в запросе маркера по протоколу WRAP OAuth при одновременном использовании удостоверения службы с одинаковым названием для проверки подлинности в Служба управления доступом.

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

Дополнительные сведения об ограничениях службы см. в разделе Ограничения службы ACS.

Показ: