Windows identity foundation что это

Обновлено: 05.07.2024

Windows CardSpace представляет собой основанное на отраслевых стандартах решение для управления идентификацией при работе в Интернет. Windows CardSpace – это способ простой и безопасной идентификации пользователей при перемещении между ресурсами Интернет, не требующий повторного ввода имен и паролей. Идентификация на основе утверждений, принятая многими крупными поставщиками программного обеспечения, может стать большим шагом вперед. В отличие от более ранних технологий унифицированной идентификации (например, Microsoft Passport) Windows CardSpace управляет непосредственно пользователями и приложениями, с которыми устанавливается контакт. Иными словами, можно использовать разные схемы и уровни сложности для идентификации при доступе, например, при регистрации в Web-форумах или для банковских операций.

упростить процесс аутентификации пользователей на веб-сервисах и приложениях,
контролировать распространение пользовательских данных,
обеспечивать защищенную передачу пользовательских данных.

Компания КРИПТО-ПРО реализовала продержу российской криптографии для стека протоколов WS-* и CardSpace v1. Для этого необходим продукт КриптоПро Sharpei.

Geneva Server представляет собой "облачную" платформу для корпоративной идентификации, при помощи которой пользователи могут использовать единую идентификацию не только для разных сервисов в рамках одного домена или сети, но и в разных сетях и доменах. Главным преимуществом Geneva является поддержка спецификаций языка Security Assertion Markup Language (SAML) 2.0, позволяющих использовать разработку Microsoft в тандеме с другими средствами для идентификации, в частности с теми, что разрабатывают компании Novell, CA, SAP или Sun. Стоит отметить, что Geneva Server базируется на Active Directory Federation Services, расширяя его дополнительными сценариями и протоколами. В отличие от предыдущих версий ADFS2 может работать с клиентским сервисом Geneva CardSpace, совместимым с Windows Vista и Windows 7. Использование Geneva Server, реализующую технологию CBA, позволит:

Обеспечить защищенное взаимодействие между доменами Active Directory.
Избежать дублирования учетных записей и снизит расходы на управление ими, за счет создания единой регистрации между организациями, приложениями, платформами.
Использовать Windows CardSpace для междоменной идентификации. Geneva Server позволит использовать CardSpace как с веб-сервисами, так и с приложениями на основе обозревателя.
Расширить возможности аутентификации на веб-сайтах, упрощая аутентификацию по смарт-картам.
Применять несколько методов аутентификации.
Обеспечить безопасную передачу пользовательских учетных данных, используя российские стандарты шифрования и цифровой подписи (с применением продуктов КриптоПро Sharpei и КриптоПро CSP).

Центр Идентификации Bandit (Bandit IdP) – это продукт, созданный на основе двух open source-проектов Bandit и Higgins. Центр Идентификации Bandit написан на платформе Java и использует сертифицированные средства защиты КриптоПро JCP, и КриптоПро JTLS. Центр Идентификации Bandit работает как веб-приложение под управлением TomCat и предоставляет следующую функциональность:

Создание и управление пользовательскими данными. Включает в себя инструменты для создания учетных данных, редактирования атрибутов, удаления пользователей и управления паролями. Администратор может изменять атрибуты доступные пользователям, и указывать, какие атрибуты доступны для изменений самим пользователем.
Выпуск инфокарт. Администратор имеет возможность создать несколько шаблонов карт. После чего пользователь получает инфокарту, выпущенную по одному из шаблонов.
Служба электронных идентификаторов (STS). ЦИ Bandit имеет встроенный Higgins STS. Служба электронных идентификаторов выпустит электронный идентификатор, представляющий собой маркер безопасности, когда пользователь выберет одну из инфокарт, изданных ЦИ Bandit и корректно пройдет процедуру аутентификации.
Использование различных хранилищ пользовательских данных.

Центр Идентификации Bandit использует Higgins IdAS (Identity Attribute Service) для доступа к пользовательским данным. IdAs – это уровень абстракции, позволяющий подключать различные хранилища данных. Поэтому ЦИ Bandit может обращаться за пользовательскими данными к LDAP, SQL и т.д.

Для поддержки российской криптографии необходим продукт КриптоПро Sharpei.

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

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

