1. Загружается основный модуль программы, который содержит логику аутентификации на STS.
2. После успешной аутентификации подключаются другие модули.
3. В каждом модуле находится proxy-client для доступа к WCF — сервисам.
Необходимо реализовать механизм, чтобы после единого ввода логина и пароля и получения Токена безопасности от STS, можно было аутентифицироваться на прочих WCF-сервисах, на которые идёт обращение из модулей без передачи
туда логина-пароля, а при помощи ранее полученного токена.
С уважением,
Сергей
Re: Аутентификация rich-клиента на нескольких WCF-сервисах
От:
Аноним
Дата:
19.01.14 05:41
Оценка:
Здравствуйте, WSA, Вы писали:
Угу, схема нормальная. А вопрос какой?
Re[2]: Аутентификация rich-клиента на нескольких WCF-сервисах
Да проблнма в том, что далее схемы дело не идёт )))
Ни как не удаётся заставить работать схему.
У меня STS успешно выдаёт токен, я его получаю клиентом, расшифровываю и назначаю Thread.CurrentPrincipal на клиенте....
А вот дальше... прям стена... ни как не удаётся настроить WCF сервисы, чтобы принимали этот токен.
Re[3]: Аутентификация rich-клиента на нескольких WCF-сервисах
Здравствуйте, WSA, Вы писали:
WSA>У меня STS успешно выдаёт токен, я его получаю клиентом, расшифровываю и назначаю Thread.CurrentPrincipal на клиенте.... WSA>А вот дальше... прям стена... ни как не удаётся настроить WCF сервисы, чтобы принимали этот токен.
И не будет, на сколько я понимаю, в меру своих знаний — базовый WCF не позволяет такие манипуляции.
Вы можете сделать один из следующих варианов:
1. Использовать только "чистый" WCF.
Тогда вам понадобится ws2007FederationHttpBinding. Там примерно следующая схема:
вместо STS который работает на базе HTTP Redirect вы используете STS, работающий поверх SOAP и аутентифицирующий пользователй по логину и паролю.
вы настраиваете 2 биндинга: №1 — ws2007FederationHttpBinding для соединения с вашими сервисами и №2 — ws2007HttpBinding для соединения с STS. Биндинг №2 указываете в качестве параметра у №1.
на сайте вы запоминаете логин и пароль и при создании WCF-клиента в качестве credentials передаете эти два параметра.
дальше все за вас делает WCF: стучится с вашим логином и пролем на STS (биндинг №2), аутентифицируется там и получает токен (в этом токене помимо прочего будут лежать ключи для защиты соединения), затем с полученным тоеном идет (биндинг №1) на непосредственный сервис.
2. Использовать Windows Identity Foundation.
Именно она позволит сделать сценарий именно как у вас. Только обратите внимание, что начиная с .Net 4.5 классы WIF вроде как с некоторыми небольшими изменениями перекочевали в основной фремворк. Хотя "старую" WIF (которая поставляется отдельной библиотекой) по-прежнему можно использовать.
Для более предметной беседы, ответьте, плиз:
Какой .Net используете
Что используете в качестве STS (AD, свое решение — тогда на чем, сторонний продукт)
Используете ли WIF
Re[4]: Аутентификация rich-клиента на нескольких WCF-сервисах
Немного поправлюсь... Почему-то подумал, что у вас сайт и обращение к STS идет через HTTP Redirect.
Собственно, раз у вас rich клиент, то с большой вероятностью обращение к STS идет поверх SOAP. Осталось понять по какому именно протоколу: WS-Federation или SAML (это не только язык разметки токенов, но и протокол передачи из, чтобы не путать его еще часто называют SAML-P) у вас идет обращение, а также возвращает ли токен закрытые ключи для шифрования канала (без этого ws2007FederationHttpBinding не будет работать).
Re[5]: Аутентификация rich-клиента на нескольких WCF-сервисах
Михаил, здравствуйте. Спасибо за интерес к теме и информативные комментарии.
>> Какой .Net используете
.Net 4.5. И это вносит дополнительную головную боль. Как вы заметили, в 4.5 WIF перекочевал во вреймворк, да и к томуже в другой неймспейс. в 4.5 это System.IdentityModel
>> Что используете в качестве STS (AD, свое решение — тогда на чем, сторонний продукт)
Как STS использую Thinktecture Identity Server v2
>> Используете ли WIF
Да, использую, но пока что не очень осознанно... Ничего не работает, я не знаю поэтому что на что влияет.
>> WS-Federation или SAML
В качестве формата утверждений SAML 2.0. Как протокол обмена как с WIF.... пока ничего не работает пробую все варианты из инета... в котором блин все примеры не для 4.5
С уважением,
Сергей
Re[6]: Аутентификация rich-клиента на нескольких WCF-сервисах
этот сервер и то, как он работает (мы сами используем самописный вариант на базе WIF 4.0).
что поменялось в WIF после выхода 4.5
Возможно, смогу подсказать что-то более конкретное (если это будет еще актуально на тот момент).
Сразу оговорюсь — ваша схема вполне работоспособна, т.к. мы сами работаем по схожей. Разница только в том, что: а) токенов мы получаем несколько — в них разная информация для разных случаев, у нас Web, а не Desktop клиент (поэтому часть токенов мы получаем по HttpRedirect, а что-то по SOAP).
Но нюансов мы насобирали там просто невозможное количество, поэтому давать советы типа "посмотрите тут, это должно работать", я воздержусь, прежде чем не перепроверю.
Идет?
Re[7]: Аутентификация rich-клиента на нескольких WCF-сервисах
Кстати, Михаил, может проще если я вам дам адрес этого STS и админские права, смодете поковыряться в уже работающем тестовом STS thinktecture? Мой email: zergy@list.ru
Re: Аутентификация rich-клиента на нескольких WCF-сервисах
Здравствуйте, WSA, Вы писали:
WSA>Необходимо реализовать механизм, чтобы после единого ввода логина и пароля и получения Токена безопасности от STS, можно было аутентифицироваться на прочих WCF-сервисах, на которые идёт обращение из модулей без передачи WSA>туда логина-пароля, а при помощи ранее полученного токена.
Я смог установить и настроить Thinktecture Server (кстати, если я не путаю, один из его авторов достаточно активный участник форумов MSDN по WIF и Identity, я даже пользовался как-то его советами).
А также мне удалось разобраться с большей частью нововведений (точнее изменений) в WIF 4.5 и построить, хоть и с некоторыми "костылями", работающий пример по первому описанному мною сценарию (когда вы сами руками токен не получаете, а всем занимается только инфраструктура WCF+WIF — сейчас они почти неотделимы).
К сожалению, у меня катастрофически отсутсвует время, чтобы написать подробный ответ и пример (а за одно разобраться, почему же потребовались костыли — по идее все должно работать и без них...)
Сергей, на сколько вас жмет время? Можете ли вы подождать до понедельника с этой задачей?
Если да, то я постараюсь за выходные все еще раз перепроверить и сделать детальное описание того, что я узнал.
Re[2]: Аутентификация rich-клиента на нескольких WCF-сервисах
Здравствуйте Михаил. МР>Сергей, на сколько вас жмет время? Можете ли вы подождать до понедельника с этой задачей?
Мне даже не удобно отвечать )) Ну естественно подожду. Я всё ещё эксперементирую, но пример от вас, воплотившего подобный сценарий в жизнь, это очень круто. Буду ждать с нетерпением. Я подготовлю к понедельнику солюшен с клиентом, который получает и дешефрует токен, может быть вам будет интересно взглянуть. Куда бы отправить? Если вы напишите мне на zergy@list.ru я отправлю мылом.
Что ж, я в принципе разобрался со всеми сложностями и напастями, что мне встречались и теперь могу рассказать, что же у меня получилось.
На текущий момент, у меня готов первый вариант, из тех, что я описывал, т.е. практически всю работу на себя берет WCF (правда в .Net 4.5 работа так или иначе идет с использованием WIF, но от вас лично не потребует ни строчки кода для WIF — разве что вы начнете делать какие-то кастомные расширения).
Для начала, чтобы у нас было единое понимание того, что происходит, позволю себе небольшое описание процесса (см. картинку):
0. Пользователь вводит свои UserName и Password (U/P)
1. Клиент пытается подключиться к WCF Service используя переданные ему U/P. Однако, инфраструктура WCF, анализирует указанные ей настройки и выясняет, что от нее требуется работать по Federation протоколу, а это значит, что вместо прямого обращения WCF Service, она формирует специальный Security Token Request (STR), который отсылает на STS. При этом в качестве credentials в SRT используются наши U/P.
2. STS получает STR и первым делом анализирует credentials (надо сказать, что в общем случае это не обязательно должны быть именно UserName/Password, а любой допустимый способ аутентификации Windows, Certificate, … — вплоть до полученного ранее сертификата! Но мы рассматриваем простейший случай).
Получив и аутентифицировав STR, наш STS начинает его анализировать и обрабатывать.
Делает он это следующим образом:
смотрит, для какого именно сервера будет выдаваться токен (в терминологии WIF такой сервер-получатель токена называется Relying Party, RP). Если в списке его доверенных такого сервера то формируется ошибка и токен не выдается
извлекает из своей базы данные пользователя (пользователя он берет из переданных credentials)
генерирует ключи симметричного шифрования для клиента и сервера — этими ключами будет защищаться канал/сессия между клиентом и RP
формирует токен, для RP (состоящий из данных пользователя и ключа шифрования), подписывает его своим закрытым ключом и шифрует открытым ключом RP.
затем, зашифрованный пакет вкладывает в еще один пакет, предназначенный уже для клиента (там могут быть те же данные, но обычно там только шифрования для клиента). Этот пакет тоже подписывается
результат возвращается клиенту (Security Token Response, STRes)
3. Клиент, получивший STRes проверяет подпись STS, достает свои данные и зашифрованный пакет для RP и уже с этим пакетом делает запрос на установление соединения с WCF Service
4. WCF Service получает запрос, достает оттуда зашифрованный пакет, расшифровывает его своим закрытым ключом и проверяет подпись STS. Если все в порядке, то устанавливается сессия с клиентом, а данные из токена используются как данные аутентифицированного пользователя.
Примерно так выглядит общий процесс (я тоже владею далеко не всем предметом в совершенстве, так что местами мог слегка и наврать).
Если мы его внимательно просмотрим, то получится, что для успешного решения нам желательно выполнить следующее:
Создать и правильно прописать SSL сертификаты для STS и WCF Service (если они на разных машинах, если на одной — хватит и одного).
Создать и положить в хранилище сертификат для подписания. Thinktecture IdentityServer по умолчанию берет такие сертификаты из Local Machine / My, поэтому кладем туда. Обратите внимание, что для сертификата надо дать права на доступ к закрытым ключам ученой записи под которой запущен STS (самое простое — дать права IIS_IUSRS, хотя это и не совсем правильно)
Аналогично создать и положить в хранилище сертификат для шифрования. Только теперь это нужно сделать на машине WCF Service + на базе этого сертификата сделать файл сертификата только с открытым ключом (.cer)
Теперь перейдем к настройке STS.
Тут нужно не забыть сделать следующее:
Имхо, в разделе "General Configuration" лучше снять галочку "Only Users in the 'IdentityServerUsers' role can request tokens:" (иначе всех пользователей придется добавлять в эту группу)
В разделе "Key Configuration" указать наш сертификат для подписи в Signing Certificate
В Разделе Protocols, проверьте, что включен WS-Trust (нам нужен только он), а затем зайдите в сами настройки WS-Trust и проверьте что стоит галочка "Enable Mixed Mode Security Endpoints" (это так ребята обозначают возможность аутентификации по User/Password на STS
В разделе "Relying Parties & Resources" создать новую запись об RP. Обратите внимание, здесь в качестве Encrypting Certificate нужно указать тот самый .cer который мы создали ранее на основе сертификата шифрования для WCF Service. В качестве Realm указывайте адрес сервиса в том виде, как он указывается в настройках WCF.
Ну и конечно, создать пользователя, которого мы будем аутентифицировать.
Все, на этом настройки STS закончены.
Однако, прежде чем перейти к настройкам WSF Service, сделаем следующее: выйдем на страницу Home (она в корне нашего STS или можно через закладки), а оттуда на Application integration. На этой странице есть 2 важных для нас адреса: "WS-Trust metadata" и "WS-Trust mixed mode security (user name)" — сами мы будем использовать только 1-ый, а второй чисто для проверки, что все метаданные верно подхватились.
Переходим к нашему WCF Service!
Здесь все делается в настройке, поэтому я просто приведу config с комментариями:
<?xml version="1.0"?>
<configuration>
<configSections>
<!-- Обязательно указать эту секцию!!! Почему ее нет по умолчанию в machine.confug - ума не приложу -->
<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</configSections>
<system.serviceModel>
<bindings>
<ws2007FederationHttpBinding>
<binding name="Default">
<!-- Мы используем TransportWithMessageCredential безопасность, чтобы не заморачиваться с настройками,
так как SSL мы уже настроили.
В качестве issuerMetadata нужно указать адрес, который содержится на странице Application integration
и называется "WS-Trust metadata"
-->
<security mode="TransportWithMessageCredential">
<message>
<issuerMetadata address="https://мой_STS/IdSrv/issue/wstrust/mex" />
</message>
</security>
</binding>
</ws2007FederationHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior>
<!-- Это чтобы не возиться с настройкой клиента... -->
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
<!-- Здесь мы указываем, что в pipeline WCF будет работать WIF, конфигурация которой (DefaultIConf) описывается ниже-->
<serviceCredentials identityConfiguration="DefaultIConf" useIdentityConfiguration="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<!-- Ну и сам сервис. Т.к. хостим под IIS, адрес не указываем, binding и contract - обязательно -->
<service name="WcfService.Service">
<endpoint binding="ws2007FederationHttpBinding" bindingConfiguration="Default" contract="WcfService.Service" />
</service>
</services>
</system.serviceModel>
<!-- Здесь указываются все настройки WIF, т.е., собственно, все настройки обработки токенов -->
<system.identityModel>
<!-- Это требование MS в WIF - создавать и использовать отдельные конфигурации -->
<identityConfiguration name="DefaultIConf">
<securityTokenHandlers>
<securityTokenHandlerConfiguration>
<!-- Здесь мы указываем, что не будем проверять какому именно серверу предназначен пришедший токен
если все же хочется проверять, то нужно будет добавить к узлу audienceUris дочерний.
Что-то типа <add value="https://мой_хост/WcfService/Service.svc"/> - главное следить, чтобы он совпадал
с тем, что указано в поле Realm/Scope Name на STS
-->
<audienceUris mode="Never" />
<!-- Здесь указывается класс, который будет для пришедшего токена искать закрытый ключ для расшифровки.
К сожалению, я не нашел как для этого параметра указать настройку (т.е. в каком хранилище искать сертификаты)
это можно сделать, если задавть настройку программно (например, делать свой наследник текущего класса и там
в конструкторе заполнять нужные параметры, а здесь указывать наш класс).
Однако по умолчанию этот класс ищет сертификаты в Local Machine / My так что просто положим его туда
-->
<serviceTokenResolver
type="System.IdentityModel.Tokens.X509CertificateStoreTokenResolver, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<!-- Этот тэг задает список доверенных STS, т.е. тех от которых мы готовы получать токены.
Опознаем мы их довольно просто - по thumbprint сертификата, которым они ставят подпись
Информация о сертификате подписи добавляется в саму подпись, поэтому ничего регистрировать
дополнительно не надо, надо только указать строку thumbprint (имя произвольное)
-->
<issuerNameRegistry>
<trustedIssuers>
<add name="STS" thumbprint="9B14A55B4A435YYY8C88D14779F57193905C2"/>
</trustedIssuers>
</issuerNameRegistry>
</securityTokenHandlerConfiguration>
</securityTokenHandlers>
</identityConfiguration>
</system.identityModel>
</configuration>
Теперь переходим к клиенту.
Здесь тоже ничего специально делать не надо, просто создать ServiceReference для нашего WCF Service.
После создания перепроверьте, что все настройки соединений подхватились правильно.
Я привожу свой с комментариями, на что обратить внимание.
<?xml version="1.0"encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<!-- !!! Должно быть 2 биндинга: ws2007FederationHttpBinding и ws2007HttpBinding !!! -->
<ws2007FederationHttpBinding>
<binding name="WS2007FederationHttpBinding_Service">
<security mode="TransportWithMessageCredential">
<message>
<!-- !!! Обратите внимание на адрес. Он должен совпадать с "WS-Trust mixed mode security (user name)"
на странице Application integration !!!
-->
<issuer address="https://мой_STS/IdSrv/issue/wstrust/mixed/username"
binding="ws2007HttpBinding" bindingConfiguration="https://мой_STS/IdSrv/issue/wstrust/mixed/username" />
<issuerMetadata address="https://мой_STS/IdSrv/issue/wstrust/mex" />
<tokenRequestParameters>
<trust:SecondaryParameters xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<!-- Тут я выпущу кусок -->
</trust:SecondaryParameters>
</tokenRequestParameters>
</message>
</security>
</binding>
</ws2007FederationHttpBinding>
<ws2007HttpBinding>
<!-- !!! Модель безопасности должна быть TransportWithMessageCredential
а clientCredentialType должен стоять в UserName !!! -->
<binding name="https://мой_STS/IdSrv/issue/wstrust/mixed/username">
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" />
<message clientCredentialType="UserName" establishSecurityContext="false" />
</security>
</binding>
</ws2007HttpBinding>
</bindings>
<client>
<!-- Ну а тут просто адрес наших WCF Service и указание биндинга с контрактом -->
<endpoint address="https://мой_WCF_Service/WcfService/Service.svc"
binding="ws2007FederationHttpBinding" bindingConfiguration="WS2007FederationHttpBinding_Service"
contract="ServiceReference.Service"name="WS2007FederationHttpBinding_Service" />
</client>
</system.serviceModel>
</configuration>
Ну все, настройка закончена
Теперь пишем пробный код клиента
(создаем proxy и указываем User/Password в качестве credentials)
using (var client = new ServiceReference.ServiceClient())
{
client.ClientCredentials.UserName.UserName = "User1";
client.ClientCredentials.UserName.Password = "123456";
Console.WriteLine(client.GetData());
}
Ну и осталось привести код сервиса
Там ничего сложного, просто показываю как добраться до переданных Claims. В отличие от WIF 3.5, WIF 4.5 не меняет Principal текущего потока (хотя может где-то и есть такая опция), а предлагает как и в целом в WCF все получать через OperationContext
namespace WcfService
{
[ServiceContract]
public class Service
{
[OperationContract]
public string GetData()
{
var princinpal = OperationContext.Current.ClaimsPrincipal;
var name = princinpal.Identity.Name;
var email = princinpal.FindFirst(ClaimTypes.Email);
var webPage = princinpal.FindFirst(ClaimTypes.Webpage);
return string.Format("User: {0}, mail: {1}, web page: {2}", name,
email == null ? "" : email.Value,
webPage == null ? "" : webPage.Value);
}
}
}
Надеюсь, все получилось достаточно доходчиво.
Если останутся вопросы — спрашивайте без смущения (если я не буду долго отвечать — спросите в личку, я не постоянно читаю RSDN, а так должно прийти уведомление).
По поводу второго варианта (отдельное получение токена и затем вручную добавление его в вызовы сервисов в качестве Credentials) — он тоже должен быть возможен (мы именно так и работаем), но с ходу накидать пример на WCF/WIF 4.5 я не смогу, а больше пока времени на исследования, увы, не осталось.
Здравствуйте, WSA, Вы писали:
WSA>Сейчас бум курить...
Потом отпишите о результатах, по возможности.
Я постараюсь в течение недели выделить время и сделать еще один пример — с явным получением токена и дальнешей работой через него. Но обещать не буду — времени не хватает ни на что, как обычно.
Проект с сервисом создаю по шаблону VS2012: WCF Service Application.
После редактирования конфига с данными, приведёнными в статье для WCF сервиса и попытки обратиться к сервису через браузер, возникает ошибка
"Could not find a base address that matches scheme https for the endpoint with binding WS2007FederationHttpBinding. Registered base address schemes are [http]."
Здравствуйте, WSA, Вы писали:
WSA>Что я делаю не так?
Обычно такая ошибка возникает, когда ост сервиса не может найти https среди доступных ему биндингов сайта (не биндингов WCF, а биндингов IIS-сайта!!!).
На сколько я помню, по умолчанию проект WCF Application хостится под IIS Express, у которого по умолчанию же SSL не настроен.
К сожалению, при всей удобстве работы с IIS Express, в данном конкретном случае я рекомендую переключиться на полноценный IIS — как минимум там проще и нагляднее настраивать SSL.
МР>К сожалению, при всей удобстве работы с IIS Express, в данном конкретном случае я рекомендую переключиться на полноценный IIS — как минимум там проще и нагляднее настраивать SSL.
К сожалению в моём случае не получится перейти на IIS, т.к. используются self-hosted WCF — сервисы, которые крутятся в windows — службе.
В данном контекстк, видимо нужно будет укказать более явно адрес конечной точки... А сертификат руками привязать к порту?
Разница только в том, что: а) токенов мы получаем несколько — в них разная информация для разных случаев, у нас Web, а не Desktop клиент (поэтому часть токенов мы получаем по HttpRedirect, а что-то по SOAP).
