Микросервисная авторизация для чайников для чайников

Начало

Вся эта функциональность уже реализована для ASP.NET Core — проект с открытым исходным кодом под названием Identity 3.0. Для настройки окружения вам понадобится установить:

• Visual Studio 2015;
• Update 3 для VS 2015;
• .NET Core tools for Visual Studio.

Инструкцию по установке и ссылки можно найти .

Для включения функционала Identity создадим проект ASP.NET Core Web Application по шаблону Web Application и в качестве типа аутентификации выберем Individual User Accounts.

В проект будет добавлен пакет Microsoft.AspNetCore.Identity.EntityFrameworkCore, который будет сохранять данные и схемы в SQL Server для Entity Framework Core.

Также этот пакет можно добавить через NuGet Package Manager.

Или же дописав соответствующие зависимости в файле project.json в узлах dependencies и tools.

После сохранения файла в проект автоматически будут добавлены указанные пакеты. Но в этом случае для работы приложения необходимо будет самому настроить строку подключения и работу с базой данных.

Как это работает

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

В ASP.NET Core за настройку обработки запросов отвечает метод Configure класса Startup. При создании проекта с использованием шаблона по умолчанию в этот метод добавится строка отвечающая за аутентификацию для потока запросов, основанную на куки.

Также в метод ConfigureServices этого же класса Startup будут добавлены Identity сервисы.

Это позволит использовать их в приложении с помощью встроенной системы внедрения зависимостей.

Теперь при обработке каждого запроса будет проводиться аутентификация пользователя. А авторизацию будет контролировать атрибут Authorize, который можно добавить перед контроллером и отдельным методом в MVC фреймворке.

ASP.NET Core был сильно изменен по сравнению с прошлыми версиями, не остался в стороне и Identity 3.0. Структура БД для Identity 3.0 имеет следующий вид:

Появились две новые таблицы: AspNetRoleClaims и AspNetUserTokens. Пользователи и роли, как и ранее, представлены классами IdentityUser и IdentityRole соответственно. Но теперь они не наследуются от интерфейсов для пользователей и ролей, что очень удобно. Также появились новые инструменты авторизации — политики.

Политика — это одно или несколько требований, необходимых пройти пользователю для авторизации.

Пример

Пусть для доступа к некоторому ресурсу в приложении пользователь должен иметь российское гражданство. Для начала зарегистрируем политику RussianСitizenship в ConfigureService файла startup.cs:

Для регистрации политики мы использовали RussianСitizenshipRequirement в качестве авторизационного требования — параметры данных, которые использует политика для оценки текущего пользователя. В нашем случае есть лишь один параметр — гражданство. Для создания требования нужно реализовать интерфейс IAuthorizationRequirement:

Далее создадим обработчик авторизации, который и будет оценивать свойства требования для принятия решения об авторизации:

Добавим в HomeController метод RussianPage () c атрибутом Authorize:

Готово, доступ к этому методу получат лишь пользователи, удовлетворяющие требованиям данной политики.

Подготовка к реализации системы аутентификации

Даже несмотря на то, что наш запрос на данный момент заканчивается ошибкой, мы наглядно показали как вписывается Identity в жизненный цикл приложения ASP.NET. Следующий шаг — создать контроллер, обрабатывающий запрос к URL /Account/Login, для отображения формы входа в приложение. Добавьте сначала новый класс view-model в файл UserViewModels.cs:

Новый класс модели содержит свойства Name и Password, декларированные атрибутом Required, который говорит системы валидации модели, что эти свойства не должны иметь пустых значений. В реальном проекте не забывайте также добавлять клиентскую проверку при вводе пользователем имени и пароля. В данном проекте мы пропустим эту проверку, т. к. основная наша цель — разобраться в ASP.NET Identity.

Теперь добавьте контроллер Account в наше приложение, с кодом, показанным в примере ниже, который содержит две перегруженные версии метода Login

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

Хотя этот код еще не относится к аутентификации пользователей, контроллер Account все же содержит некоторую полезную инфраструктуру, не относящуюся к ASP.NET Identity.