Введение

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

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

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

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 Server 2003, Windows Identity Foundation останется в обновленной операционной системе при обновлении операционной системы Windows до Windows Server 2008. Мы рекомендуем удалить Windows Identity Foundation перед обновлением операционной системы Windows, а затем переустановить Windows Identity Foundation для Windows Server 2008. Вы можете использовать следующую команду, чтобы молча удалить Windows Identity Foundation на Windows Server 2003: %windir%\\$NtUninstallKB974405$\\spuninst\\spuninst.exe /quiet .

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

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

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

Для того, что бы определиться, в каких же случаях имеет смысл «городить огород» со своим сервером авторизации, достаточно посмотреть как же он работает. Итак, мы хотим предоставлять клиенту несколько сервисов, например несколько сайтов, например с WCF сервисами, и допустим REST API. Согласитесь, что пользователю будет достаточно дискомфортно отдельно авторизоваться на каждом из наших сайтов, при переходе с одного на другой. Тут достаточно простая идея, которая заключается в том, что пользователю, при авторизации на одном из сервисов (ресурсов), выдаётся некий Token. А в дальнейшем, другой, или тот же, сервис (ресурс) уже доверяет авторизированному пользователю, на основе существования у клиента этого самого токена, ну и так далее…

Просто для наглядности понимания, приведу понравившееся сравнение (к сожалению ссылки на нашел). Например человек получает паспорт, после некой процедуры проверки, а в дальнейшем, предоставляя свой паспорт, человеку доверяют, на основе наличия у него паспорта. В данном сравнении, паспорт человека, и есть токен клиента.

Сразу же можно сделать вывод, что зачастую, бессмысленно выдавать «паспорт», если он будет проверяться только в одном месте.

Конечно же, у токена, как и у паспорта, есть время жизни, и точно так же, токен может быть пересоздан, на основе устаревшего. И по аналогии, как и паспорт, токен может быть разным, т.е. представлять из себя практически всё что угодно, или это заголовок реквеста, или base64 строка, как например JWT Token (JSON Web Token). А по факту, сам токен содержит информацию о себе (время когда он был создан последний раз, публичный ключ сертификата, и т.п.), а так же список клеймов, содержащих информацию о клиенте. Для описания токена, мы будем использовать язык SAML (Security Assertion Markup Language).

Отсюда можно сделать пожалуй два основных вывода, первый — это что для просто авторизации пользователя, на сайте, использовать Identity Server, просто неоправданно, и второй — что поскольку мы собираемся передавать токен, между различными ресурсами, нам понадобится безопасность транспорта, в первую очередь. И так приступим, и начнём пожалуй с настройки транспорта, поскольку если у нас не будет trusted транспорта, ничего работать просто не сможет, а для этого, в первую очередь, нам понадобится сертификат.

Создание сертификата

Далее, для проверки сертификата издателя, воспользуемся утилитой cert2spc.

Для того что бы, наш IIS сервер начал работать с нашим сертификатом, во первых, нам нужно импортировать наш pfx файл, в Trusted Root Certification Authorities зону через оснастку MMC, и выполнить Import в самом IIS сервере, в разделе Server Certificates.

Если Вы скачаете IdentityTrainingKitVS2010 с сайта Microsoft, то можно немного облегчить себе жизнь, выполнив SetupCertificates.cmd, например по пути IdentityTrainingKitVS2010\Labs\MembershipAndFederation\Source\Setup\Scripts\SetupCertificates.cmd

Настройка клиентского приложения

Теперь надо произвести некоторую настройку нашего клиентского приложения. Для начала, в настройках проекта, установим адрес нашего сайта для поля 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:

Тут всё достаточно просто, iisuer — это наш сервер из секции выше, а reply — это адрес куда, в дальнейшем отвечать серверу.

Осталось зарегистрировать модули, в разделе system.webServer.

Всё, можно проверять работу нашего клиента, достаточно попробовать с View вызвать любой метод или метод контроллера помеченного атрибутом Authorize.

После запуска приложения (по F5), и попытке пользователем вызвать наш метод, мы увидим GET запрос по адресу нашего бедующего сервера:

Описанного выше, вполне хватает, для минимальной настройки клиентского приложения, работающего с WIF Identity Server, даже если Вы используете сервер сторонних разработчиков, главное что бы сервер поддерживал WS-Federation.

Создание сервера

Создадим 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, через который клиент может авторизоваться.

В заключение

Что хотелось бы, лично мне получить в результате, так это полноценный Identity Server, в который вынесена вся работа с профилем пользователя т.е. логин, регистрация, соцсети, просмотр своего профиля и т.д. Соответственно с должным уровнем security. Но по факту, что бы сам сервер можно было бы подключить к разрабатываемому ресурсу, и каждый раз не тратить на время на систему авторизации. Ну и конечно же, хотелось бы, интегрировать работу сервера, с WCF и REST сервисами, с распределением доступа к методам по ролям клиента. Но это пока только в планах.

