Может ли AD предоставить моему настольному приложению Win учетные данные для моих веб-служб? - PullRequest
3 голосов
/ 20 сентября 2019

У меня есть работающее настольное приложение c # / dotnet для Windows, которое выполняет свою работу, используя различные веб-службы в моем веб-приложении.Когда приложение для настольного компьютера запускается, оно запрашивает у пользователя имя пользователя / пароль, а затем обращается к моему веб-сервису входа в систему, который возвращает токен сеанса.

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

Как мое настольное приложение может извлечь из Windows используемый токен аутентификации / авторизации (может быть, из объекта участника безопасности)?Как мое веб-приложение может проверить этот токен, чтобы оно могло доверять настольному приложению и отправить ему токен сеанса?

(Мое веб-приложение работает в моей среде, а не в домене клиента.)

С клиентами из чисто веб-приложений я делаю это успешно с SAML2 и Active Directory / Federation Services.SAML2 dance заставляет браузер моего пользователя отправлять запрос на сервер AD / FS клиента, который затем отправляет подписанный ответ обратно в мое веб-приложение.

Но я не могу понять, как сделать это чисто из настольного приложения.Есть ли мудрость?

Ответы [ 2 ]

3 голосов
/ 20 сентября 2019

Мне следует предвосхитить это тем фактом, что я никогда не делал этого, поэтому я не могу дать вам точный код, но могу указать вам верное направление.

Вы должны быть в состоянии сделатьэто с ADFS и интегрированной авторизацией Windows (WIA).В «чистом веб-приложении» браузер отправляет учетные данные вошедшего в систему пользователя на этапе авторизации.В вашем случае ваше настольное приложение должно делать все, что обычно делает браузер.В любом случае настройка на стороне веб-службы должна быть точно такой же.

В C # с HttpClient, это важная часть:

var httpClient = new HttpClient(new HttpClientHandler() 
                  {
                      UseDefaultCredentials = true
                  });

Затем, всякий раз, когда ваш httpClient отправляет запрос с ответом 401, он автоматически отправляет запрос с учетными данными пользователя Windows.Это именно то, что будет делать веб-браузер.Поэтому используйте его, когда получите токен.

Возможно, вам придется отправить строку пользовательского агента в запросе, поскольку ADFS, похоже, ограничивает WIA для определенных агентов .

Получив токен, используйте его в запросах к веб-службе.

Ключ в том, что вы копируете действия браузера.Так что, если у вас возникли проблемы с настройкой того, как должны выглядеть HTTP-запросы, то получите доступ к GET-запросу в вашем API из браузера и используйте инструменты разработчика браузера, чтобы точно проверить, как выглядит трафик, и используйте эту информацию для репликации того же запроса.в вашем коде.

2 голосов
/ 27 сентября 2019

Вы можете проверить эти примеры в github (от jelledruyts): Современные сценарии идентификации на основе утверждений для разработчиков .NET

В нем есть примеры аутентификации и авторизации с использованием Azure Active Directory и /или Службы федерации Active Directory Windows Server.


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

Жетоны бывают разных форматов.Однако для современных приложений .NET наиболее важны три вида токенов.Они следующие:

  1. Имя пользователя / пароль токена - Этот очень простой токен содержит только два утверждения: имя некоторого субъекта и пароль этого субъекта.
  2. билет Kerberos - сложнее, чем токен имени пользователя / пароля, билет включает в себя имя субъекта, имя домена Windows субъекта и другую информацию.Билеты Kerberos, выпускаемые Active Directory, также включают расширение, содержащее идентификаторы безопасности (SID), которые идентифицируют субъект и группы, к которым принадлежит этот субъект.
  3. токен SAML - язык разметки утверждений безопасности (SAML) - это язык на основе XML, принадлежащий группе стандартов мультивендоров OASIS.В отличие от других типов токенов, которые описаны здесь, токен SAML не имеет фиксированного набора утверждений, определенных для него.Вместо этого токен такого типа может содержать любые утверждения, выбранные его создателем.

Как только утверждения доступны, они могут использоваться Windows, приложением, или оба.Наиболее распространенные формы использования претензий:

  1. Аутентификация пользователя (...)
  2. Принятие решения об авторизации (...)
  3. Информация об этом пользователе (...)

Тип аутентификации:

  1. Аутентификация на основе домена (например, билеты Kerberos) :

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

Аутентификация на основе утверждений (например, токены SAML) :

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


Identity Technologies

  • Доменные службы Active Directory (AD) (полнофункциональная служба каталогов, источник токенов для билетов Kerbero и т. Д.
  • Службы федерации Active Directory (ADFS) (поддержка приложений на основе утверждений, источник токенов для токенов SAML
  • Windows CardSpace
  • Службы Active Directory облегченного доступа к каталогам (подмножество AD)услуги)
  • Identity Life-Cycle Manager (ILM) (синхронизация между различными хранилищами идентификаторов)
  • Windows Authorization Manager (инструменты для RBAC - управление доступом на основе ролей)
  • АктивенСлужбы управления правами каталогов (RMS)

Поскольку доменные службы AD реализуют Kerberos, токен по умолчанию в среде Windows - это билет Kerberos .по умолчанию в приложении ASP.NET указана встроенная проверка подлинности Windows, а в приложении WCF используется соответствующая привязка, например NetTcpBinding.В любом случае на следующем рисунке показано, какКлиенты в одном домене могут использовать билет Kerberos и доменные службы AD


Первые версии AD FS поддерживают SAML только с веб-клиентами.

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

Надеюсь, это поможет.

...