Во-первых, обратите внимание, что оба метода Login принимают строковый аргумент returnUrl. Когда пользователь запрашивает URL-адрес с ограниченным доступом, он перенаправляется по адресу /Account/Login со строкой запроса, содержащей адрес страницы с ограниченным доступом

Например, если сейчас вы запросите адрес /Home/Index, вас перенаправит на URL следующего вида:

/Account/Login?ReturnUrl=%2FHome%2FIndex

С помощью параметра ReturnUrl мы сможем перенаправить пользователя, успешно прошедшего аутентификацию, на страницу, с которой он пришел. Это обеспечивает простой и понятный процесс навигации пользователя в приложении при аутентификации.

Далее обратите внимание на атрибуты, которые я применил к контроллеру и его методам действий. Функции контроллера Account (такие как смена пароля, например) по умолчанию должны быть доступны только авторизованным пользователям

Для этого мы применили атрибут Authorize к контроллеру Account и добавили атрибут AllowAnonymous к некоторым методам действий. Это позволяет ограничить методы действий для авторизованных пользователей по умолчанию, но открыть доступ неавторизованным пользователям для входа в приложение.

Наконец, мы добавили атрибут ValidateAntiForgeryToken который работает в связке с классом HtmlHelper, используемом в Razor в представлениях cshtml. Вспомогательный метод AntiForgeryToken защищает от межсайтовой подделки запросов CSRF, благодаря тому, что генерирует скрытое поле формы с токеном, который проверяется при отправке формы.

Последний подготовительный шаг — создание формы входа в приложение. Добавьте в папку /Views/Account файл представления Login.cshtml:

В этой разметке стоит обратить внимание на использование вспомогательного метода Html.AntiForgeryToken и создание скрытое поля с сохранением параметра returnUrl. В остальном — это обычная форма, генерируемая с помощью Razor

Итак, мы завершили подготовку к созданию системы аутентификации. Запустите приложение и перейдите по адресу /Home/Index – система перенаправит вас на страницу входа:

Методы, используемые для авторизации: с аутентификацией и без

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

По СМС

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

Через социальные сети

Еще один способ авторизовать Wi-Fi — использование социальных сетей. Чаще всего для аутентификации используют Instagram или Facebook. Зарегистрировавшись при помощи аккаунта в соцсети, не придется оставлять свой номер телефона или другие персональные данные.

По ваучерам

Ваучер — это специальная электронная карточка, в которой содержатся номер телефона пользователя, его паспортные данные, а также логин с паролем. Чаще всего такой метод авторизации используется в гостиницах.

Спойлер второй части

Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:

public void Configuration(IAppBuilder app)  {      var factory = new IdentityServerServiceFactory();      factory.UseInMemoryClients(Clients.Get())             .UseInMemoryScopes(Scopes.Get())             .UseInMemoryUsers(Users.Get());        var options = new IdentityServerOptions      {          SiteName = Constants.IdentityServerName,          SigningCertificate = Certificate.Get(),          Factory = factory,      };        app.UseIdentityServer(options);  }

Минимальная реализация интеграции веб-клиента с Identity Server:

public void Configuration(IAppBuilder app)  {      app.UseCookieAuthentication(new CookieAuthenticationOptions      {          AuthenticationType = "Cookies"      });        app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions      {          ClientId = Constants.ClientName,          Authority = Constants.IdentityServerAddress,          RedirectUri = Constants.ClientReturnUrl,          ResponseType = "id_token",          Scope = "openid email",          SignInAsAuthenticationType = "Cookies",      });  }

Минимальная реализация интеграции веб-API с Identity Server:

Использование смарт-карт и USB-ключей

  Несмотря на то, что криптография с открытым ключом согласно спецификации Х.509 может обеспечивать строгую аутентификацию пользователя, сам по себе незащищенный закрытый ключ подобен паспорту без фотографии. Закрытый ключ, хранящийся на жёстком диске компьютера владельца, уязвим по отношению к прямым и сетевым атакам. Достаточно подготовленный злоумышленник может похитить персональный ключ пользователя и с помощью этого ключа представляться этим пользователем. Защита ключа с помощью пароля помогает, но недостаточно эффективно -пароли уязвимы по отношению ко мно¬гим атакам. Несомненно, требуется более безопасное хранилище.