Windows® Identity Foundation (WIF) — это платформа для построения приложений, поддерживающих удостоверения. Платформа поддерживает на уровне абстракций протоколы WS-Trust и WS-Federation и предоставляет разработчикам программные интерфейсы (API) для построения служб маркеров безопасности (STS) и приложений, поддерживающих утверждения. Приложения могут использовать WIF для обработки маркеров, выданных службами STS, и принятия решений на основе удостоверений на уровне веб-приложения или веб-службы.

Ниже перечислены основные возможности WIF.

Кроме того, платформа также обеспечивает возможности для создания служб STS, которые поддерживают протокол WS-Federation для включения клиентов веб-браузеров. Такие службы также называются "пассивными службами STS".

WIF поддерживает следующие основные сценарии.

WIF упрощает использование преимуществ модели удостоверений на основе утверждений, описанной в этой теме. В этой теме приводится обзор новых возможностей, предлагаемых в Windows® Identity Foundation (WIF) для обработки утверждений. Дополнительные сведения см. в Техническом документе по Windows Identity Foundation для разработчиков.

Доступ к утверждениям через Thread.CurrentPrincipal

Для доступа к набору утверждений текущего пользователя в приложении проверяющей стороны используйте Thread.CurrentPrincipal .

В следующем примере кода показано использование этого метода для получения интерфейса IClaimsIdentity:

Тип утверждения роли

Утверждения, извлеченные компонентом Windows Identity Foundation из маркеров различных типов

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

Сопоставление с маркером доступа Windows

См. "SAML 1.1, сопоставление с учетной записью Windows".

Windows (Kerberos или NTLM)

Один из наших читателей попросил объяснить предназначение всех функций, которые могут быть включены или отключены в окне «Компоненты Windows». Даже при том, что для каждого из них предусмотрено описание, информация, которую предоставляет сама Windows, либо слишком краткая, либо слишком сложна для понимания. Вот почему мы решили опубликовать эту статью, в которой постарались описать каждый компонент в Windows 8.1 Pro гораздо более подробно, чем это делает Windows. Надеемся, что после прочтения вы сможете легко решить для себя, какие компоненты следует включить или, наоборот, отключить.

Где найти компоненты Windows

В этой статье мы опишем все функции, которые имеются в меню «Компоненты Windows», а если вы хотите узнать, как получить доступ к этому меню, прочитайте следующее руководство: «Как включить или отключить компоненты Windows».

При написании этого руководства мы использовали Windows 8.1 Pro. Другие редакции Windows будут включать несколько иной ряд доступных возможностей.

Описание всех компонентов Windows

После того как вы откроете окно «Компоненты Windows», вы увидите длинный список функций, которые могут быть включены или отключены. Давайте рассмотрим все эти компоненты один за другим и узнаем, за что отвечает каждый из них:

PowerShell является излюбленным оружием для многих ИТ-администраторов, и не зря. Этот инструмент может очень сильно упростить операции и усилия по управлению крупными корпоративными сетями.

Звучит сложно? Давайте рассмотрим это на примере работника «Х», который использует «Рабочие папки» для разграничения своей работы и своей личной информации и имеет возможность работать с любого устройства:

Итак, если «Х» на своем рабочем компьютере сохранит документ в директорию «Рабочие папки», он будет синхронизирован с файловым сервером, который управляется ИТ-отделом его компании. Когда «Х» вернется домой и возьмет свой планшет, на нем уже будет вышеупомянутый документ, поскольку ранее он настроил «Рабочие папки» на этом устройстве. Предположим, что затем «Х» возьмет свой планшет и направится, например, в кафе, чтобы поработать с документом в режиме оффлайн. Но когда он вернется домой и подключит планшет к интернету, документ будет автоматически синхронизирован с файловым сервером, так что все внесенные изменения будут доступны «Х» на следующий день, когда он вернется в свой офис и сядет за свой рабочий компьютер. Так понятней, верно?

На этом все! Мы надеемся, что эта информация окажется полезной для вас, и что мы смогли ответить хотя бы на некоторые из ваших вопросов, связанных с различными компонентами Windows. И обязательно ознакомьтесь с другими статьями и инструкциями на нашем сайте!

Читайте также: