Назад | Перейти на главную страницу

Как пройти аутентификацию в службах управления правами Active Directory с помощью токена-носителя из служб федерации Active Directory

Моя цель - использовать Пакет SDK для управления правами Microsoft 4.2 в системе Linux для доступа и управления защищенными документами.

Я не могу пройти аутентификацию на сервере RMS через сервер федерации (это настройка, которая требуется для SDK).

У меня следующая установка:

Все узлы в кластере работают под управлением Windows Server 2016 и имеют сертификаты, подписанные центром регистрации. Корневой CA и промежуточные сертификаты RA установлены на хостах. Сертификат подписи токена и сертификаты дешифрования токена для службы федерации также подписаны RA.

Приложения Microsoft Office (которые используют более ранний протокол SOAP) могут взаимодействовать со службой RMS. Библиотека SDK RIghts Management использует более легкий протокол JSON, предоставляемый расширением для мобильных устройств.

Я настроил запись DNS SRV для _rmsdisco._http._tcp.mydomain.

Расширение мобильного устройства настроено для использования https: //fs1.mydomain для аутентификации.

На fs1.mydomain я настроил «Серверное приложение для доступа к веб-API». Серверное приложение имеет идентификатор клиента <ID> и секрет клиента <SECRET>. Веб-API имеет идентификатор проверяющей стороны api.rms.rest.com.

Я не могу заставить клиент SDK RMS пройти аутентификацию на сервере RMS с учетными данными клиентского приложения. Это неудачный обмен oauth2:

  1. Попытка получить https: //rms1.mydomain: 443 / my / v2 / servicediscovery? email = user1 @ mydomain
  2. Это возвращает ответ 401 с ожидаемым заголовком WWW-Authenticate:
    WWW-Authenticate: Bearer realm="api.rms.rest.com", authorization="https://fs1.mydomain/adfs/oauth2/authorize"
  3. POST следующий текст в https: //fs1.mydomain/adfs/oauth2/token:
    grant_type=client_credentials&client_id=<ID>&client_secret=<SECRET>&resource=api.rms.rest.com
  4. Получите подписанный токен аутентификации с расшифрованным телом, выглядящим примерно так:
    {"aud":"microsoft:identityserver:api.rms.rest.com","iss":"http: //fs1.mydomain/adfs/services/trust","iat":1553792250,"exp":1553795850,"apptype":"Confidential","appid":"<ID>","authmethod":"http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password","auth_time":"2019-03-28T16:57:30.037Z","ver":"1.0"}
  5. Попытайтесь снова получить URI обнаружения службы, на этот раз добавив следующий заголовок:
    Authorization: Bearer <TOKEN>
  6. Сервер возвращает ответ 401 вместо 200.

Я предполагаю, что в конфигурации сервера есть ошибка, но не знаю какая. Я не вижу ничего зарегистрированного на сервере RMS, но я предполагаю, что он не может проверить токен oauth. Сертификат для подписи токена присутствует в FederationData.xml, предоставленном сервером федерации. Я также установил его на сервере RMS в разделе «Сертификаты» (сертификаты центра сертификации также присутствуют).

На этом я застрял, поэтому обращаюсь за помощью.

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

Установите и настройте расширение для мобильных устройств AD RMS, как описано в документации. Вот.

Есть еще кое-что, что вам нужно сделать, что не задокументировано (и, как я полагаю, является новым для Windows Server 2016). После добавления клиента ADFS в Powershell, например, приложение общего доступа MAC OS X RMS:

Add-AdfsClient -Name "RMS Sharing App for macOS" -ClientId "96731E97-2204-4D74-BEA5-75DCA53566C3" -RedirectUri @("com.microsoft.rms-sharing-for-osx://authorize")

Затем вам необходимо предоставить клиентскому идентификатору разрешение на доступ к защищенному ресурсу (даже если вы настроили «Разрешить доступ всем пользователям»):

Grant-AdfsApplicationPermission -ClientRoleIdentifier "96731E97-2204-4D74-BEA5-75DCA53566C3" -ServerRoleIdentifier "api.rms.rest.com"

Теперь вы можете пройти аутентификацию, используя идентификатор клиента и действительные учетные данные для пользователя домена. Тело запроса аутентификации становится:
grant_type=password&client_id=96731e97-2204-4d74-bea5-75dca53566c3&username=user1@mydomain&password=mypassword&resource=api.rms.rest.com

Возвращенный токен имеет примерно такую ​​полезную нагрузку:
{"aud":"microsoft:identityserver:api.rms.rest.com","iss":"http: //fs1.mydomain/adfs/services/trust","iat":1553874942,"exp":1553878542,"email":"user1@mydomain","upn":"user1@mydomain","apptype":"Public","appid":"96731E97-2204-4D74-BEA5-75DCA53566C3","authmethod":"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport","auth_time":"2019-03-29T15:55:42.124Z","ver":"1.0"}

Этот токен принимается сервером RMS.

Одна маленькая деталь: URL обнаружения службы не совсем правильный. Даже с рабочим токеном на предъявителя при попытке доступа https: //rms1.mydomain: 443 / my / v2 / servicediscovery? email = user1 @ mydomain приведет к ответу 404. Замените «v2» на «v1», и ответ будет 200. Мое замешательство было связано с эффективным жестким кодированием SDK «/ my / v2».

Остается еще пара вопросов:

  1. Можно ли заставить расширение RMS Mobile Device Extension принимать токен, не содержащий запроса по электронной почте? Это необходимо для работы аутентификации по идентификатору клиента / секрету клиента.
  2. В чем разница между «/ my / v1» и «/ my / v2» и как узнать, какой из них использовать?