Смарт-карты

  Смарт-карты — пластиковые карты стандартного размера банковской карты, имеющие встроенную микросхему. Они находят всё более широкое применение в различных областях, от систем накопительных скидок до кредитных и дебетовых карт, студенческих билетов и телефонов стандарта GSM.

  Для использования смарт-карт в компьютерных системах необходимо устройство чтения смарт-карт. Несмотря на название — устройство чтения (или считыватель), — большинство подобных оконечных устройств, или устройств сопряжения (IFD), способны как считывать, так и записывать информацию, если позволяют возможности смарт-карты и права доступа. Устройства чтения смарт-карт могут подключаться к компьютеру посредством последовательного порта, слота PCMCIA или USB. Устройство чтения смарт-карт также может быть встроено в клавиатуру. Как правило, для доступа к защищенной информации, хранящейся в памяти смарт-карты, требуется пароль, называемый PIN-кодом.

USB-ключи

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

  Аутентификацию на основе смарт-карт и USB-ключей сложнее всего обойти, так как используется уникальный физический объект, которым должен обладать человек, чтобы войти в систему. В отличие от паролей, владелец быстро узнаёт о краже и может сразу принять необходимые меры для предотвращения её негативных последствий. Кроме того, реализуется двухфакторная аутентификация. Микропроцессорные смарт-карты и USB-ключи могут повысить надёжность служб PKI: смарт-карта может использоваться для безопасного хранения закрытых ключей пользователя, а также для безопасного выполнения криптографических преобразований. Безусловно, данные устройства аутентификации не обеспечивают абсолютную безопасность, но надёжность их защиты намного превосходит возможности обычного настольного компьютера.

  Для хранения и использования закрытого ключа разработчики используют различные подходы. Наиболее простой из них — использование устройства аутентификации в качестве защищенного носителя аутентификационной информации: при необходимости карта экспортирует закрытый ключ, и криптографические операции осуществляются на рабочей станции. Этот подход является не самым совершенным с точки зрения безопасности, зато относительно легко реализуемым и предъявляющим невысокие требования к устройству аутентификации. Два других подхода более безопасны, поскольку предполагают выполнение устройством аутентификации криптографические операций. При первом пользователь генерирует ключи на рабочей станции и сохраняет их в памяти устройства. При втором пользователь генерирует ключи при помощи устройства. В обоих случаях, после того как закрытый ключ сохранён, его нельзя извлечь из устройства и получить любым другим способом.

Что такое идентификация?

Предположим, что есть определенная система или база данных, где содержится ряд из параметров (идентификаторов), например:

• ID пользователя;
• ФИО (фамилия, имя и отчество);
• номер телефона;
• IMEI-устройства;
• адрес электронной почты;
• логин (никнейм);
• реквизиты банковской карты;
• номер автомобиля;
• серийный номер (штрих-код);
• трек-номер;
• смарт-карта;
• адрес веб-сайта;
• и т. д.

Каждый раз, когда что-либо покупаете в Интернете, где-либо регистрируетесь, Вы получаете идентификатор — определенный параметр позволяющий взаимодействовать с системой. Как правило, он является уникальным — не пересекается с другими информационными системами, участниками и пользователями. Таким образом, при необходимости получить доступ к системе или узнать какие-либо сведения, потребуется предоставить один или несколько идентификаторов. Исходя из этого, можно сказать, что идентификации — процесс позволяющий однозначно определить (распознать) субъект или объект, по его идентификатору, в той или иной системе.

Для большего понимания давайте рассмотрим на примере простой ситуации. Вы находитесь дома, занимаетесь своими делами: смотрите фильмы для взрослых, делаете физические упражнения или читаете статью про кибербезопасность на моём сайте. В один момент Вы слышите звонок в дверь, прекращаете заниматься своей деятельностью и направляетесь открывать. Подойдя к двери смотрите в глазок, но никого не видите, спрашиваете: «Кто там?» и слышите в ответ: «Это я, ИМЯ человека!». Имя человека по ту стороны двери, в данной ситуации, является идентификатором. Правильный или неправильный ответ на вопрос — процесс идентификации.

