Windows Identity Foundation — для ASP.NET MVC проектов
В этой статье, хотелось бы рассказать о том, как можно использовать Windows Identity Foundation в своих ASP.NET MVC проектах, и написать свой Identity Server, на WIF платформе. Во первых, потому что, общей информации, в интернете, достаточно, а вот когда дело касается конкретики, тут возникают проблемы. Так как идеологию и частные случаи можно ещё найти, а вот когда дело касается конкретики, приходится собирать по крупицам. И во вторых, то что сейчас предлагает Microsoft, используя надстройки над Visual Studio, не совсем годится, я бы даже сказал, совсем не годится при разработке решений, сложнее домашней странички или сайта — визитки. Кроме всего прочего, я не очень люблю, когда мифический мастер настройки что сделал с солюшеном, и сказал что «вроде должно работать».
В качестве примера, создадим, и настроим, самый примитивный клиент, который будет авторизоваться через самый примитивный сервер авторизации (Identity Server) работающий по WS-Federation протоколу.
Для того, что бы определиться, в каких же случаях имеет смысл «городить огород» со своим сервером авторизации, достаточно посмотреть как же он работает. Итак, мы хотим предоставлять клиенту несколько сервисов, например несколько сайтов, например с WCF сервисами, и допустим REST API. Согласитесь, что пользователю будет достаточно дискомфортно отдельно авторизоваться на каждом из наших сайтов, при переходе с одного на другой. Тут достаточно простая идея, которая заключается в том, что пользователю, при авторизации на одном из сервисов (ресурсов), выдаётся некий Token. А в дальнейшем, другой, или тот же, сервис (ресурс) уже доверяет авторизированному пользователю, на основе существования у клиента этого самого токена, ну и так далее…
Просто для наглядности понимания, приведу понравившееся сравнение (к сожалению ссылки на нашел). Например человек получает паспорт, после некой процедуры проверки, а в дальнейшем, предоставляя свой паспорт, человеку доверяют, на основе наличия у него паспорта. В данном сравнении, паспорт человека, и есть токен клиента.
Сразу же можно сделать вывод, что зачастую, бессмысленно выдавать «паспорт», если он будет проверяться только в одном месте.
Конечно же, у токена, как и у паспорта, есть время жизни, и точно так же, токен может быть пересоздан, на основе устаревшего. И по аналогии, как и паспорт, токен может быть разным, т.е. представлять из себя практически всё что угодно, или это заголовок реквеста, или base64 строка, как например JWT Token (JSON Web Token). А по факту, сам токен содержит информацию о себе (время когда он был создан последний раз, публичный ключ сертификата, и т.п.), а так же список клеймов, содержащих информацию о клиенте. Для описания токена, мы будем использовать язык SAML (Security Assertion Markup Language).
Ещё одно важное понятие, — это клеймы (Claims). Клеймы входят в состав нашего токена, и несут информацию о клиенте в целом. Фактически — это словарь, состоящий из пары Key/Value, в котором Key — namespace описывающий тип поля Value, а само по себе поле Value — это простая строка. В .Net это представлено типизированным списком:
Существует целый ряд, зарегистрированных неймспейсов, которых более чем хватает для того что бы описать профиль клиента, от списка ролей, до аватарки. При желании мы можем создавать свои пространства имён, единственное о чём нужно помнить, что сам объект Claim, должен сериализоваться.
Отсюда можно сделать пожалуй два основных вывода, первый — это что для просто авторизации пользователя, на сайте, использовать Identity Server, просто неоправданно, и второй — что поскольку мы собираемся передавать токен, между различными ресурсами, нам понадобится безопасность транспорта, в первую очередь. И так приступим, и начнём пожалуй с настройки транспорта, поскольку если у нас не будет trusted транспорта, ничего работать просто не сможет, а для этого, в первую очередь, нам понадобится сертификат.
Создание сертификата
Вот примерно с этого момента, у многих разработчиков, начинаются вопросы, по поводу создания сертификата, настройки HTTPS на сервере, и так далее. Для работы и отладки, нам понадобится сам IIS установленный локально, простое ASP.NET MVC приложение, которое будет нашим клиентским сайтом, и доверенный сертификат. Нам нужен не просто сертификат, а сертификат выданный на какое либо доменное имя, покупать его, для тестовых целей — экономически не выгодно, поэтому мы сделаем его сами.
Например, имя домена, который мы будем использовать в тестовых целях будет identity.com. Сначала, для создания сертификата воспользуемся утилитой makecert.
В результате выполнения мы получим два файла identity.com.pvk и identity.com.cer.Тут все предельно понятно, да и информации по утилите makecert более чем достаточно. Единственный момент, на котором хотелось бы остановиться по подробнее, так это на CN на который мы выдаём сертификат. Если выдать сертификат просто на identity.com, то нам, в дальнейшем, будет неудобно локально моделировать ситуацию с распределёнными ресурсами, а вот использование *, значительно упрощает нашу задачу т.е. *.identity.com. Использование *, даёт нам возможность локально создавать произвольное количество доменов вида «any name».identity.com.
Далее, для проверки сертификата издателя, воспользуемся утилитой cert2spc.
И в результате, получим файл identity.com.spc, который нам понадобится для утилиты pvk2pfx. С помощью которой мы сгенерируем необходимый нам pfx файл.
В результате, мы получили identity.com.pfx файл, содержащий private ключ, с паролем qwerty. Осталось его зарегистрировать IIS и в системе.
Настройка HTTPS
Для того что бы, наш IIS сервер начал работать с нашим сертификатом, во первых, нам нужно импортировать наш pfx файл, в Trusted Root Certification Authorities зону через оснастку MMC, и выполнить Import в самом IIS сервере, в разделе Server Certificates.
Теперь всё готово к настройке нашего клиентского сайта. Для этого создадим новый сайт в IIS, с именем client.identity (в прочем, без разницы с каким), главное что бы App Pool нашего сайта работал под .Net 4.0 (это если сайт скомпилирован под .Net 4.0, 4.5). И указываем Physical path, на директорию нашего клиентского сайта. 
Далее, настраиваем наш HTTPS, в разделе Binding. После выбора https в поле type, нам необходимо выбрать наш сгенерированный сертификат, и только после этого нам становится доступно для редактирования поле Host name. Если сертификат мы сгенерировали с «*«, то мы можем указывать практически любое имя нашего сайта, главное сто бы оно заканчивалось на identity.com, т.е. имя нашего тестового домена. В дальнейшем мы можем изменить наши биндинги в разделе Bindings, нашего сайта. Остался только последний «штрих», так это изменить hosts файл, по пути (c:\Windows\System32\drivers\etc\) и добавить туда строку с именем биндинга нашего сайта:
Всё, можно проверять работу локального https, просто по адресу: client.identity.com. 
В результате, мы должны увидеть наше web приложение, а в адресной строке, то что наш сертификат, является доверенным, т.е. никаких предупреждений браузера.
Если Вы скачаете IdentityTrainingKitVS2010 с сайта Microsoft, то можно немного облегчить себе жизнь, выполнив SetupCertificates.cmd, например по пути IdentityTrainingKitVS2010\Labs\MembershipAndFederation\Source\Setup\Scripts\SetupCertificates.cmd
Этот скрипт сделает практически тоже самое, только для уже готового сертификата из примеров localhost.pfx (у него пароль xyz). Соответственно обращение к сайту (например Default Web Site), будут работать через localhost, а все ваши приложения которые должны работать через https, должны быть созданы ни как, Web Site, а как Web Application, под localhost сайтом.
Настройка клиентского приложения
Теперь надо произвести некоторую настройку нашего клиентского приложения. Для начала, в настройках проекта, установим адрес нашего сайта для поля Custom Web Server. 
Это даст Visual Studio возможность, при запуске, автоматически делать Attach to Process к w3wp.exe процессу (процесс сайта IIS).
Теперь, нам надо разобраться с референсами нашего сайта, и добавить две сборки из GAC, System.IdentityModel.dll и System.IdentityModel.Services.dll. А так же удалить лишнее, то что нам будет мешать — это NUget пакеты DotNetOpenAuth, они нам не понадобятся, а будут только мешать, а для этого, необходимо удалить пакет Microsoft.AspNet.WebPages.OAuth. Если, по каким либо причинам, Вы не хотите их трогать, то как опциональный вариант, — это настройка регистрации в web.config.
И последним шагом, в настройке клиентского приложения — это настройка самого web.config. Во первых, в разделе sysytem.web, установить метод authentication в none.
Далее регистрируем наши секцию, для Identity Model в разделе configSections:
Добавляем и настраиваем эти секции, сначала system.identityModel:
Для начала, в секции audienceUris, добавляем адрес нашего клиенского сайта, далее добавляем запись в секциию trustedIssuers, где thumbprint это значение Thumbprint из нашего сгенерированного файла identity.crt, или другого сертификата транспорта, по которому будет работать сервер. 
Только без пробелов. А поле name — это и есть адрес нашего бедующего сервера, например, в нашем случае server.identity.com + /issue/wsfed. Использовать именно wsfed не обязательно, оссобенно в нашем случае бедующего сервера — это может быть что угодно. Просто wsfed — это сокращение от WS-Federation.
Далее добавляем секцию system.identityModel.services:
Тут всё достаточно просто, iisuer — это наш сервер из секции выше, а reply — это адрес куда, в дальнейшем отвечать серверу.
Осталось зарегистрировать модули, в разделе system.webServer.
Всё, можно проверять работу нашего клиента, достаточно попробовать с View вызвать любой метод или метод контроллера помеченного атрибутом Authorize.
После запуска приложения (по F5), и попытке пользователем вызвать наш метод, мы увидим GET запрос по адресу нашего бедующего сервера:
Это запрос на авторизацию, от клиента серверу, по адресу server.identity.com/issue/wsfed.
Описанного выше, вполне хватает, для минимальной настройки клиентского приложения, работающего с WIF Identity Server, даже если Вы используете сервер сторонних разработчиков, главное что бы сервер поддерживал WS-Federation.
Создание сервера
Перед началом создания Identity сервера, надо обязательно упомянуть о такой вещи как STS (Security Token Service). Фактически — это сервис, и не важно на каком языке и платформе он написан. А наш ASP.NET MVC Identity Server — это по сути UI оболочка. Для создания своего STS, поскольку мы всё таки используем .Net, то нам будет удобно воспользоваться уже теми инструментами которые есть в платформе.
Наш Identity Server, так же как и клиент, по сути представляет собой, ASP.NET MVC приложение, для которого тоже необходимо настроить HTTPS, и, в нашем случае, назначим ему биндинг server.identity.com, используя все тот же, сгенерированный нами сертификат.
Создадим SignIn View для SignIn метода контроллера Account, и добавим в web.config запись:
И добавим в роуты, запись для метода контроллера, который будет выполняться при обращении по пути issue/wsfed.
Именно по этому пути обращается наш клиент <>/issue/wsfed. Если мы контроллер, пометим атрибутом Authorizе, то клиентское приложение, при попытке выполнить вход, в систему, будет попадать сначала на метод SignIn, контроллера Account, который в свою очередь будет возвращать View, с логин формой нашего сервера.
Далее пользователь вводит данные, необходимые для входа (например логин пароль), и попадает на метод Issue. Обратите внимание, что RequestString при этом не меняется, а остаётся таким же, с которым обратилось клиентское приложение.
Для того что бы наш сервер понимал, что же именно клиент от него хочет, разберём аргументы запроса:
Соответственно метод WSFederationMessage.CreateFromUri, возвращает инстанцию наследников абстрактного класса WSFederationMessage. Далее выполняем действия, или входа в систему, или выхода.
При выполнении входа в систему по WS-Federation протоколу, выполняем статический метод:
Этот метод, на основе полученной инстанции класса SignInRequestMessage, и списка клеймов (Claims), сформирует некий объект RequestSecurityToken, который по сути и является нашим токеном клиента, и отдаст его на метод GetScope нашего STS сервиса. Для создания нашего STS сервиса, унаследуемся от абстрактного класса SecurityTokenService:
и перекроем метод GetScope:
именно в этом методе будет происходить анализ или заполнение объекта RequestSecurityToken.Т.е. непосредственно само формирование, и проверка токена клиента. Всю проверку я просто не вижу смысла описывать, так как проще всего по методу пройтись дебагом, так как в методе нет ничего не тривиального.
В принципе, вышеописанного в самом своём минимуме достаточно, для того что бы получить примитивный Identity Server, через который клиент может авторизоваться.
Если будет интересно, как это всё работает, я «склеил» упрощённый клиент и сервер, на с github.
Это просто облегченная версия сервера https://github.com/thinktecture/Thinktecture.IdentityServer.v2, собранная пока что, на данный момент, в целях демонстрации и не более того, и конечно не выдерживает никакой критики.
В заключение
Что хотелось бы, лично мне получить в результате, так это полноценный Identity Server, в который вынесена вся работа с профилем пользователя т.е. логин, регистрация, соцсети, просмотр своего профиля и т.д. Соответственно с должным уровнем security. Но по факту, что бы сам сервер можно было бы подключить к разрабатываемому ресурсу, и каждый раз не тратить на время на систему авторизации. Ну и конечно же, хотелось бы, интегрировать работу сервера, с WCF и REST сервисами, с распределением доступа к методам по ролям клиента. Но это пока только в планах.
Microsoft identity extensions что это
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлой статье мы подробно рассмотрели вопрос по решению ошибки STOP 0x00000050 сопровождающейся синим экранов Windows. Сегодня я хочу вас научить, как обойти ошибку установки Windows Identity Foundation в Windows Server 2012 R2 и Windows 8.1, ошибка имеет код 0x80096002 (Недопустимый сертификат лица, подписавшего сообщение или сертификат не найден).
Описание проблемы
У меня есть RDS ферма, состоящая из хостов Windows Server 2012 R2. В данную RDS ферму был добавлен новый хост подключений. Пользователь запустил на нем определенный софт, где сразу выскочила ошибка:
Установка Windows Identity Foundation
Когда вы начнете искать, что такое компонент Windows Identity Foundation, то вас приведет на ветку обсуждения, где попросят установить в вашу Windows 8.1 или Windows Server 2012 R2 обновление Windows6.1-KB974405-x64 (https://www.microsoft.com/ru-ru/download/details.aspx?id=17331. Скачав его и попытавшись запустить я получил ошибку:
Я не стал вдаваться в ситуацию, что за сертификат и чем подписан данный пакет, мне нужно было найти решение. В Windows Server 2012 R2 компонент Windows Identity Foundation устанавливается как фича. Вы запускаете PowerShell, и пишите:
В итоге вам покажут, что для установки доступен пакет «Windows Identity Foundation 3.5». Установим его командой:
Начнется установка пакета.
Проверяем установленный пакет Windows Identity Foundation 3.5, у него теперь статус «Installed».
Пробуем теперь запустить ваше приложение, ошибка «Не удалось загрузить файл или сборку Microsoft IdentityModel, Version=3.5.0.0» должна исправиться.
Так же проинсталлировать Windows Identity Foundation вы можете и через графический интерфейс, для этого откройте оснастку диспетчера серверов и выберите пункт «Добавить роли и компоненты».
Доходим до окна с выбором компонентов, где выставляем галку Windows Identity Foundation 3.5, после чего производим установку.
Если нужно установить компонент WID 3.5 в Windows 8.1, то откройте панель управления и выберите раздел «Программы и компоненты»
Перейдите в раздел «Включение или отключение компонентов Windows»
Установите галку Windows Identity Foundation 3.5 и нажмите «Ok», компонент будет добавлен в вашу операционную систему.
Windows Identity Foundation — для ASP.NET MVC проектов
В этой статье, хотелось бы рассказать о том, как можно использовать Windows Identity Foundation в своих ASP.NET MVC проектах, и написать свой Identity Server, на WIF платформе. Во первых, потому что, общей информации, в интернете, достаточно, а вот когда дело касается конкретики, тут возникают проблемы. Так как идеологию и частные случаи можно ещё найти, а вот когда дело касается конкретики, приходится собирать по крупицам. И во вторых, то что сейчас предлагает Microsoft, используя надстройки над Visual Studio, не совсем годится, я бы даже сказал, совсем не годится при разработке решений, сложнее домашней странички или сайта — визитки. Кроме всего прочего, я не очень люблю, когда мифический мастер настройки что сделал с солюшеном, и сказал что «вроде должно работать».
В качестве примера, создадим, и настроим, самый примитивный клиент, который будет авторизоваться через самый примитивный сервер авторизации (Identity Server) работающий по WS-Federation протоколу.
Для того, что бы определиться, в каких же случаях имеет смысл «городить огород» со своим сервером авторизации, достаточно посмотреть как же он работает. Итак, мы хотим предоставлять клиенту несколько сервисов, например несколько сайтов, например с WCF сервисами, и допустим REST API. Согласитесь, что пользователю будет достаточно дискомфортно отдельно авторизоваться на каждом из наших сайтов, при переходе с одного на другой. Тут достаточно простая идея, которая заключается в том, что пользователю, при авторизации на одном из сервисов (ресурсов), выдаётся некий Token. А в дальнейшем, другой, или тот же, сервис (ресурс) уже доверяет авторизированному пользователю, на основе существования у клиента этого самого токена, ну и так далее…
Просто для наглядности понимания, приведу понравившееся сравнение (к сожалению ссылки на нашел). Например человек получает паспорт, после некой процедуры проверки, а в дальнейшем, предоставляя свой паспорт, человеку доверяют, на основе наличия у него паспорта. В данном сравнении, паспорт человека, и есть токен клиента.
Сразу же можно сделать вывод, что зачастую, бессмысленно выдавать «паспорт», если он будет проверяться только в одном месте.
Конечно же, у токена, как и у паспорта, есть время жизни, и точно так же, токен может быть пересоздан, на основе устаревшего. И по аналогии, как и паспорт, токен может быть разным, т.е. представлять из себя практически всё что угодно, или это заголовок реквеста, или base64 строка, как например JWT Token (JSON Web Token). А по факту, сам токен содержит информацию о себе (время когда он был создан последний раз, публичный ключ сертификата, и т.п.), а так же список клеймов, содержащих информацию о клиенте. Для описания токена, мы будем использовать язык SAML (Security Assertion Markup Language).
Ещё одно важное понятие, — это клеймы (Claims). Клеймы входят в состав нашего токена, и несут информацию о клиенте в целом. Фактически — это словарь, состоящий из пары Key/Value, в котором Key — namespace описывающий тип поля Value, а само по себе поле Value — это простая строка. В .Net это представлено типизированным списком:
Существует целый ряд, зарегистрированных неймспейсов, которых более чем хватает для того что бы описать профиль клиента, от списка ролей, до аватарки. При желании мы можем создавать свои пространства имён, единственное о чём нужно помнить, что сам объект Claim, должен сериализоваться.
Отсюда можно сделать пожалуй два основных вывода, первый — это что для просто авторизации пользователя, на сайте, использовать Identity Server, просто неоправданно, и второй — что поскольку мы собираемся передавать токен, между различными ресурсами, нам понадобится безопасность транспорта, в первую очередь. И так приступим, и начнём пожалуй с настройки транспорта, поскольку если у нас не будет trusted транспорта, ничего работать просто не сможет, а для этого, в первую очередь, нам понадобится сертификат.
Создание сертификата
Вот примерно с этого момента, у многих разработчиков, начинаются вопросы, по поводу создания сертификата, настройки HTTPS на сервере, и так далее. Для работы и отладки, нам понадобится сам IIS установленный локально, простое ASP.NET MVC приложение, которое будет нашим клиентским сайтом, и доверенный сертификат. Нам нужен не просто сертификат, а сертификат выданный на какое либо доменное имя, покупать его, для тестовых целей — экономически не выгодно, поэтому мы сделаем его сами.
Например, имя домена, который мы будем использовать в тестовых целях будет identity.com. Сначала, для создания сертификата воспользуемся утилитой makecert.
В результате выполнения мы получим два файла identity.com.pvk и identity.com.cer.Тут все предельно понятно, да и информации по утилите makecert более чем достаточно. Единственный момент, на котором хотелось бы остановиться по подробнее, так это на CN на который мы выдаём сертификат. Если выдать сертификат просто на identity.com, то нам, в дальнейшем, будет неудобно локально моделировать ситуацию с распределёнными ресурсами, а вот использование *, значительно упрощает нашу задачу т.е. *.identity.com. Использование *, даёт нам возможность локально создавать произвольное количество доменов вида «any name».identity.com.
Далее, для проверки сертификата издателя, воспользуемся утилитой cert2spc.
И в результате, получим файл identity.com.spc, который нам понадобится для утилиты pvk2pfx. С помощью которой мы сгенерируем необходимый нам pfx файл.
В результате, мы получили identity.com.pfx файл, содержащий private ключ, с паролем qwerty. Осталось его зарегистрировать IIS и в системе.
Настройка HTTPS
Для того что бы, наш IIS сервер начал работать с нашим сертификатом, во первых, нам нужно импортировать наш pfx файл, в Trusted Root Certification Authorities зону через оснастку MMC, и выполнить Import в самом IIS сервере, в разделе Server Certificates.
Теперь всё готово к настройке нашего клиентского сайта. Для этого создадим новый сайт в IIS, с именем client.identity (в прочем, без разницы с каким), главное что бы App Pool нашего сайта работал под .Net 4.0 (это если сайт скомпилирован под .Net 4.0, 4.5). И указываем Physical path, на директорию нашего клиентского сайта.
Далее, настраиваем наш HTTPS, в разделе Binding. После выбора https в поле type, нам необходимо выбрать наш сгенерированный сертификат, и только после этого нам становится доступно для редактирования поле Host name. Если сертификат мы сгенерировали с «*«, то мы можем указывать практически любое имя нашего сайта, главное сто бы оно заканчивалось на identity.com, т.е. имя нашего тестового домена. В дальнейшем мы можем изменить наши биндинги в разделе Bindings, нашего сайта. Остался только последний «штрих», так это изменить hosts файл, по пути (c:\Windows\System32\drivers\etc\) и добавить туда строку с именем биндинга нашего сайта:
Всё, можно проверять работу локального https, просто по адресу: client.identity.com.
В результате, мы должны увидеть наше web приложение, а в адресной строке, то что наш сертификат, является доверенным, т.е. никаких предупреждений браузера.
Если Вы скачаете IdentityTrainingKitVS2010 с сайта Microsoft, то можно немного облегчить себе жизнь, выполнив SetupCertificates.cmd, например по пути IdentityTrainingKitVS2010\Labs\MembershipAndFederation\Source\Setup\Scripts\SetupCertificates.cmd
Этот скрипт сделает практически тоже самое, только для уже готового сертификата из примеров localhost.pfx (у него пароль xyz). Соответственно обращение к сайту (например Default Web Site), будут работать через localhost, а все ваши приложения которые должны работать через https, должны быть созданы ни как, Web Site, а как Web Application, под localhost сайтом.
Настройка клиентского приложения
Теперь надо произвести некоторую настройку нашего клиентского приложения. Для начала, в настройках проекта, установим адрес нашего сайта для поля Custom Web Server.
Это даст Visual Studio возможность, при запуске, автоматически делать Attach to Process к w3wp.exe процессу (процесс сайта IIS).
Теперь, нам надо разобраться с референсами нашего сайта, и добавить две сборки из GAC, System.IdentityModel.dll и System.IdentityModel.Services.dll. А так же удалить лишнее, то что нам будет мешать — это NUget пакеты DotNetOpenAuth, они нам не понадобятся, а будут только мешать, а для этого, необходимо удалить пакет Microsoft.AspNet.WebPages.OAuth. Если, по каким либо причинам, Вы не хотите их трогать, то как опциональный вариант, — это настройка регистрации в web.config.
И последним шагом, в настройке клиентского приложения — это настройка самого web.config. Во первых, в разделе sysytem.web, установить метод authentication в none.
Далее регистрируем наши секцию, для Identity Model в разделе configSections:
Добавляем и настраиваем эти секции, сначала system.identityModel:
Для начала, в секции audienceUris, добавляем адрес нашего клиенского сайта, далее добавляем запись в секциию trustedIssuers, где thumbprint это значение Thumbprint из нашего сгенерированного файла identity.crt, или другого сертификата транспорта, по которому будет работать сервер.
Только без пробелов. А поле name — это и есть адрес нашего бедующего сервера, например, в нашем случае server.identity.com + /issue/wsfed. Использовать именно wsfed не обязательно, оссобенно в нашем случае бедующего сервера — это может быть что угодно. Просто wsfed — это сокращение от WS-Federation.
Далее добавляем секцию system.identityModel.services:
Тут всё достаточно просто, iisuer — это наш сервер из секции выше, а reply — это адрес куда, в дальнейшем отвечать серверу.
Осталось зарегистрировать модули, в разделе system.webServer.
Всё, можно проверять работу нашего клиента, достаточно попробовать с View вызвать любой метод или метод контроллера помеченного атрибутом Authorize.
После запуска приложения (по F5), и попытке пользователем вызвать наш метод, мы увидим GET запрос по адресу нашего бедующего сервера:
Это запрос на авторизацию, от клиента серверу, по адресу server.identity.com/issue/wsfed.
Описанного выше, вполне хватает, для минимальной настройки клиентского приложения, работающего с WIF Identity Server, даже если Вы используете сервер сторонних разработчиков, главное что бы сервер поддерживал WS-Federation.
Создание сервера
Перед началом создания Identity сервера, надо обязательно упомянуть о такой вещи как STS (Security Token Service). Фактически — это сервис, и не важно на каком языке и платформе он написан. А наш ASP.NET MVC Identity Server — это по сути UI оболочка. Для создания своего STS, поскольку мы всё таки используем .Net, то нам будет удобно воспользоваться уже теми инструментами которые есть в платформе.
Наш Identity Server, так же как и клиент, по сути представляет собой, ASP.NET MVC приложение, для которого тоже необходимо настроить HTTPS, и, в нашем случае, назначим ему биндинг server.identity.com, используя все тот же, сгенерированный нами сертификат.
Создадим SignIn View для SignIn метода контроллера Account, и добавим в web.config запись:
И добавим в роуты, запись для метода контроллера, который будет выполняться при обращении по пути issue/wsfed.
Именно по этому пути обращается наш клиент <>/issue/wsfed. Если мы контроллер, пометим атрибутом Authorizе, то клиентское приложение, при попытке выполнить вход, в систему, будет попадать сначала на метод SignIn, контроллера Account, который в свою очередь будет возвращать View, с логин формой нашего сервера.
Далее пользователь вводит данные, необходимые для входа (например логин пароль), и попадает на метод Issue. Обратите внимание, что RequestString при этом не меняется, а остаётся таким же, с которым обратилось клиентское приложение.
Для того что бы наш сервер понимал, что же именно клиент от него хочет, разберём аргументы запроса:
Соответственно метод WSFederationMessage.CreateFromUri, возвращает инстанцию наследников абстрактного класса WSFederationMessage. Далее выполняем действия, или входа в систему, или выхода.
При выполнении входа в систему по WS-Federation протоколу, выполняем статический метод:
Этот метод, на основе полученной инстанции класса SignInRequestMessage, и списка клеймов (Claims), сформирует некий объект RequestSecurityToken, который по сути и является нашим токеном клиента, и отдаст его на метод GetScope нашего STS сервиса. Для создания нашего STS сервиса, унаследуемся от абстрактного класса SecurityTokenService:
и перекроем метод GetScope:
именно в этом методе будет происходить анализ или заполнение объекта RequestSecurityToken.Т.е. непосредственно само формирование, и проверка токена клиента. Всю проверку я просто не вижу смысла описывать, так как проще всего по методу пройтись дебагом, так как в методе нет ничего не тривиального.
В принципе, вышеописанного в самом своём минимуме достаточно, для того что бы получить примитивный Identity Server, через который клиент может авторизоваться.
Если будет интересно, как это всё работает, я «склеил» упрощённый клиент и сервер, на с github.
Это просто облегченная версия сервера https://github.com/thinktecture/Thinktecture.IdentityServer.v2, собранная пока что, на данный момент, в целях демонстрации и не более того, и конечно не выдерживает никакой критики.
В заключение
Что хотелось бы, лично мне получить в результате, так это полноценный Identity Server, в который вынесена вся работа с профилем пользователя т.е. логин, регистрация, соцсети, просмотр своего профиля и т.д. Соответственно с должным уровнем security. Но по факту, что бы сам сервер можно было бы подключить к разрабатываемому ресурсу, и каждый раз не тратить на время на систему авторизации. Ну и конечно же, хотелось бы, интегрировать работу сервера, с WCF и REST сервисами, с распределением доступа к методам по ролям клиента. Но это пока только в планах.
Microsoft identity extensions что это
Данное руководство устарело. Актуальное руководство: Руководство по ASP.NET Core 7
Проект с типом аутентификации Individual User Accounts позволяет автоматически добавить все необходимые файлы для работы с ASP.NET Core Identity. Однако, как правило, редко востребован весь стандартный функционал, кроме того, нередко вознкает необходимость более детально настроить различные компоненты, из которых состоит Identity. И в реальности мы можем выбрать любой другой тип проекта и в него уже добавить вручную и подкорректировать функционал ASP.NET Core Identity. Это даст нам больший контроль над тем кодом, который размещается в проекте. Также это может быть актуально если у нас уже есть рабочий проект, но в него необходимо добавить поддержку ASP.NET Core Identity.
Итак, вначале создадим проект ASP.NET Core по шаблону ASP.NET Core Web App (Model-View-Controller) но без аутентификации:
Вначале добавим в папку Models новый класс User :
Класс User представляет пользователя и наследуется от класса IdentityUser, перенимая все его свойства. Кроме того, для примера здесь добавлено свойство Year, которое будет представлять год рождения пользователя. При желании можно определить любые другие свойства.
Для взаимодействия с MS SQL Server через ASP.NET Core Identity добавим в проект через Nuget пакеты Microsoft.AspNetCore.Identity.EntityFrameworkCore и Microsoft.EntityFrameworkCore.SqlServer .
Далее добавим в папку Models класс контекста данных ApplicationContext . Так как мы используем Identity, то класс контекста данных будет наследоваться не от DbContext, а от IdentityDbContext:
У нас есть контекст и модели, и теперь нам необходима база данных, которая будет хранить все данные. Вначале определим в файле appsettings.json строку подключения:
Далее нам надо изменить класс Startup, чтобы применить все необходимые сервисы для работы с Identity и базой данных:
В методе ConfigureServices() добавляются сервисы для Entity Framework Core:
Далее добавляются специфичные для Identity сервисы:
Метод AddIdentity() позволяет установить некоторую начальную конфигурацию. Здесь мы указываем тип пользователя и тип роли, которые будут использоваться системой Identity. В качестве типа пользователя выступает созданный нами выше класс User, а в качестве типа роли взят стандартный класс IdentityRole , который находится в пространстве имен Microsoft.AspNetCore.Identity.EntityFrameworkCore .
Метод AddEntityFrameworkStores() устанавливает тип хранилища, которое будет применяться в Identity для хранения данных. В качестве типа хранилища здесь указывается класс контекста данных.
Install and Download SharePoint 2013 prerequisites offline (manually)
This article applies in a situation when you don’t have internet access in your SharePoint server , I have placed all the direct download links for the installers you might need.
This article assumes you are having a new fresh installation of windows server 2008 R2 SP1
If you tried to run the installer , The following should be installed (but you cant install them directly from here since you don’t have internet)
in this case you can download and install SharePoint 2013 Prerequisites offline and run them manually as below:
I have placed what needs to be installed on a clean Window server R2 SP1 , you should not need more than this:
Microsoft .NET Framework 4.5
(Full Stand alone package)
Download tFx45_Full_x86_x64.exe from stand alone section from
Windows Management Framework 3.0
Microsoft SQL Server 2008 R2 SP1 Native Client
Download 1033x64sqlncli.msi from
Windows Identity Foundation (KB974405)
Windows Identity Extensions
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Server AppFabric
(Note: don’t install WindowsServerAppFabricSetup_x64_6.1 this is not the correct version that
SharePoint installer seeks)
Download it but don’t install it by yourself since it needs configuration, hence install all other
prerequisites in this article (except this one) then let the prerequisite installer to install AppFabric
and configure it manually for you by running the following command from command prompt:
prerequisiteInstaller.exe /appfabric:[Full AppFabric Installer path]
D: is the CD drive where SharePoint installer is placed
Microsoft Information Protection and Control Client
Microsoft WCF Data Services 5.0
Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB2671763
Microsoft. Identity. Client. Extensions. Msal 2.26.0
Showing the top 5 NuGet packages that depend on Microsoft.Identity.Client.Extensions.Msal:
This is the implementation of the Azure SDK Client Library for Azure Identity
Integrate with Azure DevOps Server 2022 and Azure DevOps Services from desktop-based Windows applications that require interactive sign-in by a user.
Programmatically issue queries and control commands to Kusto service.
PnP Framework contains the PnP Provisioning engine and a ton of extension methods that will make you more productive while developing for Microsoft 365.
This package contains the .net core Dataverse ServiceClient. Used to connect to Microsoft Dataverse. This Package has been authored by the Microsoft Dataverse SDK team.
Microsoft Identity Manager: функции, цены, загрузка
Microsoft сделала объявление в одном из своих сообщений в блоге, которое Microsoft Identity Manager (MIM) был выпущен на коммерческой основе. Если вы впервые слышите Microsoft Identity Manager, это эксклюзивный продукт управления идентификацией, предназначенный для работы с Azure-сервисами от Microsoft. По сути, он подготавливает идентификаторы Active Directory для синхронизации с Azure Active Directory, помогает вам сбрасывать пароли с помощью многофакторной аутентификации Azure и предоставляет динамические группы с одобрениями вместе с измененными параметрами управления сертификатами.
Microsoft Identity Manager
Microsoft Identity Manager 2016 является преемником продукта Forefront Identity Manager 2010 R2 и поддерживает управление идентификацией и доступом для вычислительных сред на основе помещений, эта версия имеет эксклюзивную поддержку для клиентов Windows 10. Хотя в настоящее время Microsoft Identity Manager 2016 теперь доступен, Microsoft планирует выпустить дополнительный пакет развертывания в течение следующих 90 дней, что поможет автоматизировать подготовку привилегированной среды управления идентификацией, указанной в Microsoft Active Directory, в одной из своих сообщений в блоге.
Преимущества использования Microsoft Identity Manager
Вот некоторые из преимуществ, которые может предложить Microsoft Identity Manager 2016:
Общая идентичность
Благодаря автоматизированным рабочим процессам, бизнес-правилам и бесшовной интеграции с гетерогенными платформами в облаке и центре обработки данных, это упрощает управление жизненным циклом идентификации. Используя один отдельный интерфейс, который он предлагает, можно было бы автоматизировать инициализацию идентификаторов и групп на основе бизнес-политики и осуществлять подготовку на основе рабочих процессов. С помощью среды разработки Visual Studio и .NET вы можете расширить MIM для поддержки новых сценариев и случаев использования.
Включить пользователей
MIM 2016 действует как универсальный интерфейс, позволяя пользователям самостоятельно устранять проблемы идентификации, которые включают в себя такие функции, как членство в группах, сброс смарт-карт и паролей, путем повышения производительности и удовлетворенности.
Защита данных
Инструменты разработки ролей помогают вам открывать и сопоставлять разрешения для многих систем для отдельных пользователей. Используйте эти инструменты для развертывания роли, чтобы также исследовать наборы разрешений для пользователей по всему предприятию, которые впоследствии могут быть смоделированы и применены централизованно. Углубленные функции аудита и отчетности обеспечивают повышенную степень видимости соответствия и состояния безопасности систем в организации.
Унифицировать доступ
Концепция унифицированного доступа — это сокращение количества имен пользователей и паролей, необходимых для входа в систему. Группы могут автоматически обновлять свое членство, это гарантирует, что только люди с правом доступа могут использовать правильные ресурсы.
Возможности Microsoft Identity Manager
Чтобы начать работу и лучше понять этот продукт, важно знать, как работает Microsoft Identity Manager.
соединять
Вы можете начать с подключения идентификаторов Active Directory к различным местоположениям, таким как каталоги, базы данных и приложения.
обмен
Вы можете пользоваться привилегией обмена идентификаторами между этими местоположениями, при необходимости настраивая их.
Самообслуживание
Вы можете включить пароль, группу, а также управление сертификатами для своих пользователей с помощью простого самообслуживания, которое использует надежную защиту.
Поделиться
Используйте Azure Active Directory Connect для синхронизации идентификаторов от Active Directory до Azure Active Directory, который помогает доставлять единый вход и самообслуживание приложения SaaS в облаке.
Как купить Microsoft Identity Manager
Лицензия клиентского доступа (CAL) требуется для каждого пользователя, личность которого управляется, поскольку этот продукт лицензируется для каждого пользователя. Кроме того, для использования серверного программного обеспечения Microsoft Identity Manager 2016 в качестве дополнения к Windows Server требуется лицензия Windows Server с активным Software Assurance.
Azure Active Directory Premium от Microsoft Enterprise Mobility Suite включает Microsoft Identity Manager 2016, который делает его самым экономичным способом приобретения всех включенных облачных сервисов: Azure Active Directory Premium, Azure Rights Management и Intune.
Цены на Microsoft Identity Manager
Стоимость Enterprise Mobility Suite составляет 8,75 долларов США в месяц. Приобретаемые отдельно, они стоят в месяц:
- Azure AD Premium — $ 6
- Microsoft Intune — $ 6
- Управление Azure Rights — $ 2
- Microsoft Advanced Threat Analytics — $ 3,50.
Покупка пакета приводит к экономии на 50% по сравнению с отдельными предложениями.
Более подробную информацию о Microsoft Identity Manager можно найти Вот, Вы можете попробовать 180-дневную оценочную копию Microsoft Identity Manager 2016, если ваш компьютер соответствует системным требованиям, указанным в продукте.