Windows identity foundation что это
Windows® Identity Foundation (WIF) — это платформа для построения приложений, поддерживающих удостоверения. Платформа поддерживает на уровне абстракций протоколы WS-Trust и WS-Federation и предоставляет разработчикам программные интерфейсы (API) для построения служб маркеров безопасности (STS) и приложений, поддерживающих утверждения. Приложения могут использовать WIF для обработки маркеров, выданных службами STS, и принятия решений на основе удостоверений на уровне веб-приложения или веб-службы.
Ниже перечислены основные возможности WIF.
Кроме того, платформа также обеспечивает возможности для создания служб STS, которые поддерживают протокол WS-Federation для включения клиентов веб-браузеров. Такие службы также называются «пассивными службами STS».
Платформа включает встроенные шаблоны Visual Studio для создания служб STS ASP.NET и WCF. Эти шаблоны позволяют создавать простые службы STS, а разработчики могут расширять их и реализовывать производственные службы, соответствующие их потребностям. Дополнительные сведения см. в разделах Инструкции: создание службы STS ASP.NET и Инструкции: создание службы STS WCF.
WIF поддерживает следующие основные сценарии.
WIF упрощает использование преимуществ модели удостоверений на основе утверждений, описанной в этой теме. В этой теме приводится обзор новых возможностей, предлагаемых в Windows® Identity Foundation (WIF) для обработки утверждений. Дополнительные сведения см. в Техническом документе по Windows Identity Foundation для разработчиков.
Доступ к утверждениям через Thread.CurrentPrincipal
В следующем примере кода показано использование этого метода для получения интерфейса IClaimsIdentity:
Тип утверждения роли
Утверждения, извлеченные компонентом Windows Identity Foundation из маркеров различных типов
WIF поддерживает ряд сочетаний готовых механизмов проверки подлинности. В следующей таблице приводится список утверждений, которые WIF извлекает из маркеров различных типов.
Сопоставление с маркером доступа Windows
См. «SAML 1.1, сопоставление с учетной записью Windows».
Windows (Kerberos или NTLM)
Тип проверки подлинности
Коды URI, выпущенные в утверждении «AuthenticationMethod»
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. А в дальнейшем, другой, или тот же, сервис (ресурс) уже доверяет авторизированному пользователю, на основе существования у клиента этого самого токена, ну и так далее…
Сразу же можно сделать вывод, что зачастую, бессмысленно выдавать «паспорт», если он будет проверяться только в одном месте.
Существует целый ряд, зарегистрированных неймспейсов, которых более чем хватает для того что бы описать профиль клиента, от списка ролей, до аватарки. При желании мы можем создавать свои пространства имён, единственное о чём нужно помнить, что сам объект 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.
Всё, можно проверять работу локального 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 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 сервисами, с распределением доступа к методам по ролям клиента. Но это пока только в планах.
Описание Windows Identity Foundation
В этой статье приводится информация о Windows Identity Foundation.
Применяется к: Windows 7 Пакет обновления 1, Windows Server 2012 R2
Исходный номер КБ: 974405
Введение
Требования к системе
Windows Identity Foundation требует установки одной из следующих операционных систем:
Windows Для установки Identity Foundation необходимо установить следующее:
Поддерживаемые языки
Windows Фонд identity поддерживается на следующих языках:
Скачивание сведений
Следующие файлы доступны для скачивания из Центра загрузки Майкрософт.
| Название пакета | Поддерживаемая операционная система | Платформа | Размер файла загрузки |
|---|---|---|---|
| Windows6.1-KB974405-x64.msu | Windows 7 и Windows Server 2008 R2 | x64 | 965 KB |
| Windows6.1-KB974405-x86.msu | Windows 7 | x86 | 858 KB |
| Windows6.0-KB974405-x64.msu | Windows Vista SP2 и Windows Server 2008 SP2 | x64 | 969 KB |
| Windows6.0-KB974405-x86.msu | Windows Vista SP2 и Windows Server 2008 SP2 | x86 | 861 KB |
| Windows5.2-KB974405-x64.exe | Windows Сервер 2003 SP2 | x64 | 1.2 МБ |
| Windows5.2-KB974405-x86.exe | Windows Сервер 2003 SP2 | x86 | 1.2 МБ |
Дополнительные сведения о том, как скачать файлы поддержки Майкрософт, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
119591 Получение файлов поддержки Майкрософт из онлайн-служб
Корпорация Майкрософт отсканирует этот файл для вирусов. Корпорация Майкрософт использовала самое текущее программное обеспечение для обнаружения вирусов, доступное в день публикации файла. Файл хранится на серверах с усиленной безопасностью, которые помогают предотвратить любые несанкционированные изменения в файле.
Дополнительная информация
Дополнительные сведения о технических деталях и документах можно найти на следующих веб-сайтах Майкрософт:
Центр Майкрософт по реагированию на угрозы
Windows обновления операционной системы
Если Windows Identity Foundation установлен на Windows Server 2008 или на Windows Server 2003, Windows Identity Foundation будет автоматически отключлен при обновлении операционной системы Windows до Windows Server 2008 R2. После обновления Windows для Windows Server 2008 R Windows 2 необходимо установить Windows Identity Foundation.
Если при запуске этой команды возникает ошибка, рекомендуется удалить Windows Identity Foundation с помощью программ и функций в панели управления.
Технические изменения
В следующей таблице перечислены значительные технические изменения в этой статье.
Windows identity foundation что это
Добрый день! Уважаемые читатели и гости одного из крупнейших 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 10 и какие из них можно отключить
Windows 10 поставляется вместе с большим списком «компонентов», которые пользователь может включить или выключить в соответствующем диалоговом окне. Большое количество функций из этого списка создано специально для нужд и потребностей бизнес-пользователей и серверов, но вместе с этим часть компонентов может пригодиться и обычному пользователю.
Все компоненты Windows занимают место на вашем жестком диске, вне зависимости от того, включены они или нет. Иными словами, отключение отдельных компонентов не освободит место на диске компьютера. Кроме того, не стоит включать абсолютно все компоненты Windows, поскольку это негативно скажется на безопасности вашего компьютера, а также ухудшит его производительность. Стоит включать лишь те компоненты, которые вам действительно нужны или те, принцип работы которых вы понимаете. Это же касается и отключения. Бездумное выключение отдельных или всех компонентов системы может привести к нарушению работы приложений или ухудшению защищенности операционной системы.
Компоненты Windows 10
Управлять компонентами Windows можно только из классической панели управления. В Windows 10 Fall Creators Update Microsoft все еще не перенесла раздел с компонентами в новое приложение Параметры Windows. Интерфейс настройки компонентов Windows позволяет настроить виртуализацию Hyper-V, IIS-сервисы, подсистему Linux и так далее. Вы даже можете «отключить» Internet Explorer с помощью окна компонентов Windows 10. Конкретный набор доступных опций будет зависеть от того, какую редакцию Windows вы используете. В Windows 10 Профессиональная будет список побольше, а в Windows 10 Домашняя поменьше.
Где найти программы и компоненты Windows 10
Чтобы добраться до окна настройки компонентов Windows нажмите Win + R и введите optionalfeatures. Сразу же появится небольшое окошко со списком. Как вариант, вы можете ввести команду control, а затем перейти в раздел Программы – Включение или отключение компонентов Windows. Обратите внимание, что изменение компонентов Windows требует от вашей учетной записи наличия прав Администратора.
Посмотрите на список компонентов, и вы заметите, что определенные пункты обозначены черными квадратами, а не «птичками». Это означает, что компонент имеет «подкомпоненты» и не все из них активированы. Нажмите на плюсик, и система отобразит список доступных подкомпонентов.
Внесите нужные вам изменения и нажмите Ок. Скорее всего, Windows попросит перезагрузиться, чтобы изменения вступили в силу.
Обратите внимание, что управление компонентами Windows не требует от компьютера активного Интернет-соединения. Их можно включать и выключать в любой момент вне зависимости от того, есть ли Интернет или его нет. Все компоненты уже доступны в системе после установки, а окно настроек лишь включает или отключает их.
Какие компоненты Windows можно отключить
Здесь вы найдете объяснение нескольких компонентов Windows и то, для чего они нужны. Внимательно ознакомьтесь с ним и сами решите, какие из них нужны вашему компьютеру, а какие нет. Имейте ввиду, что отключение тех или иных компонентов может привести к тому, что часть приложений перестанет работать или будет работать с ошибками.
В списке вы найдете еще много других компонентов, которые зачастую отключены. Они включаются автоматически лишь при необходимости, поэтому вручную активировать их мы не рекомендуем. Если они отключены, значит скорее всего они вам не нужны вовсе. Ну а что же касается включенных компонентов, то их описание вы уже нашли в этой статье. Сами решайте, стоит их отключать или нет. В подавляющем большинстве случаев пользователю вовсе не надо открывать окно с компонентами Windows, но все же полезно знать, для чего они нужны и какую функцию выполняют.