Microsoft Windows HTTP Services (WinHTTP) полностью поддерживает использование протокола проверки подлинности Microsoft Passport на стороне клиента. В этом разделе приводятся общие сведения о транзакциях, связанных с проверкой подлинности Passport, и способах их обработки.
В WinHTTP 5.1 проверка подлинности Passport отключена по умолчанию.
Passport 1.4
Passport является основным компонентом служб microsoft .NET стандартных блоков. Это позволяет компаниям разрабатывать и предлагать распределенные веб-службы в широком спектре приложений и позволяет своим членам использовать одно имя входа и пароль на всех участвующих веб-сайтах.
WinHTTP обеспечивает поддержку платформы Microsoft Passport 1.4 путем реализации протокола на стороне клиента для проверки подлинности Passport 1.4. Он освобождает приложения от сведений о взаимодействии с инфраструктурой Passport и сохраненными именами пользователей и паролями в Windows XP. Эта абстракция не отличается от точки зрения разработчика, чем использование традиционных схем проверки подлинности, таких как Basic или Digest.
Renew American US Passport Online in less than 10 minutes! So EASY!! #passportrenewal
Windows XP: раздел реестра HKCUSoftwareMicrosoftWindowsCurrentVersionInternet ПараметрыPassportNumRegistrationRuns определяет количество попыток отображения мастера проверки подлинности passport при необходимости проверки подлинности PassPort. Если для этого ключа задано число больше 5, мастер не отображается.
В следующих разделах описаны транзакции, связанные с проверкой подлинности Passport с точки зрения клиентского приложения. Сведения о разработке passport на стороне сервера см. в документации по пакету SDK для Passport.
- Первоначальный запрос
- Сервер входа Passport
- Запрос, прошедший проверку подлинности
Первоначальный запрос
Когда клиент запрашивает ресурс на сервере, которому требуется проверка подлинности Passport, сервер проверяет запрос на наличие билетов. Если действительный билет отправляется с запросом, сервер отвечает запрошенным ресурсом. Если билет не существует на клиенте, сервер отвечает кодом состояния 302. Ответ включает заголовок запроса «WWW-Authenticate: Passport1.4».
Клиенты, которые не используют Passport, могут следовать перенаправлению на сервер входа Passport. Более сложные клиенты обычно обращаются к nexus Passport, чтобы определить расположение сервера входа Passport.
Центральное место в сети Microsoft Passport — Passport Nexus, что упрощает синхронизацию сайтов участников Passport, чтобы убедиться, что каждый сайт содержит последние сведения о конфигурации сети и других проблемах. Каждый компонент Passport (Passport Manager, серверы входа, серверы обновления и т. д.) периодически взаимодействует с Nexus, чтобы получить сведения, с которыми необходимо найти и правильно взаимодействовать, другие компоненты в сети Passport. Эти сведения извлекаются в виде XML-документа, называемого документом конфигурации компонента или CCD.
На следующем рисунке показан первоначальный запрос к филиалу Passport.
РАЗРЕШЕНИЕ НА ВЫЛЕТ ИЗ США ДЛЯ БЕЖЕНЦЕВ: КАК ПОЛУЧИТЬ ADVANCE PAROLE И REFUGEE TRAVEL DOCUMENT
Сервер входа Passport
Сервер входа Passport обрабатывает все запросы на билеты на любой ресурс в доменном органе Passport. Перед проверкой подлинности запроса с помощью Passport клиентское приложение должно связаться с сервером входа, чтобы получить соответствующие билеты.
Когда клиент запрашивает билеты с сервера входа Passport, сервер входа обычно отвечает с кодом состояния 401, чтобы указать, что учетные данные пользователя должны быть предоставлены. При указании этих учетных данных сервер входа отвечает на запросы , необходимые для доступа к указанному ресурсу на сервере, который содержит исходный запрошенный ресурс. Сервер входа также может перенаправить клиент на другой сервер, который может предоставить запрошенный ресурс.
Запрос, прошедший проверку подлинности
Если у клиента есть билеты , соответствующие заданному серверу, эти билеты включаются во все запросы к серверу. Если билеты не были изменены с момента получения с сервера входа Passport, а билеты действительны для сервера ресурсов, сервер ресурсов отправляет ответ, включающий как запрошенный ресурс, так и файлы cookie, указывающие, что пользователь прошел проверку подлинности для будущих запросов.
Дополнительные файлы cookie в ответе предназначены для ускорения процесса проверки подлинности. Дополнительные запросы в одном сеансе для ресурсов на серверах в одном и том же доменном органе Passport включают эти дополнительные файлы cookie. Учетные данные не нужно отправлять на сервер входа еще раз до истечения срока действия файлов cookie.
Использование Passport в WinHTTP
Проверка подлинности passport в WinHTTP очень похожа на другие схемы проверки подлинности. Общие сведения о проверке подлинности в WinHTTP см. в статье «Проверка подлинности в WinHTTP «.
В WinHTTP 5.1 проверка подлинности Passport отключена по умолчанию и должна быть явно включена с помощью WinHttpSetOption перед использованием.
WinHTTP обрабатывает многие сведения о транзакциях внутренне для проверки подлинности Passport. Во время первоначального запроса сервер отвечает с кодом состояния 302 при необходимости проверки подлинности. Код состояния 302 фактически указывает на перенаправление и является частью протокола Passport для обратной совместимости.
WinHTTP скрывает код состояния 302 и связывается с приложением Passport Nexus, а затем сервер входа. Приложение WinHTTP уведомляется о коде состояния 401, отправляемом сервером входа для запроса учетных данных пользователя. Однако в приложении отображается состояние 401, исходящее от сервера, с которого был запрошен ресурс. Таким образом, приложение WinHTTP не знает о взаимодействии с другими серверами, и оно может обрабатывать проверку подлинности Passport с тем же кодом, который обрабатывает другие схемы проверки подлинности.
Как правило, приложение WinHTTP отвечает на код состояния 401, предоставляя учетные данные проверки подлинности. Если учетные данные предоставляются с помощью WinHttpSetCredentials или SetCredentials для проверки подлинности паспорта, учетные данные фактически отправляются на сервер входа, а не на сервер, указанный в запросе.
Однако при ответе на код состояния 407 приложение WinHTTP должно использовать WinHttpSetOption для предоставления учетных данных прокси-сервера, а не WinHttpSetCredentials. Так как WinHttpSetOption является менее безопасным способом предоставления учетных данных, его следует избегать.
После получения билеты управляются внутренне и автоматически отправляются на применимые серверы в будущих запросах.
WinHTTP позволяет отключить автоматическое перенаправление, вызвав функцию WinHttpSetOption для флага WINHTTP_OPTION_DISABLE_FEATURE и указав значение WINHTTP_DISABLE_REDIRECTS. Отключение перенаправления не мешает перенаправлению, которое WinHTTP обрабатывает внутренне для транзакций Passport.
WinHTTP может успешно завершить проверку подлинности Passport, даже если приложение отключает автоматическое перенаправление. Однако после завершения проверки подлинности Passport неявное перенаправление должно происходить из URL-адреса сервера входа Passport обратно в исходный URL-адрес. Это перенаправление не активируется http-ответом 302, но неявно в протоколе Passport.
WinHTTP специально обрабатывает это неявное перенаправление. Если приложение отключило автоматическое перенаправление, WinHTTP требует, чтобы приложение предоставило WinHTTP разрешение на автоматическое перенаправление в этом конкретном случае.
Чтобы перенаправить WinHTTP обратно на исходный URL-адрес после проверки подлинности, приложение должно зарегистрировать функцию обратного вызова с помощью WinHttpSetStatusCallback. Затем WinHTTP может уведомить приложение с помощью обратного вызова WINHTTP_CALLBACK_STATUS_REDIRECT, что позволяет приложению отменить перенаправление. Приложению не требуется предоставлять какие-либо функции в функции обратного вызова; регистрация обратного вызова достаточна, чтобы разрешить WinHTTP следовать этому специальному перенаправлению.
Сообщение ERROR_WINHTTP_LOGIN_FAILURE создается, если функция обратного вызова не задана приложением.
Passport Cobranding
В отличие от традиционных схем проверки подлинности, поддерживаемых WinHTTP, Passport может быть широко кобрендирован. Получив код состояния 401, указывающий на проблему, приложение может получить кобрендинговый рисунок и текст. Получите URL-адрес для кобрендингового рисунка, вызвав WinHttpQueryOption с флагом WINHTTP_OPTION_PASSPORT_COBRANDING_URL. Получите cobranding текст, вызвав WinHttpQueryOption с флагом WINHTTP_OPTION_PASSPORT_COBRANDING_TEXT. Эти элементы можно использовать для настройки диалогового окна сбора учетных данных.
Сохранение имен пользователей и паролей
Windows XP представила концепцию сохраненных имен пользователей и паролей. Если учетные данные пользователя Passport сохраняются с помощью мастера регистрации паспортов или стандартного диалогового окна учетных данных, он сохраняется в сохраненных именах пользователей и паролях. При использовании WinHTTP в Windows XP или более поздней версии WinHTTP автоматически использует учетные данные в сохраненных именах пользователей и паролях, если учетные данные не заданы явным образом. Это похоже на поддержку учетных данных входа по умолчанию для NTLM/Kerberos. Однако использование учетных данных Passport по умолчанию не распространяется на параметры политики автоматического входа.
Отключение проверки подлинности passport
Для некоторых приложений может потребоваться возможность отключить проверку подлинности Passport. Например, если филиал Passport отвечает с исходным кодом состояния 302, предпочтительнее следовать указанному перенаправлению и отображать страницу проверки подлинности HTML Passport, а не разрешить WinHTTP обрабатывать проверку подлинности внутри организации. Проверка подлинности passport отключена в WinHTTP путем вызова функции WinHttpSetOption с параметром WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH и передачи значения WINHTTP_DISABLE_PASSPORT_AUTH. Позже его можно снова включить с помощью WINHTTP_ENABLE_PASSPORT_AUTH.
Проверка подлинности passport не может быть отключена при использовании объекта WinHttpRequest .
Как отмечалось ранее в этом разделе, проверка подлинности Passport по умолчанию отключена в WinHTTP 5.1 и должна быть явно включена с помощью WinHttpSetOption перед использованием.
Переопределения конфигурации passport, используемые для тестирования
WinHTTP использует сведения о конфигурации, которые он загружает с сервера nexus passport для поддержки проверки подлинности Passport 1.4. По умолчанию этот защищенный сервер (SSL) является nexus.passport.com, а ресурс конфигурации — rdr/pprdr.asp, который называется «динамической» конфигурацией паспорта. Формат сведений — это настраиваемый заголовок HTTP PassportURLs, за которым следуют пары атрибутов с разделителями-запятыми.
Например: «https://nexus.passport.com/rdr/pprdr.asp» возвращает следующие сведения о конфигурации:
PassportURLs: DARealm=Passport.net, DALogin=login.passport.com/login2.asp, DAReg=https://register.passport.com/defaultwiz.asp, Properties=https://memberservices.passport.com/ppsecure/MSRV_EditProfile.asp, Privacy=https://www.passport.com/consumer/privacypolicy.asp, GeneralRedir=https://nexusrdr.passport.com/redir.asp, Help=https://memberservices.passport.com/UI/MSRV_UI_Help.asp, ConfigVersion=2 rn
Компоненты, относящиеся к WinHTTP, относятся DARealm, DALogin и ConfigVersion. По соображениям производительности они кэшируются в течение всего времени существования сеанса WinHTTP. Эти три значения можно переопределить приложениями, необходимыми для работы с другой инфраструктурой паспортов, отличной от рабочей настройки в режиме реального времени, изменив соответствующие параметры реестра в разделе
HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Internet Settings WinHttp Passport Test
LoginServerRealm (REG_SZ) For example: abc.net LoginServerUrl (REG_SZ) For example: https://private-login.passport.com/login2.asp ConfigVersion (REG_DWORD) For example: 10
Если LoginServerUrl присутствует в реестре, WinHTTP не обращается к серверу Nexus для других значений конфигурации. В этом случае для исправления значений следует также задать LoginServerRealm и ConfigVersion с помощью реестра.
Приложение может потребоваться для тестирования, чтобы скачать конфигурацию паспорта с частного сервера Nexus. Это можно сделать, переопределив два значения реестра в разделе
HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Internet Settings WinHttp Passport Test
NexusHost (REG_SZ) e.g. private-nexus.passport.com NexusObj(REG_SZ) e.g. config/passport.asp
Источник: learn.microsoft.com
Как работает Passport.js
PassportJS — это middleware для авторизации под node.js. Passport поддерживает авторизацию с помощью огромного количества сервисов, включая «ВКонтакте» и прочие твиттеры. Список сервисов можно просмотреть здесь. Я хочу немного рассказать о том, как работает этот middleware на примере самой обычной авторизации с помощью логина и пароля.
Для самых нетерпеливых — готовый проект можно посмотреть здесь.
Зависимости:
- «express»: «3.3.7»,
- «passport»: «~0.1.17»,
- «passport-local»: «~0.1.6»,
- «mongoose»: «~3.8.0»,
Так же я буду использовать для удобства несколько дополнительных утилит. Без них вполне можно обойтись:
- «jade»: «*»
- «bootable»: «~0.1.0»
- «nconf»: «~0.6.8»
- «require-tree»: «~0.3.2»
- «winston»: «~0.7.2»
Модель пользователя
Для начала, я думаю, можно создать модель пользователя:
var UserSchema = new mongoose.Schema(< username: < type: String, unique: true, required: true >, password: < type: String, required: true >, >); mongoose.model(‘user’, UserSchema);
Здесь можно было бы посолить пароль, и добавить немного магии безопасности для бога безопасности, но я оставляю это на вас =).
Стратегия авторизации
Верификация
Подключим и настроим стратегию авторизации.
var passport = require(‘passport’); var LocalStrategy = require(‘passport-local’).Strategy; passport.use(new LocalStrategy(< usernameField: ’email’, passwordField: ‘password’ >, function(username, password,done)< User.findOne(< username : username>,function(err,user)< return err ? done(err) : user ? password === user.password ? done(null, user) : done(null, false, < message: ‘Incorrect password.’ >) : done(null, false, < message: ‘Incorrect username.’ >); >); >));
LocalStrategy принимает 2 параметра: объект с опциями и middleware для верификации пользователя.
По-умолчанию, если в `LocalStrategy` не передавать никаких опций — стратегия будет искать параметры для авторизации пользователя в формах с именами `username` и `password`. При желании, можно указать свои имена форм, как я, собственно, и сделал.
Второй аргумент — middleware — принимает параметры `username`, `passport` и `done`. В done, вторым аргументом, передаем объект пользователя, если такой есть.
Привязка авторизации к пользователю
В типичном веб-приложении, учетные данные, используемые для аутентификации пользователя будет передаваться только во время авторизации. Если все в порядке, и пользователь существует, то информация о нем сохраняется в сессию, а идентификатор сессии, в свою очередь, сохраняется в cookies браузера.
Каждый последующй запрос будет содержать cookies, с помощью которого passport сможет опознать пользователя, и достать его данные из сессии. Для того, чтобы сохранять или доставать пользовательские данные из сессии, паспорт использует функции `passport.serializeUser()` и `passport.deserializeUser()`.
passport.serializeUser(function(user, done) < done(null, user.id); >); passport.deserializeUser(function(id, done) < User.findById(id, function(err,user)< err ? done(err) : done(null,user); >); >);
Подключение Passport к Express
Окей, с этим разобрались, теперь нужно подключить Passport к Express:
// Middlewares, которые должны быть определены до passport: app.use(express.cookieParser()); app.use(express.bodyParser()); app.use(express.session(< secret: ‘SECRET’ >)); // Passport: app.use(passport.initialize()); app.use(passport.session());
Создание роутера и контроллеров
Настало время настройки роутера. Привяжем запросы к соответствующим контроллерам:
// Auth system app.post(‘/login’, controllers.users.login); app.post(‘/register’, controllers.users.register); app.get(‘/logout’, controllers.users.logout);
Теперь создадем сами контроллеры:
// Здесь мы проверяем, передаем данные о пользователе в функцию верификации, котоую мы определили выше. // Вообще, passport.authenticate() вызывает метод req.logIn автоматически, здесь же я указал это явно. Это добавляет удобство в отладке.
Например, можно вставить сюда console.log(), чтобы посмотреть, что происходит. // При удачной авторизации данные пользователя будут храниться в req.user module.exports.login = function(req, res, next) < passport.authenticate(‘local’, function(err, user, info) < return err ? next(err) : user ? req.logIn(user, function(err) < return err ? next(err) : res.redirect(‘/private’); >) : res.redirect(‘/’); > )(req, res, next); >; // Здесь все просто =) module.exports.logout = function(req, res) < req.logout(); res.redirect(‘/’); >; // Регистрация пользователя. Создаем его в базе данных, и тут же, после сохранения, вызываем метод `req.logIn`, авторизуя пользователя module.exports.register = function(req, res, next) < var user = new User(< username: req.body.email, password: req.body.password>); user.save(function(err) < return err ? next(err) : req.logIn(user, function(err) < return err ? next(err) : res.redirect(‘/private’); >); >); >;
Проверка авторизации
Проверку авторизации можно делать с помощью req.isAuthenticated(). Я вынесу проверку в middleware.
exports.mustAuthenticatedMw = function (req, res, next)< req.isAuthenticated() ? next() : res.redirect(‘/’); >;
И добавлю в routes.
App.all(‘private’, mustAuthenticatedMw); App.all(‘private/*’, mustAuthenticatedMw);
HTML
Осталось создать форму регистрации, авторизации, и кнопку логаута.
h4 Register your account form(action=’/register’ method=’post’) fieldset label(for=’email’) Email input(type=’email’ name=’email’ placeholder=’Your Email’) label(for=’password’) Password input(type=’password’ name=’password’ placeholder=’Your Password’) button(type=’Register’)
h4 Login to your account form(action=’/login’ method=’post’) fieldset label(for=’email’) Email input(type=’email’ name=’email’ placeholder=’Your Email’) label(for=’password’) Password input(type=’password’ name=’password’ placeholder=’Your Password’) button(type=’Login’)
a(href=’/logout’) logout
Чтож, можно запускать и проверять работу. Чтобы не переписывать сотни кода можно форкнуть репозиторий на GitHub.
Источник: habr.com
Аутентификация Node-приложений при помощи Passport
Agraj Mangal Last updated Jun 22, 2022
Read Time: 12 min
Реализация надежной стратегии аутентификации для любого приложения может быть чрезвычайно трудной задачей, и Node-приложения не являются исключением.
В данном руководстве мы разработаем приложение Node.js с нуля и будем использовать новое, но очень популярное промежуточное ПО (* программное обеспечение. Здесь и далее прим. пер.) для реализации аутентификации — Passport для решения наших вопросов по аутентификации.
В документации по Passport оно описывается как «простое нетребовательное промежуточное ПО для реализации аутентификации Node-приложений», и по делу.
Поставляясь в виде промежуточного ПО, Passport отлично справляется с разделением вопросов аутентификации от остальных. Благодаря этому Passport можно легко встраивать в любое веб-приложение на основе Express так же легко как мы встраиваем другое промежуточное ПО для Express, например, для обеспечения входа в систему, разбора тела запроса, разбора куки, реализации сессии и т.д.
В руководстве предполагается, что у вас имеются базовые представления о Node.js и фреймворке Express, и делается попытка сосредоточить внимание на реализации аутентификации, хотя мы и создадим образец приложения Express с нуля и усовершенствуем путем добавления в него маршрутов и реализации аутентификации для некоторых из них.
Стратегии аутентификации
Passport предоставляет нам возможность выбора из более чем 140 способов аутентификации. Вы можете реализовать аутентификацию при помощи локального/удаленного экземпляра базы данных, или использовать SSO (* single sign-on – технологию единого входа) при помощи провайдеров OAuth (* открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль) для Facebook, Twitter, Google и т.д. для аутентификации пользователей с помощью их аккаунтов в социальных сетях, или же вы можете выбрать из обширного списка провайдеров, которые поддерживают аутентификацию при помощи Passport и предоставляют для этого соответствующий модуль Node.
Но не переживайте: вам нет необходимости подключать какие-либо стратегии, которые не нужны для вашего приложения. Все эти стратегии независимы друг от друга и реализованы в виде отдельных модулей Node, которые не подключаются по умолчанию при установке Passport при помощи npm install passport.
В данном руководстве мы будем использовать локальную стратегию аутентификации Passport и проводить аутентификацию пользователей при помощи локально настроенного экземпляра MongoDB, сохраняя данные пользователей в базу данных. Для использования локальной стратегии аутентификации нам необходимо установить модуль passport-local при помощи npm install passport-local.
Но погодите: Перед тем как вы запустите вашу консоль и начнете выполнять эти команды, давайте начнем с создания приложения Express с нуля и добавим несколько маршрутов в него (для входа в приложение, регистрации и главной страницы) и затем попробуем добавить в него наше промежуточное ПО для реализации аутентификации. Обратите внимание, что для целей данного руководства мы будем использовать Express 4, однако с небольшими поправками Passport также будет работать и с Express 3.
Установка приложения
Если вы еще этого не сделали, то установите Express и express-generator для создания шаблона приложения просто при помощи выполнения в консоли express passport-mongo. Структура созданного приложения должна выглядеть следующим образом:
Давайте уберем некоторые функциональные возможности, которые мы не будем использовать: удалите файл u sers.js и уберите ссылки на него из файла app.js.
Добавление зависимостей проекта
Откройте package.json и добавьте зависимости для модулей passport и passport-local.
«passport»: «~0.2.0»,
«passport-local»: «~1.0.0»
Поскольку мы будем сохранять данные пользователей в MongoDB, то будем использовать Mongoose (* ODM (Object Document Mapper – объектно-документный отобразитель)) в качестве инструмента для моделирования объектных данных. Другим способом установки и сохранения зависимостей в package.json является выполнение:
npm install mongoose —save
package.json должен выглядеть следующим образом:
Теперь установите все зависимости и запустите шаблон приложения, выполнив в консоли npm install npm start . В результате этого будут загружены и установлены все зависимости и запустится сервер Node. Вы можете ознакомиться с базовым приложением Express по адресу http://localhost:3000/, однако там не на что смотреть.
Очень скоро мы изменим это, создав полноценное приложение Express, которое предоставляет страницу регистрации для нового пользователя, страницу входа для зарегистрированного пользователя и осуществляет аутентификацию зарегистрированного пользователя при помощи Passport.
Создание модели Mongoose
Поскольку мы будем сохранять данные пользователя в Mongo, то давайте создадим модель User в Mongoose и сохраним ее в models/user.js нашего приложения.
var mongoose = require(‘mongoose’);
Источник: code.tutsplus.com