Рассмотрим на примере другой ситуации. Вы совершаете звонок в банк с целью получить какую-либо информацию по Вашей банковской карте. Сотрудник, отвечающий на Ваш звонок, прежде чем предоставить информацию, обязан Вас идентифицировать. Помимо номера телефона, он может запросить у Вас другой идентификатор, например, номер банковской карты или ФИО. Ваш ответ, в данном случае — идентификация.

Переход на защищенные технологии идентификации

Чем заменить устаревшие Proximity карты в действующей системе СКУД

Актуальность

Количество объектов, на которых функционируют системы контроля доступа с незащищенной технологией идентификации исчисляется десятком тысяч. Несмотря на поступательное развитие технологий в современных системах контроля доступа в качестве идентификатора используются карты, работающие по открытому протоколу передачи данных на частоте 125 кГц, выпускаемые под марками EM Marin (EM4100, EM4102, TK4100), HID Prox и Indala.

О нецелесообразности использования proximity карт для организации СКУД в материалах уязвимость технологий считывания и повторное воспроизведение карт доступа.

Миграция с технологии Proximity на защищенные технологии

Лидеры средств идентификации предлагают различные способы апгрейда систем. Самые распространенные из них:

Использование мультитехнологичных карт, которые поддерживают различные технологии идентификации.

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

Переход с карты на смарт-карту или с карты на биометрическую карту?

На выставке ISC West, которая прошла с 15 по 17 апреля в Лас-Вегасе, разработчик и производитель средств аутентификации по отпечаткам пальцев, компания Zwipe продемонстрировала биометрические решения, в которых используется биометрическая карта. Достоинством решения является возможность усиления уровня защищенности системы без установки биометрических считывателей, используя установленные на объекте считыватели смарт-карт.

Как это работает? На биометрической карте установлен сканер отпечатков пальцев с 3D-технологией, а также RFID-чип, который обеспечивает поддержку популярных технологий согласно стандарту ISO 14443, включая бесконтактные карты DESFire EV1 и MIFARE Classic. Таким образом, Zwipe предлагает экономный способ обновления действующих систем контроля доступа и перехода с устаревших проксимити карт на биометрию.

ISO 14443

Стандарт регламентирует работу бесконтактных смарт-карт, описывает частотный диапазон, метод модуляции и протокол обмена бесконтактных пассивных карт (RFID) ближнего радиуса действия (до 10 см) на магнитосвязанных индуктивностях. Существует аутентичный перевод стандарта на русский язык (ГОСТ Р ИСО/МЭК 14443).

Материал из Википедии — свободной энциклопедии

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

Материал спецпроекта «Без ключа»

Спецпроект «Без ключа» представляет собой аккумулятор информации о СКУД, конвергентном доступе и персонализации карт

Какие существуют виды двухфакторной аутентификации?

Скорее всего Вы уже ни один раз сталкивались с двухэтапной проверкой, например, когда пытались зайти на страницу в социальной сети с другого компьютера или телефона и в этот момент, сервис подозревая о сомнительной активности, запрашивал у Вас проверочный код, который был отправлен на телефон. Это лишь одна из форм представления 2FA, а в целом они более многогранны и могут быть реализованы, как:

