Description of Windows Identity Foundation

This article provides information about Windows Identity Foundation.

Original product version: В Windows 7 Service Pack 1, Windows Server 2012 R2
Original KB number: В 974405

Introduction

Windows Identity Foundation (WIF) is a new extension to the Microsoft .NET Framework that makes it easy for developers to enable advanced identity capabilities in the .NET Framework applications. Based on interoperable, standard protocols, Windows Identity Foundation and the claims-based identity model can be used to enable single sign-on (SSO), personalization, federation, strong authentication, identity delegation, and other identity capabilities in ASP.NET and Windows Communication Foundation (WCF) applications that run on-premises or in the cloud.

System requirements

Windows Identity Foundation requires that one of the following operating systems be installed:

• Windows 7 (32-bit or 64-bit)
• Windows Server 2008 R2 (64-bit)
• Windows Server 2008 together with Service Pack 2 (32-bit or 64-bit)
• Windows Vista together with Service Pack 2 (32-bit or 64-bit)
• Windows Server 2003 together with Service Pack 2 (32-bit or 64-bit)
• Windows Server 2003 R2 (32-bit or 64-bit)

Windows Identity Foundation requires the following to be installed:

• The Microsoft .NET Framework 3.5 together with Service Pack 1

Supported languages

Windows Identity Foundation is supported in the following languages:

Download information

The following files are available for download from the Microsoft Download Center.

Package name	Supported operating system	Platform	Download file size
Windows6.1-KB974405-x64.msu	Windows 7 and 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 and Windows Server 2008 SP2	x64	969 KB
Windows6.0-KB974405-x86.msu	Windows Vista SP2 and Windows Server 2008 SP2	x86	861 KB
Windows5.2-KB974405-x64.exe	Windows Server 2003 SP2	x64	1.2 MB
Windows5.2-KB974405-x86.exe	Windows Server 2003 SP2	x86	1.2 MB

For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591 How to obtain Microsoft support files from online services

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.

More information

For more information about technical details and white papers, go to the following Microsoft websites:
Microsoft Security Response Center

Windows operating system upgrade information

If you have Windows Identity Foundation installed on Windows Server 2008 or on Windows Server 2003, Windows Identity Foundation will be automatically uninstalled when you upgrade your Windows operating system to Windows Server 2008 R2. You have to install the Windows Identity Foundation installation package for Windows Server 2008 R2 after your Windows operating system upgrade.

If you have Windows Identity Foundation installed on Windows Server 2003, Windows Identity Foundation will remain on the upgraded operating system when you upgrade your Windows operating system to Windows Server 2008. We recommend that you uninstall the Windows Identity Foundation before you upgrade your Windows operating system and then reinstall Windows Identity Foundation for Windows Server 2008. You can use the following command to silently uninstall Windows Identity Foundation on Windows Server 2003: %windir%\\$NtUninstallKB974405$\\spuninst\\spuninst.exe /quiet .

If an error occurs when you run this command, we recommend that you uninstall Windows Identity Foundation by using Programs and Features in Control Panel.

Technical revisions

The following table lists significant technical revisions to this article.

Описание Windows Identity Foundation

В этой статье содержится информация о Windows Identity Foundation.

Исходная версия продукта: Windows 7 Пакет обновления 1, Windows Server 2012 R2
Исходный номер КБ: 974405

Общие сведения

Windows Identity Foundation (WIF) — это новое расширение Microsoft .NET Framework, которое позволяет разработчикам легко включить расширенные возможности удостоверений в приложениях .NET Framework. В зависимости от взаимодействия, стандартных протоколов, Windows Identity Foundation и модели удостоверений на основе утверждений можно использовать для поддержки единого входов,персонализации, федерации, сильной проверки подлинности, делегирования удостоверений и других возможностей удостоверений в приложениях Windows Communication Foundation (WCF), которые работают локально или в ASP.NET облаке.

Требования к системе

Windows Identity Foundation требует установки одной из следующих операционных систем:

• Windows 7 (32-разрядная или 64-разрядная версия)
• Windows Server 2008 R2 (64-битная)
• Windows Server 2008 вместе с Пакет обновления 2 (32- или 64-битная)
• Windows Vista вместе с Пакет обновления 2 (32- или 64-битная)
• Windows Server 2003 вместе с Пакет обновления 2 (32- или 64-битная)
• Windows Server 2003 R2 (32- или 64-битная)

Для установки Windows Identity Foundation необходимо следующее:

• Microsoft .NET Framework 3.5 вместе с Пакет обновления 1

Поддерживаемые языки

Windows Identity Foundation поддерживается на следующих языках:

• Английский
• Голландский
• французский;
• немецкий;
• итальянский;
• японский;
• Испанский

Сведения о загрузке

Следующие файлы можно скачать в Центре загрузки Майкрософт.

Название пакета	Поддерживаемая операционная система	Платформа	Размер файла скачивания
Windows6.1-KB974405-x64.msu	Windows 7 и Windows Server 2008 R2	x64	965 КБ
Windows6.1-KB974405-x86.msu	Windows 7	x86	858 КБ
Windows6.0-KB974405-x64.msu	Windows Vista SP2 и Windows Server 2008 SP2	x64	969 КБ
Windows6.0-KB974405-x86.msu	Windows Vista SP2 и Windows Server 2008 SP2	x86	861 КБ
Windows5.2-KB974405-x64.exe	Windows Server 2003 SP2	x64	1,2 МБ
Windows5.2-KB974405-x86.exe	Windows Server 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 Identity Foundation для Windows Server 2008 R2 после обновления операционной системы Windows.

Если в Windows Server 2003 установлен Windows Identity Foundation, Windows Identity Foundation останется в обновленной операционной системе при обновлении операционной системы Windows до Windows Server 2008. Перед обновлением операционной системы Windows рекомендуется удалить Windows Identity Foundation, а затем переустановить Windows Identity Foundation для Windows Server 2008. Чтобы автоматически удалить Windows Identity Foundation в Windows Server 2003, можно использовать следующую %windir%\\$NtUninstallKB974405$\\spuninst\\spuninst.exe /quiet команду:

Если при запуске этой команды возникает ошибка, рекомендуется удалить Windows Identity Foundation с помощью программ и компонентов на панели управления.

Технические изменения

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

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.