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

Обновлено: 19 июня 2015 г.

Область применения: Azure

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

• Март 2015 г. — Миграция пространств имен ACS в Google OpenID Connect

• Июнь 2014 г. — поддержка поставщика удостоверений Google

• Заметки о выпуске обновления в июле 2013 г.

• Заметки о выпуске обновления в декабре 2012 г.

• Заметки о выпуске обновления в сентябре 2012 г.

• Заметки о выпуске обновления в июне 2012 г.

• Заметки о выпуске обновления в мае 2012 г.

• Заметки о выпуске обновления в январе 2012 г.

• Заметки о выпуске обновления за июль 2011 г.

Март 2015 г. — Миграция пространств имен ACS в Google OpenID Connect

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

Июнь 2014 г. — поддержка поставщика удостоверений Google

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

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

Заметки о выпуске обновления в июле 2013 г.

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

Заметки о выпуске обновления в декабре 2012 г.

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

Обновление ACS за декабрь 2012 г. включает следующие новые возможности:

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

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

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

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

• ACS распознает сообщения 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.

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

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

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

1. Перейдите на портал управления Microsoft Azure (https://manage.WindowsAzure.com), войдите и щелкните Active Directory. (Совет по устранению неполадок: элемент Active Directory отсутствует или недоступен)

2. Щелкните контроль доступа пространство имен и нажмите кнопку "Управление".

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

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

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

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

Чтобы настроить пространство имен контроль доступа для служебной шины и управлять им, выполните следующие действия.

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

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

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

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

Дополнительные сведения см. в разделе "Практическое руководство. Управление пространством имен контроль доступа для служебная шина".

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

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

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

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

Возможность федерации клиентов каталогов с контроль доступа пространствами имен

Azure Active Directory клиенты теперь можно использовать в качестве поставщиков удостоверений в контроль доступа пространствах имен. Это позволяет многим сценариям, таким как разрешить веб-приложению принимать удостоверения организации из клиентов каталогов и удостоверений потребителей от таких поставщиков социальных сетей, как Facebook, Google, Yahoo!, учетные записи Майкрософт или любой другой поставщик 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.

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

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

Azure Co-Administrators теперь может управлять пространствами имен контроль доступа. Однако для распространения существующих соадминистраторов в существующие пространства имен контроль доступа требуется действие.

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

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

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

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

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

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

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

3. Выйдите с портала. Войдите в портал Azure с использованием учетных данных соадминистратора. Затем вы сможете управлять пространствами имен контроль доступа.

Заметки о выпуске обновления в сентябре 2012 г.

В сентябре 2012 года Microsoft Azure Active Directory контроль доступа (также известный как служба контроль доступа или ACS) получили обновление, содержащее следующие изменения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заметки о выпуске обновления в июне 2012 г.

В июне 2012 года СЛУЖБА ACS получила обновление, содержащее следующую новую функцию:

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

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

• OAuth 2.0

• WS-Federation

• WS-Trust

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

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

Важно!

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

Заметки о выпуске обновления в мае 2012 г.

В начале мая 2012 года ACS получила обновление, содержащее следующее изменение:

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

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

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

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

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

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

Заметки о выпуске обновления в январе 2012 г.

25 января 2012 г. ACS 2.0 получил обновление, содержащее следующие изменения:

• Изменения в сообщениях об ошибках ACS для неудачных запросов на проверку подлинности

• Изменения кодов ошибок OAuth 2.0 для неудачных запросов на проверку подлинности

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

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

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

Ответ при проверке подлинности	До	После
Издатель не существует	ACS50026 IssuerNotFound	ACS50008 InvalidSwt, ACS50009 InvalidSaml, OR ACS50012 AuthenticationFailed
Неправильные учетные данные	ACS50006 InvalidSignature

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

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

Ответ при проверке подлинности	Примеры	До	После
Издатель не существует		invalid_client	invalid_client
Неправильные учетные данные	SWT подписан неправильным ключом. Идентификатор клиента и учетные данные соответствуют настроенным в ACS.	invalid_grant
Не удалось выполнить проверку подлинности	Ошибка проверки URI аудитории. Ошибка проверки сертификата. Утверждение из удостоверения службы содержит самостоятельно выданные утверждения.	invalid_grant
Неверно сформированное утверждение	В SWT отсутствует подпись. Утверждение SAML является недопустимым XML.	invalid_request
Неверно сформирован код авторизации		invalid_grant	invalid_grant
Неверный код авторизации		invalid_grant
Неверно сформирован запрос OAuth2		invalid_request	invalid_request

Заметки о выпуске обновления за июль 2011 г.

Заметки о выпуске обновления ACS 2.0 за июль 2011 г. содержат следующие элементы:

• Предварительные требования

• Новые возможности

• Изменения

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

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

Предварительные требования

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

Новые возможности

Обновление acS за июль 2011 г. содержит следующие новые возможности:

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

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

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

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

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

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

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

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

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

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

Изменения

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

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

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

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

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

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

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

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

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

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

• При создании издателя для утверждения утверждений в запросе маркера по протоколу OAuth WRAP при использовании удостоверения службы с одинаковым именем для проверки подлинности с помощью ACS.

Квоты

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

Ограничения службы

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