• имя пользователя и пароль + наличие специального ПИН-кода из SMS-сообщения, электронной почты или мобильного приложения — данный вариант самый простой по реализации и самый популярный среди других;
• имя пользователя и пароль + фотография – это означает, что при попытке входа делается фотография с помощью веб-камеры и отправляется на доверенное устройство (мобильный телефон, планшет, ноутбук). Все, что остается – на втором устройстве подтвердить подлинность сделанной фотографии или отклонить, тем самым заблокировав доступ для злоумышленника;
• имя пользователя и пароль + визуальная метка – в случае, если отсутствует веб-камера на компьютере или нет желания себя фотографировать, можно пройти двухфакторную аутентификацию другим способом. Визуальная метка – формирует уникальный визуальный код, который вычисляется по определенному алгоритму и отображается у пользователя на двух устройствах одновременно, позволяя пройти аутентификацию путем проверки подлинности кодов;
• имя пользователя и пароль + биометрика (отпечаток пальца, геометрия руки, сетчатка или радужная оболочка глаза, лицо, голос) – при получении доступа к системе, отправляется уведомление на соответствующее устройство, где от пользователя потребуется предоставить необходимый биометрический параметр;
• имя пользователя и пароль + аппаратное устройство (USB-накопитель, смарт-карта, токен, ключ) – для прохождения двухфакторной аутентификации потребуется вставить в персональный компьютер ключ доступа, или приложить карту к специальному считывателю, или же синхронизировать токен, например, через Bluetooth. В качестве примера, можно выделить такие электронные ключи, как USB-токены и смарт-карты JaCarta PKI от российского разработчика «Аладдин Р.Д.», которые и предназначены для двухфакторной аутентификации пользователей;
• имя пользователя и пароль + метаданные – аутентификация пользователя осуществляет только при соответствии всех необходимых параметров. В частности учитывается, местоположение посредством GPS. Пользователь, имеющий аппаратуру GPS, многократно посылает координаты заданных спутников, находящихся в зоне прямой видимости. Подсистема аутентификации, зная орбиты спутников, может с точностью до метра определить месторасположение пользователя. Также может учитываться время, например, выполнить вход в систему можно в период с 8:00 до 9:00, в иное время – доступ заблокирован. Как альтернатива — полная привязка к операционной системе и компонентам устройства, т. е. фиксируется IP-адрес и устройство (операционная система, программы и т. д.).

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

Многофакторная аутентификация

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

Среди видов многофакторной аутентификации наиболее распространена двухфакторная аутентификация (2FA — 2-factor authentication) – метод, при котором пользователю для получения доступа необходимо предоставить два разных типа аутентификационных данных, например, что-то известное только пользователю (пароль) и что-то присущее только пользователю (отпечаток пальца).

Доступ к ресурсам через ввод логина и пароля, является однофакторной аутентификацией, поскольку для входа используется только один тип аутентификационных данных — известный пользователю пароль.

Одноразовые пароли

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

На данный момент одним из наиболее популярных программных генераторов одноразовых паролей является система под названием S/KEY, выпущенная компанией Bellcore. Основная концепция этой системы заключается в том, что имеется определенная функция F, которая известна как пользователю, так и серверу аутентификации. Далее представлен секретный ключ К, который известен только определенному пользователю.

При начальном администрировании пользователя данная функция используется к ключу определенное количество раз, после чего происходит сохранение полученного результата на сервере. В дальнейшем процедура проверки подлинности выглядит так:

1. На пользовательскую систему от сервера приходит число, которое на 1 меньше количества раз использования функции к ключу.
2. Пользователем используется функция к имеющемуся секретному ключу то количество раз, которое было установлено в первом пункте, после чего результат отправляется через сеть непосредственно на сервер аутентификации.
3. Сервером используется данная функция к полученному значению, после чего результат сравнивается с сохраненной ранее величиной. Если результаты совпадают, то в таком случае подлинность пользователя является установленной, а сервер сохраняет новое значение, после чего снижает счетчик на единицу.

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

В России в качестве объединенного сервиса используется специальный государственный портал – «Единая система идентификации/аутентификации» («ЕСИА»).

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

Взаимосвязь идентификации, аутентификации и авторизации

Наверное, вы уже догадались, что все три процедуры взаимосвязаны:

1. Сначала определяют имя (логин или номер) – идентификация
2. Затем проверяют пароль (ключ или отпечаток пальца) – аутентификация
3. И в конце предоставляют доступ – авторизация

Инфографика: 1 — Идентификация; 2 — Аутентификация; 3 — Авторизация

Проблемы безопасности при авторизации

Помните, как в сказке «Красная Шапочка» бабушка разрешает внучке войти в дом? Сначала бабушка спрашивает, кто за дверью, затем говорит Красной Шапочке, как открыть дверь. Волку же оказалось достаточным узнать имя внучки и расположение дома, чтобы пробраться в дом.

Какой вывод можно сделать из этой истории?

Каждый этап авторизации должен быть тщательно продуман, а идентификатор, пароль и сам принцип авторизации нужно держать в секрете.