Аутентификация пользователей через Веб-интерфейс


Оглавление (нажмите, чтобы открыть):

Web-аутентификация в ProCurve

Материал из Xgu.ru

Содержание

[править] Принцип работы

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

Если на порту включена Web-аутентификация, то клиент не может использовать прокси-сервер в браузере.

[править] Процедура Web-аутентификации

  1. Пользователь открывает браузер и заходит на домашнюю страницу Web-аутентификатора (по умолчанию https://192.168.0.1);
  2. Коммутатор автоматически возвращает пользователю страницу с запросом имени пользователя и пароля;
  3. Пользователь вводит логин и пароль;
  4. Коммутатор отправляет запрос на RADIUS-сервер;
  5. Если такой пользователь существует и ему разрешен доступ, то коммутатор авторизует порт.

Аутентификация может происходить как по протоколу HTTP, так и по протоколу HTTPS.

В коммутаторе есть «mini» DHCP-, ARP- и DNS-сервера для осуществления Web-аутентификации:

  • DHCP-сервер — выдает временный адрес клиенту, для того чтобы он мог пройти аутентификацию. По умолчанию клиент получает в аренду на 10 секунд адрес из сети 192.168.0.0/24 (время аренды и сеть можно изменять);
  • ARP-сервер — коммутатор будет возвращать на все ARP-запросы клиента в MAC-адрес коммутатора;
  • DNS-сервер — до тех пор пока клиент не пройдет аутентификацию, DNS-сервер коммутатора будет все запросы клиента преобразовывать в адрес коммутатора.

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

[править] Подготовка к использованию Web-аутентификации

Шаги по подготовке к использованию Web-аутентификации:

  • Определить на каких портах будет включена Web-аутентификация;
  • Определить какие VLAN’ы будут использоваться — если устройство должно после прохождения попасть в какой-то VLAN, то этот VLAN должен быть создан на коммутаторе;
  • Определить каким образом будет порт назначаться в VLAN:
    • динамически через RADIUS-сервер,
    • попадать в авторизованный VLAN на коммутаторе,
    • оставаться в статическом VLAN настроенном на порту;
  • Проверить, что CHAP включен на RADIUS-сервере — для Web-аутентификации коммутатор использует CHAP;
  • Проверить, что на RADIUS-сервере настроены политики доступа;
  • Проверить, что в базе данных пользователей есть нужные пользователи — для Web-аутентификации может использоваться та же база пользователей, что и для 802.1X аутентификации.

[править] Настройка Web-аутентификации

[править] Включение Web-аутентификации

Включение Web-аутентификации на портах 6-10:

Включение SSL (по умолчанию отключен):

[править] VLAN для авторизованных пользователей

По умолчанию такой VLAN не создан.

Указание VLAN’а для авторизованных пользователей. Для портов 6-10 авторизованный VLAN 100:

[править] Настройка дополнительных параметров

Указать URL на который пользователь будет перенаправлен после успешной процедуры аутентификации (по умолчанию никакого значения нет):

Задать сеть, которую коммутатор будет использовать для временной выдачи адреса клиенту во время Web-аутентификации (по умолчанию 192.168.0.0/24):

Задать время аренды адреса (по умолчанию 10 секунд, возможны значения от 5 до 25 секунд):

[править] Увеличение максимального количества авторизованных клиентов на порту

Указание максимального количества авторизованных клиентов на порту (по умолчанию 1):

Если на этих же портах настроена аутентификация 802.1X, то это максимальное ограничение на оба метода.

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

[править] Управление аутентифицированными клиентами

[править] Административная реаутентификация клиентов

Инициировать реаутентификацию клиентов на указанных портах:

[править] Перемещение клиентов

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

Позволить клиентам перемещаться между указанными портами (как минимум должны быть указаны два порта), на которых настроена Web-аутентификация:

[править] Изменение параметров и таймеров аутентификации

Описание значения этих параметров и таймеров приведено в разделе Параметры и таймеры аутентификации.

Интервал времени (logoff-period) после которого неактивная сессия обрывается (по умолчанию 300 секунд):

Интервал времени от момента прохождения аутентификации (reauth-period), по истечению которого клиент будет повторно аутентифицирован (по умолчанию 300 секунд):

Если установить этот интервал в 0, то реаутентификация будет отключена.

Количество попыток (max-retries) для пользователя ввести правильно имя и пароль (по умолчанию 3):

Время которое коммутатор ждет (quiet-period) прежде чем отправит повторный запрос на аутентификацию клиенту, который её не прошел (по умолчанию 60 секунд):

Количество запросов (max-requests) на RADIUS-сервер, если он недоступен (по умолчанию 2):

Интервал времени (server-timeout) в течении которого коммутатор ждет ответа от RADIUS-сервера (по умолчанию 30 секунд):

[править] Просмотр настроек

Посмотреть какие компьютеры (с какими MAC-адресами) подключены к портам с включенной Web-аутентификацией:

Посмотреть количество подключенных компьютеров, аутентифицированы они или нет, присвоенный номер VLAN, назначен ли ACL на порт:

Команды просмотра информации о Web-аутентификации:

Аутентификация с помощью ASP.NET >

Самым базовым средством работы с ASP.NET Identity является аутентификация пользователей, и в этой статье я покажу как ее использовать. Ниже собраны базовые вопросы, которые могут возникнуть у вас в данный момент:

Аутентификация — это проверка учетных данных, предоставляемых пользователем. После успешной аутентификации пользователя, во все последующие запросы добавляется cookie-файл с идентификатором пользователя.

Зачем нужно использовать?

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

Как использовать в рамках MVC?

В ASP.NET MVC используется атрибут авторизации, который применяется к контроллерам и методам действий для того, чтобы ограничить доступ неавторизованным пользователям.

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

Процесс аутентификации/авторизации

Платформа ASP.NET >атрибут Authorize. В этой статье мы ограничим доступ к методу действия Index контроллера Home и реализуем функции, которые позволят идентифицировать пользователей, чтобы они могли получить к нему доступ. В примере ниже я применил атрибут Authorize:

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

Платформа ASP.NET предоставляет полезную информацию о пользователе в объекте HttpContext, которую использует атрибут Authorize, чтобы проверить состояние текущего запроса и посмотреть, является ли пользователь аутентифицированным. Свойство HttpContext.User возвращает реализацию интерфейса IPrincipal, который определен в пространстве имен System.Security.Principal. Интерфейс IPrincipal определяет свойства и методы, перечисленные в таблице ниже:

Методы и свойства, определенные в интерфейсе IPrincipal

Возвращает реализацию интерфейса IIdentity, описывающую пользователя, связанного с запросом.

Возвращает true, если пользователь является членом указанной роли.

Интерфейс IIdentity, реализация которого возвращается свойством Iprincipal.Identity, также содержит несколько полезных свойств:

Название Описание
Identity
IsInRole(role)
Свойства интерфейса IIDentity

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

Возвращает true, если пользователь аутентифицирован.

Возвращает имя текущего пользователя.

ASP.NET Identity содержит модуль, который обрабатывает глобальное событие AuthenticateRequest жизненного цикла приложения в котором проверяет cookie в браузере пользователя, для определения того, является ли он аутентифицированным. Позже я покажу как используются эти cookie-файлы. Если пользователь аутентифицирован, ASP.NET задает свойству IIdentity.IsAuthenticated значение true. (В нашем приложении мы еще не реализовали функцию аутентификации, поэтому свойство IsAuthenticated будет всегда возвращать false.)

Модуль авторизации проверяет свойство IsAuthenticated и, если пользователь не прошел проверку, возвращает HTTP-статус 401 и завершает запрос. В этот момент модуль ASP.NET Identity перехватывает запрос и перенаправляет пользователя на страницу входа /Account/Login. Это URL-адрес, который я определил в классе IdentityConfig ранее:

Браузер перенаправит вас по адресу /Account/Login, но т. к. мы еще не добавили контроллер для этого запроса, появится ошибка 404.

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

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

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

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

Наконец, мы добавили атрибут Val >метод AntiForgeryToken защищает от , благодаря тому, что генерирует скрытое поле формы с токеном, который проверяется при отправке формы.

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

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

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

Аутентификация пользователей

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

Самая простая часть — это проверка учетных данных, которую мы делаем с помощью метода FindAsync класса AppUserManager:

В дальнейшем мы будем многократно обращаться к экземпляру класса AppUserManager, поэтому мы создали отдельное свойство UserManager, который возвращает экземпляр класса AppUserManager с помощью метода расширения GetOwinContext() класса HttpContext.

Метод FindAsync принимает в качестве параметров имя и пароль, введенные пользователем, и возвращает экземпляр класса пользователя (AppUser в примере) если учетная запись с такими данными существует. Если нет учетной записи с таким именем или пароль не совпадает, метод FindAsync возвращает значение null. В этом случае мы добавляем ошибку в метаданные модели, которая будет отображена пользователю. Claims >метода Create >перечислении DefaultAuthenticationTypes.

Следующий шаг — удаление всех старых аутентифицирующих файлов cookie и создание новых. Мы добавили свойство AuthManager в контроллере Account, которое возвращает объект, реализующий интерфейс IAuthenticationManager, который отвечает за выполнение аутентификации в ASP.NET Identity. В таблице ниже перечислено несколько полезных методов этого интерфейса:

Название Описание
AuthenticationType
IsAuthenticated
Наиболее полезные методы интерфейса IAuthenticationManager

Вход пользователя в систему, что фактически означает создание аутентифицирующего cookie-файла

Выход пользователя из системы, который обычно означает удаление файлов cookie

Аргументами метода SignIn являются объект AuthenticationProperties, определяющий свойства настройки процесса аутентификации и объект Claims >свойству IsPersistent объекта AuthenticationProperties значение true — это означает, что файлы cookie будут сохраняться между сессиями пользователей. Благодаря этому, если пользователь выйдет из приложения и зайдет, например, на следующий день, он будет автоматически аутентифицирован. (Есть и другие полезные свойства, определенные в классе AuthenticationProperties, но свойство IsPersistent является единственным, который широко используется на данный момент.)

После воссоздания файлов cookie мы перенаправляем пользователя по URL-адресу, который он просматривал до аутентификации (используя параметр returnUrl).

Давайте протестируем процесс аутентификации. Запустите приложение и перейдите по адресу /Home/Index. Браузер перенаправит вас на страницу входа, где необходимо ввести данные пользователя, которого мы создали ранее при тестировании панели администратора:

Двухфакторная аутентификация

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

Аутентификация пользователей через Веб-интерфейс

В статье рассматривается пример решения задачи по аутентификации и авторизации клиентов Web-сервера на сервере приложения, где под Web-сервером понимается работающее на нем приложение ASP.NET, а под сервером приложения – .NET-приложение. Взаимодействие осуществляется через .NET Remoting (TCP/Binary).

Исходные тексты:

Что есть интересного в рассматриваемом решении:

  • Использование серверных и клиентских специализированных канальных приемников.
  • Организация сессий на стороне сервера приложения и стороне Web-сервера
  • Установление зависимости между клиентом и его сессиями на Web-сервере и сервере приложения.
  • Организация авторизации без добавления дополнительных аргументов в методы сервера приложения.
  • «Протаскивание» пользовательских данных через все методы в потоке без добавления дополнительных аргументов в методы.

В статье не рассматриваются вопросы, связанные с защитой канала передачи данных. О шифровании трафика можно прочитать тут: https://msdn.microsoft.com/msdnmag/issues/03/06/netremoting/

Задача

Архитектура использования

На рисунке 1 изображена схема некоторой информационной системы (ИС)

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

Требования
  1. Web-сервер не должен иметь прямого доступа к ИС.
  2. ИСдолжна определять права пользователей на выполнение того или иного запроса (авторизованные и анонимные запросы).
  3. Права пользователей определяются их ролью в ИС.
Дополнительные ограничения

Все сервисы ИС реализованы на базе платформы MS Windows (не ниже MS Windows 2000).

Серверы приложений системы расположены в пределах одной локальной сети.

Решение

Архитектура решения

В соответствии с требованиями разрабатываем архитектуру, представленную на рисунке 2

Web-сервер — предоставляет доступ к ИС через Интернет посредством Web-интерфейса, который реализуется на технологии ASP.NET.

Сервер приложения для WEB — аутентифицирует пользователей, авторизует запросы пользователей, маршрутизирует запросы от Web-сервера к серверам ИС. Реализуются в виде .NET-приложения с возможностью удаленного вызова его методов.

База данных системы — хранит данные ИС.

Серверы приложений системы — совокупность сервисов, реализующих бизнес-логику ИС.

Firewall 1,2 — шлюзы, защищающие ИС от несанкционированного доступа.

Протоколы взаимодействия

На рисунке 3 изображена схема взаимодействия компонентов ИС и протоколы взаимодействия.

Интересующий нас участок цепи: Web-сервер — сервер приложения для Web. Мной выбран протокол взаимодействия .NET Remoting через TCP с бинарной сериализацией по причине высокой эффективности этого сочетания по сравнению с HTTP вместе с SOAP.

Идея решения

Идея решения состоит в реализации аутентификации на уровне канальных приемников (ChannelSink), встраиваемых в инфраструктуру канала Remoting на стороне клиента и сервера. Аутентификационная информация передается в заголовках запроса (TransportHeaders), результаты аутентификации передаются в заголовках ответа сервера. Авторизация выполняется с помощью декларативной проверки соответствия роли пользователя.

В случае успешной аутентификации на сервере приложения создается пользовательская сессия, в которой сохраняются пользовательские данные. Другая пользовательская сессия создается на Web-сервере, причем стандартный механизм сессий ASP.NET не используется, поэтому его можно отключить в web.config.

Сессии на сервере приложения и Web-сервере различны по содержанию, так как сервер приложения может хранить обязательные для каждого пользователя объекты, вполне возможно unmanaged (COM). Взаимосвязь между клиентом, Web-сервером и сервером приложения осуществляется по идентификатору сессии.

Развертывание

На рисунке 4 приведена диаграмма развертывания рассматриваемого решения.

Решение состоит из трех основных .NET-сборок, обеспечивающих процессы аутентификации, авторизации, поддержку сессий:

SecurityBase — сборка, содержащая общие для Web-сервера и сервера приложения типы и константы.

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

SecurityServer — сборка, содержащая типы для аутентификации и поддержки сессий на стороне сервера приложения.

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

На сервере приложения устанавливается полная версия BusinessFacade.

На Web-сервере и сервере приложения настраивается конфигурация Remoting.

На Web-сервере конфигурация содержится в Web.config

Не сервере приложения в ConsoleServer.exe.config:

Инициализация конфигурации Remoting на Web-сервере происходит в методе:

Инициализация на сервере приложения:

Диаграмма классов

На рисунке 5 приведена диаграмма используемых классов, в таблице 1 — краткое описание классов.

Название Описание
SignIn(options, identity)
Класс Сборка Описание
ServerSecurityContext SecurityServer Содержит пользовательские данные на стороне сервера приложения.
ServerChannelSinkProvider SecurityServer Провайдер канального приемника. Помещает канальный приемник в цепочку серверных канальных приемников.
ServerChannelSink SecurityServer Серверный канальный приемник. Аутентифицирует пользователей. Управляет состоянием сессии.
SecurityContextContainer SecurityBase Контейнер для пользовательских сессий.
ClientSecurityContext SecurityClient Содержит пользовательские данные на стороне Web-сервера.
ClientChannelSinkProvider SecurityClient Провайдер канального приемника на стороне Web- сервера.
ClientChannelSink SecurityClient Канальный приемник на стороне Web- сервера.
ChannelSinkHeaders SecurityBase Содержит названия заголовков аутентификации.
ISecurityContext SecurityBase Интерфейс для объектов, содержащих состояние сессии.

Аутентификация

На рисунке 6 изображен сценарий первичной аутентификации пользователя в ИС.

Пользователь вводит логин и пароль в Web-форме. Обработчик отправки формы пытается выполнить аутентификацию:

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

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

После вызова удаленного метода:

управление получает клиентский канальный применик ClientChannelSink, а именно его метод :

Во время выполнения запроса

управление передается на сервер приложения, где в работу первым делом включается серверный канальный приемник ServerChannelSink, а именно, его метод

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

Сценарий процесса приведен на рисунке 7.

Первым делом в запросе пользователя к Web-серверу ищется специализированное cookie — билет аутентификации (authTicket). Этот билет содержит некоторую информацию о пользователе и говорит Web-серверу о том, что пользователь уже аутентифицирован. Для активизации этой функциональности на Web-сервере необходимо включить Forms Authentication.

Идентификация пользователя происходит в методе AuthenticateRequest Web-сервера. Этот метод вызывается сервером в начале обработки каждого запроса.

Теперь пользователь аутентифицирован на стороне Web-сервера и может выполнять программы, реализующие логику Web-приложения. В процессе выполнения этих программ Web-сервер может обращаться к серверу приложения. Естественно, что и там запрос пользователя необходимо аутентифицировать. Для этого на сервер приложения передается S >Функциональность авторизации реализуется с помощью атрибута System.Security.Permissions.PrincipalPermissionAttribute, устанавливаемого перед соответствующими методами фасадного объекта (BusinessFacade):

Поддержка сессий

Осуществляется с помощью объектов ServerSecurityContext, SecurityContextContainer, ClientSecurityContext на клиентской и серверной сторонах. Инициализация сессии происходит в методах AuthenticateRequest для Web-сервера и в ProcessMessage канального приемника для сервера приложения. Объекты ISecurityContext(ServerSecurityContext, ClientSecurityContext), содержащие состояние сессии, хранятся в коллекции SecurityContextContainer. Ключом к сессии является SID (идентификатор сессии). При инициализации сессия извлекается из коллекции(SecurityContextContainer) и с помощью статического метода Current ассоциируется с текущим потоком выполнения.

После инициализации сессии ее состояние доступно в любом месте кода.

Главное — проставить для этого ссылки на SecurityBase и SecurityServer(SecurityClient).

Заключение

Тестовое приложение WebCl (рисунок 8) демонстрирует возможности описанного решения. Это приложение, впрочем, как и все решение, прилагается к этой статье в виде проекта в формате Visual Studio .Net 2003.

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

Можно организовать проверку — «один пользователь — одна сессия». Можно добавить шифрование трафика. Свойство Items объектов IsecurityContext может служить контейнером для сохранения различных объектов в сессии пользователя. Путем небольшой переработки клиентской части, это решение можно адаптировать для Windows Forms-приложений. В общем, поле для деятельности большое.

Аутентификация пользователей

После установки и настройки Traffic Inspector, пользователь сможет обращаться в Интернет только после успешной аутентификации на шлюзе.

По типу клиентской программы, используемой для аутентификации, можно выделить следующие типы аутентификации, поддерживаеммые в Traffic Inspector:

  • без программы, при сетевой активности по IP-адресу / MAC-адресу
  • через агент TI по логину / паролю
  • через web-агент TI по логину / паролю
  • через браузер при обращении на прокси по логину / паролю
  • через браузер при попадании на веб-портал по логину / паролю

Также, Traffic Inspector поддерживает SSO-аутентификацию и аутентификацию пользователей терминального сервера.

Аутентификация по логину / паролю может предполагать использование учетной записи Traffic Inspector или учетной записи Windows.

Аутентификация через агент TI

Агент Traffic Inspector — небольшое приложение, устанавливаемое на компьютере конечного пользователя.

Если в вашей сети развернут шлюз Traffic Inspector, и LAN-адаптеру шлюза присвоен адрес 192.168.137.1, то скачать агент можно на Web-портале по адресу: https://192.168.137.1:8081/Download/TrafInspAg.exe

Использование Агента TI является полностью опциональным. Агент TI призван упростить аутентификацию по логину / паролю и некоторые другие аспекты работы пользователя:

  • Аутентификация пользователя
  • Отображения баланса
  • Смены пароля пользователем
  • Переключения режимов фильтрации и кэширования пользователем
  • Получения сообщений от администратора сети
  • Конфигурирования Internet Explorer и других браузеров для использования прокси Traffic Inspector
  • Быстрый доступ к Web-порталу

После запуска агента, иконка приложения отображается в области уведомлений.

Для конфигурации агента, щелкните на кнопку в нижнем правом углу интерфейса агента.

Настроим агент для аутентификации по логину / паролю учетной записи Windows. Для этого укажите нстройки аналогичные тем, что указаны на скриншоте.

На вкладке Соединение в настройках агенте, укажите IP-адрес, присвоенный LAN-адаптеру шлюза Traffic Inspector (например, 192.168.137.1).

При использовании клиентского агента можно выбрать протокол обмена: UDP, HTTP или SSL.

Протоколы UDP и SSL обеспечивают конфиденциальную передачу данных между клиентом и шлюзом. При использовании аутентификации по логину / паролю, эти данные передаются в открытую, если используется Basic-аутентификация, и в виде NTLM-хеша, если используется Windows-аутентификация.

Аутентификация через Web-агент

Веб-агент Traffic Inspector — веб-приложение, отображаемое в веб-браузере на компьютере конечного пользователя.

Если в вашей сети развернут шлюз Traffic Inspector и LAN-адаптеру шлюза присвоен адрес 192.168.137.1, то запустить Web-агент можно, обратившись по адресу https://192.168.137.1:8081/portal/.

В разделе Web-агент нажмите на кнопку Запустить Web-агент.

Web-агент выполняет следующие функции:

  • Аутентификация пользователя
  • Отображения баланса
  • Переключения режимов фильтрации и кэширования пользователем

Web-агент подойдет для аутентификации с устройств, использующих MacOS, GNU/Linux, Android.

Аутентификация через браузер на прокси

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

Откройте Панель управления\Сеть и интернет\Свойства обозревателя, вкладка Соединения, кнопка Настройки LAN.

Во фрейме Прокси сервер укажите IP-адрес и порт прокси. В примере, указан IP-адрес 192.168.137.1. Адрес, используемый в Вашей сети, может отличаться.

Прокси-сервер Traffic Inspector использует порт 8080 для проксирования HTTP, HTTPS и FTP-подключений.

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

Аутентификация через браузер на веб-портале

Аутентификация через браузер на веб-портале работает сразу после установки и не требует отдельной настройки.

Когда неаутентифицированный пользователь обратится в Интернет, он будет перенаправлен на веб-портал Traffic Inspector.

Веб-портал предложит аутентифицироваться с использованием учетной записи Traffic Inspector.

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

Single Sign On аутентификация

Single Sign On аутентификация избавляет доменного пользователя от повторных запросов на прохождение аутентификации. Пользователь вводит доменный логин / пароль всего один раз — при логоне в операционную систему. При обращении в Интернет, аутентификация на прокси Traffic Inspector происходит прозрачно и автоматически.

Single Sign On аутентификация требует осуществления базовых настроек для работы с доменом Active Directory.

Также, в Свойствах обозревателя или в браузере на машине пользователя должно быть настроено использование прокси Traffic Inspector (см. раздел Аутентификация через браузер на прокси).

Аутентификация пользователей, работающих с терминального сервера

Работа терминальных пользователей может быть настроена двумя способами:

  • Все терминальные пользователи представлены как один пользователь Traffic Inspector
  • Каждый терминальный пользователь имеет собственную учетную запись в Traffic Inspector

Все терминальные пользователи представлены как один пользователь Traffic Inspector

Создайте учетную запись пользователя с аутентификацией по IP-адресу. В качестве IP-адреса укажите адрес терминального сервера.

Достоинства

  • Терминальные пользователи смогут работать через Routing/NAT и веб-прокси

Недостатки

  • Весь трафик с терминальной машины (трафик самой машины + трафик всех терминальных пользователей) будет записываться на одного «коллективного» пользователя.
  • Терминальные пользователи не могут использовать агент TI.


Каждый терминальный пользователь имеет собственную учетную запись в Traffic Inspector

В Traffic Inspector используется принцип сквозной авторизации: если с какого-то IP-адреса клиент прошел процедуру аутентификации, то в дальнейшем весь трафик с этого IP-адреса классифицируется как принадлежащий данному клиенту. Недопустима авторизация нескольких клиентов с одного IP-адреса, так как в такой случае нарушается принцип сквозной авторизации. В некоторых ситуациях, может потребоваться возможность разрешить множественную аутентифкацию с одного IP-адреса (например, при работе нескольких пользователей с сервера терминалов).

Для полноценной поддержки терминальных пользователей в Traffic Inspector должны быть осуществлены дополнительные настройки.

Пройдите в раздел [Корень консоли\Traffic Inspector []\Правила\Правила сетей], и выберите Создать новое правило.

На вкладке IP адреса и сети укажите IP-адрес терминального сервера. В нашем примере используется адрес 192.168.137.17. В Вашем случае, IP-адрес может быть другим.

На вкладке Сервер терминалов установите флаг Сервер терминалов.

На вкладке Аутентификация укажите настройки аутентификации в соответствии со скриншотом.

Убедитесь, что в разделе Правила сетей, созданное правило правило_для_терминальных_пользователей находится выше правила All IP addresses.

Достоинства

  • Каждый пользователь имеет собственную учетную запись в Traffic Inspector, благодаря чему становится возможным раздельный учет трафика.
  • Терминальные пользователи могут использовать агент TI.

Недостатки

  • Возможна работа только через HTTP-прокси и SOCKS-прокси с обязательной аутентификацией каждой HTTP-сессии и SOCKS-сессии.
  • Терминальные пользователи не могут работать через Routing/NAT.
  • Для терминальных пользователей недоступно шейпирование.

Компьютерная грамотность с Надеждой

Заполняем пробелы – расширяем горизонты!

    CompGramotnost.ru » Интернет-грамотность » Что такое web интерфейс и как им воспользоваться

Что такое web интерфейс и как им воспользоваться

Старый добрый привычный способ работы с компьютером – это запустить на нем требуемую программу, и выполнить с ее помощью требуемую работу. Но теперь на смену этому подходу приходит другой – запустить сервис или приложение в сети Интернет, а не локально на своем компьютере.

Это работа с помощью так называемого «web-интерфейса», которая находит все более широкое распространение. Недалеко то время, когда работа с web-интерфейсом будет более распространена, чем пока еще привычная для многих локальная работа на компьютере.

Вы встречали такие выражения как «web интерфейс почты» или «зайти через веб интерфейс»? У многих пользователей возникает вопрос: что же это такое — веб интерфейс? И можно ли его «попробовать на зубок» простому человеку?

Web-интерфейс — это взаимодействие пользователя с нужным ему веб-сайтом через браузер.

В частности, web-интерфейс электронной почты представлен в виде обычного web-сайта (Яндекс, Гугл, Майл ру и т.п.), который предоставляет пользователю возможность работать с почтовым ящиком.

Конечно, при таком взаимодействии требуется, чтобы устройство пользователя (компьютер, планшет, смартфон) было подключено к Интернету.

В дальнейшем будем считать, что сайт — это то же самое, что веб-сайт.

Чтобы зайти через веб-интерфейс, нужно

  • открыть браузер,
  • в браузере найти и открыть нужный сайт,
  • ввести на этом сайте свои данные (логин и пароль), чтобы получить доступ к услугам и возможностям на сайте. На этом все.

Рассмотрим конкретные примеры. Как известно, с ними всегда все проще и понятнее.

Web интерфейс почты

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

Можно заходить в свой почтовый ящик двумя способами:

  1. через web-интерфейс,
  2. с помощью специальной программы, которая называется почтовым клиентом (например, Mozilla Thunderbird, The Bat!и Microsoft Outlook).

Начинающие пользователи обычно используют первый способ.

Рис. 1 Заходим в Яндекс.почту через веб-интерфейс

Чтобы зайти в web-интерфейс почты:

  • открываем любой браузер,
  • заходим на веб-сайт почты (например, заходим на Яндекс, либо Mail.ru, Google, Rambler, Yahoo),
  • в специальной форме вводим свои данные (цифры 1 и 2 на рис. 1) для доступа к своей почте. Жмем «Войти» (любая из двух цифр 3 на рис. 1).

В этой специальной форме, как правило, есть кнопки

  • «Регистрация» (или «Завести ящик» – цифра 4 на рис. 1) и
  • «Войти».

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

После этого в окне браузера загрузится основная Web-страница почтового ящика. На ней будут размещены ссылки на дополнительные веб-страницы, которые предназначены для просмотра входящей почты (цифра 1 на рис. 2), для проведения настроек почтового ящика (цифра 2 на рис. 2) и другие.

Рис. 2 Вид почтового ящика на Майл ру после входа через веб-интерфейс

Веб интерфейс в Облаках

Есть облачный Яндекс.Диск, о котором я писала ЗДЕСЬ. С ним можно работать через веб-интерфейс или, иначе говоря, в режиме онлайн, при подключенном Интернете.

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

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

Все написанное выше в полной мере можно отнести к веб-интерфейсу Облака Майл ру.

Рис. 3 Заходим в Облако Майл ру через веб интерфейс

В Облаке также есть приложение, которое можно установить на своем компьютере. А можно работать с Облаком через веб-интерфейс. Для этого в браузере открываем сайт Облака (цифра 1 на рис. 3), а затем при первом посещении жмем на кнопку «Регистрация». Если уже есть логин и пароль на Майл ру, то нажимаем на кнопку «Войти» (цифра 2 на рис. 3).

Как зайти в веб интерфейс модема

Рис. 4 Примеры модема Yota и модема Мегафона

Речь пойдет о модемах, аналогичных представленным на рисунке 4. Это модемы Yota, Мегафона, Билайна, МТС и т.п. Другие варианты модемов здесь не рассматриваем.

Чтобы зайти в web интерфейса модема, выполняем все те же 3 шага:

  • откроем любой браузер,
  • найдем сайт, который предоставляет нам модем (Yota, Мегафон, Билайн, МТС),
  • введем свои данные для авторизации на сайте (логин и пароль). Обычно они вводятся в «Личном кабинете» пользователя на сайте.

Допустим, у меня модем Yota. В таком случае web интерфейс модема – это мой личный кабинет на сайте Yota (рис. 5).

  • Кликаем по вкладке «Частным клиентам» (цифра 1 на рис. 5),
  • а затем по ссылке «Профиль» (цифра 2 на рис. 5).
  • Вводим логин и пароль,

после чего можно управлять своим модемом. Это оплата, выбор и регулировка скорости и продолжительности работы модема Yota и т.п.

Рис. 5 Заходим через web интерфейс модема Yota

Если у Вас модем Мегафона, то Вам следует зайти на сайт Мегафона. И там при первом входе надо пройти регистрацию, а при всех последующих заходах вводить свой логин и пароль от личного кабинета на сайте Мегафона. Подробнее о личном кабинете Мегафона смотрите ЗДЕСЬ.

Веб интерфейс роутера

Web-интерфейс применяется и для управления различными сетевыми устройствами, например, для управления роутерами. Роутер – это устройство, предназначенное для «размножения» Интернета, например, в пределах квартиры или офиса. При его первоначальном подключении требуется ввести специальные настройки, которые удобно делать с помощью web-интерфейса.

Делается это не так просто, чтобы это можно было описать в одной-двух фразах. Поэтому я предлагаю заинтересованному читателю посмотреть статью «Как провайдер заставил меня перенастроить роутер D-Link», где это более подробно описано. Для этого кликните по ЭТОЙ ссылке.

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

Веб-клиент, windows авторизация

Провинциальный 1сник

(0) >из внешней сети как можно зайти, используя данные нашей локальной сети

Никак. Протокол win-аутентификации (NTLM) работает только внутри локальной сети.

(1) >А еще хочется, чтобы доменная аутентификация опционально для пользователя была бы «неавтоматической», то есть с вводом логина, пароля и домена

Это штатная функция. В настройках запуска базы нужно выбрать «Запрашивать имя и пароль».

Провинциальный 1сник

(3) >Доменные — не умеет.
Имхо, и правильно делает. Для юзеров самое то, чтобы работали в базах под своими учетками.
А для админа есть 1с-ные логин/пароль.

>Сквид же умеет так делать.
Дык, 1с же не только через веб-сервер умеет работать.

Провинциальный 1сник Провинциальный 1сник Провинциальный 1сник Провинциальный 1сник Провинциальный 1сник Господин ПЖ

(12) и проблема то в чем?

заходишь на сервак в конторе по RDP/VPN под учеткой домена

заходишь с сервера в 1с.

Господин ПЖ Провинциальный 1сник Провинциальный 1сник Провинциальный 1сник Господин ПЖ

> а стандарт де-факто при организации выхода в интернет из локальной сети.

лучше бы в 1с аудит сделали. блокировку после N-той попытки зайти

(23) Да, неявно. В этом режиме 1С ничего не знает про логины, пароли, домены и т.д., а пользуется стандартным интерфейсом безопасности ОС.

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

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

Вот зачем 1С становиться «слабым звеном»?

Господин ПЖ

>Вот зачем 1С становиться «слабым звеном»?

некуй накручивать на систему еще и «варку кофе с минетом».

Многофакторная аутентификация по-взрослому. Куем серьезный софт с помощью бесплатного инструментария

Содержание статьи

Профиты многофакторной аутентификации для корпоративных приложений

  1. Более надежная аутентификация, чем только имя пользователя и пароль. К «что-то, что я знаю» (логин/пароль) добавляется «что-то, чем обладаю» — физическое устройство, а проверить, владеет ли им данный пользователь, позволяет код в СМС, отправленной на это устройство, или звонок на него с запросом пин-кода.
  2. Удобное управление настройками подобной системы аутентификации — включение/выключение разной степени защиты для разных пользователей, настройка различных политик и способов работы дополнительных факторов аутентификации.
  3. Возможность использовать учетные данные корпоративной инфраструктуры для входа в приложения, а не создавать новые логины и пароли для приложения в дополнение к корпоративным.

Мы рассмотрим реализацию этой задачи с помощью следующих продуктов и технологий:

  • Azure Active Directory — облачный сервис многофакторной аутентификации;
  • Azure Active Directory Authentication Libraries (ADAL) — библиотеки, обеспечивающие вызовы сервисов многофакторной аутентификации, включая проверки сертификатов, защищенное соединение с облачным сервисом аутентификации, отображение необходимых диалогов аутентификации. Поддерживает множество платформ и языков программирования;
  • Xamarin Forms — кросс-платформенное средство создания мобильных приложений, обеспечивающее компиляцию в нативный код и стопроцентный доступ к нативным API. Особенно удобно для быстрого создания приложений с переиспользованием 80–90% и более исходного кода между iOS, Android, Windows UWP — как раз наш случай для данного примера. Xamarin доступен как бесплатная часть Microsoft Visual Studio во всех ее версиях, включая бесплатную Visual Studio Community Edition.

Также с помощью Active Directory Federation Services (ADFS) и их интеграции с Azure Active Directory мы можем использовать для многофакторной аутентификации корпоративные учетные записи и пароли внутреннего домена Active Directory, но основной упор в этой статье сделаем на первые две задачи. ADFS будет опциональной задачей, так как, если нам не нужна интеграция с локальным доменом Active Directory, мы можем создать учетные записи вручную непосредственно в сервисе Azure Active Directory.

Начнем с настройки Azure Active Directory: если у нас нет учетной записи и доступа к Microsoft Azure, можем легко получить бесплатную пробную учетную запись здесь. В рамках пробной подписки большое число сервисов предоставляется бесплатно на год. В целом все, что описано в данной статье, ты можешь попробовать бесплатно.

Регистрация мобильного приложения для доступа к Azure Active Directory

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

Зайдя на портал Azure, в самой левой черной панели служб выбираем службу Azure Active Directory (или нажимаем All Resources и пользуемся поиском служб), переходим в подраздел App registrations и регистрируем новую учетную запись приложения, нажимая New application registration.

New App Registration

Заполняем поля новой учетной записи приложения:

  • Name — любое имя, по которому потом нам самим будет понятно, о каком приложении речь;
  • Application Type — выбираем Native, так как у нас будет мобильное приложение, а не веб-сервис;
  • Redirect URI — это фактически идентификатор, который должен обязательно совпадать в настройке учетной записи приложения на стороне сервиса с настройкой на стороне клиента. Это может быть любой произвольный URI (произвольная строка в формате URI) — он не должен быть обязательно реальным хостом и не должен быть зарегистрирован в DNS.

New App Registration Form

Нажимаем Create и получаем новую учетную запись приложения с автоматически назначенным системой идентификатором, который называется APPLICATION ID.

New App Registration Completed

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

Создание пользователя и включение многофакторной аутентификации

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

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

То есть при использовании AFDS получится такая топология:

Мы же продолжим базовый сценарий, который не требует наличия домена Active Directory и настройки службы ADFS, и заведем пользователя самостоятельно в Azure Active Directory.

Заходим в знакомый раздел Azure Active Directory → Users and groups → All users и нажимаем New user.

Далее заполняем информацию о пользователе. Обрати внимание на User name: если у тебя в подписке Azure сконфигурировано свое доменное имя — используй его, если нет — система автоматически сгенерирует доменное имя в алиасе пользователя по принципу [логин нашей учетной записи Azure].onmicrosoft.com. Для целей тестирования этого достаточно, для производственных систем, очевидно, мы пропишем в подписке Azure свой более симпатичный домен. Также придумываем и прописываем пароль. На скриншоте подчеркнут автоматически сгенерированный домен для моей пробной подписки.

Нажимаем Create и получаем новую учетную запись пользователя.

Теперь включим для нее многофакторную аутентификацию. Заходим в раздел All users и нажимаем кнопку Multi-Factor Authentication.

Multi-Factor Authentication Button

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

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

На стороне сервиса все готово — данный пользователь теперь будет аутентифицироваться многофакторно. Если хочется изменить настройки сервиса, можно зайти в раздел Service settings — сразу под надписью Multi-factor authentication на предпоследнем экране выше.

Здесь есть, например, интересный раздел, который задает, какие методы дополнительных «факторов» доступны пользователю.

Здесь можно настроить звонок либо СМС на телефон или подтверждение через мобильное приложение Microsoft Authenticator.

Конфигурирование сервиса Azure Active Directory завершено, теперь создадим мобильное приложение и интегрируем в него многофакторную аутентификацию.

Интеграция многофакторной аутентификации в мобильное приложение

Как я сказал выше, мы для примера возьмем Xamarin Forms (бесплатная часть Visual Studio), который позволит нам, переиспользуя большую часть кода, получить сразу нативные мобильные приложения с поддержкой многофакторной аутентификации для iOS, Android и Windows UWP.

Быстрый способ — используем готовый исходный код

  1. Забираем код из моего репозитория на GitHub.
  2. Прописываем в код приложения в файле MainPage.xaml.cs идентификаторы, которые мы сконфигурировали при регистрации приложения в облачном сервисе Azure Active Directory. Их полное соответствие в приложении и сервисе необходимо, чтобы сервис не отклонял обращения приложения.

clientID — это Application ID из наших настроек облачного сервиса выше.

returnURI — это Redirect URI из наших настроек облачного сервиса выше.

Все готово. Теперь мы рассмотрим также создание приложения с нуля.

Детальный способ — создаем приложение с нуля

Запускаем Visual Studio (я сейчас использую VS 2020, версия 15.6.7) с установленным Xamarin. Это можно проверить, запустив Visual Studio Installer и нажав Modify текущей инсталляции Visual Studio.

Xamarin входит во все версии Visual Studio — даже в бесплатную Community Edition, но нужно убедиться, что он включен и установлен, как показано выше.

Запускаем Visual Studio и создаем новый проект: меню File → New → Project. Выбираем Cross-Platform → Mobile App (Xamarin.Forms).

Далее выбираем Blank App и .NET Standard как Code Sharing Strategy.

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

Если это не так, сделаем его стартовым: правый клик на проекте App.Android и меню Set as a StartUp Project.

Нажав F5, запустим приложение на эмуляторе Android и увидим:

Убедившись, что все работает, останавливаем отладку (Shift + F5).

Чтобы интегрировать многофакторную аутентификацию, подключим библиотеку Azure Active Directory Authentication Libraries (ADAL). Подключить ее надо будет к каждому проекту: правый клик на каждом проекте — всего четыре проекта (общий + специфичный под каждую из трех платформ) = 4 раза → Manage NuGet Packages.

Далее закладка Browse — вводим в поиск adal и подключаем, нажимая на кнопку со стрелкой вниз.

Для реализации логики работы с библиотекой будем использовать следующий подход:

  • в общем проекте определим интерфейс IAuthenticator, через который будем вызывать аутентификацию из общего кода;
  • в каждом из платформенных проектов определим специфичную для конкретной платформы реализацию взаимодействия аутентификации с пользовательским интерфейсом этой платформы;
  • используя DependencyService, доступный в Xamarin Forms, мы сможем при вызове единого метода Authenticate интерфейса IAuthenticator из общего кода автоматически использовать именно ту реализацию под конкретную платформу, на которой в данный момент запущено приложение.

Начинаем с определения интерфейса IAuthenticator в общем для всех платформ проекте, создаем в нем новый файл IAuthenticator.cs с определением интерфейса (правый клик на проекте → Add → New Item → Class).

Как видишь, мы определяем сигнатуру асинхронного метода аутентификации. AuthenticationResult при успешной аутентификации будет содержать полученный от Azure Active Directory токен. Соберем проекты: правый клик на Solution → Build Solution.

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

Android

Для Android нам нужно инициализировать PlatformParameters текущим окном/диалогом, то есть в терминах Android — Activity. Для этого мы можем использовать Forms.Context. Добавляем в Android-проект файл Helper.cs со следующим кодом.

Если VS будет подчеркивать красным IAuthenticator — запусти сборку, чтобы проверить, что собирается успешно.

Также обрати особое внимание на метаатрибут Dependency для данного Helper namespace — именно он позволяет DependencyService сопоставить вызов из общего кода и реализацию для конкретной платформы.

Также для Android нам нужно переопределить OnActivityResult метод в MainActivity.cs файле (внутри класса MainActivity) для правильной обработки и продолжения последовательности диалогов аутентификации (также добавляем два namespace через директивы using).

Теперь переходим к iOS.

В iOS для PlatformParameters передаем UIViewController в качестве контекста, а именно RootViewController — то есть текущее окно.

Не забываем про атрибут Dependency перед namespace. Для iOS не нужно переопределять метод возврата результатов окна/диалога.

Для того чтобы собрать iOS-проект, нам понадобится Mac-хост с агентом сборки или, например Mac-машина в облаке для сборки, которую предоставляет Microsoft App Center (опять-таки можно попробовать бесплатно — до 240 минут сборки в месяц плата не взимается).

Теперь реализация для Windows UWP (Universal Windows Platform).

Universal Windows Platform

Здесь тоже все очень просто — добавляем знакомый файл Helper.cs с реализацией интерфейса IAuthenticator, не забывая про атрибут Dependency.

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

Общий проект

Добавим кнопку для входа с использованием многофакторной аутентификации в общий проект. Заходим в общий проект Xamarin Forms, в котором содержится общий код и общий пользовательский интерфейс для всех платформ, и открываем через Solution Explorer главную страницу приложения — MainPage.xaml.

Solution Main Page

Если Solution Explorer не видно, его можно включить через меню View → Solution Explorer.

Обрати внимание, что VS предложит запустить визуализацию интерфейса через Live Player, — нажми Live Run, и ты сможешь вживую видеть на эмуляторе прямо во время редактирования, как изменяется пользовательский интерфейс приложения. Очень удобно для разработки. Визуализация будет идти с некоторой задержкой, поэтому просто продолжай редактирование.

В Xamarin Forms вся логика пишется на языке C#, а визуализация на языке разметки XAML.

Познакомиться подробно с разработкой на Xamarin Forms можно, скачав бесплатную и очень подробную книгу знаменитого Чарльза Петцольда (думаю, многие помнят этого автора) «Creating Mobile Apps with Xamarin.Forms».

В основном Page (окне) приложения MainPage.xaml добавим кнопку с обработчиком, для этого XAML-код для кнопки (Button) поместим вместе с существующим Label внутрь контейнера StackPanel. Этот простейший контейнер выстраивает внутри себя контролы в ряд по вертикали или горизонтали.

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

После этого сразу перейдем в файл MainPage.xaml.cs (для этого нужно развернуть секцию с MainPage.xaml, чтобы увидеть код/code-behind) и добавим обработчик нажатия кнопки, а также нужные нам идентификаторы и namespaces.

После этого прописываем в приложение в код идентификаторы, которые мы сконфигурировали при регистрации приложения в облачном сервисе Azure Active Directory. Их полное соответствие в приложении и сервисе необходимо, чтобы сервис не отклонял обращения приложения:

clientID — это Application ID из наших настроек облачного сервиса выше.

returnURI — это Redirect URI из наших настроек облачного сервиса выше.

Запуск приложения

Теперь можно запускать приложение (например, на эмуляторе по F5) и аутентифицироваться учетными данными пользователя, которого мы завели выше. При первом входе после корректного ввода имени пользователя и пароля система предложит пользователю зарегистрировать свой мобильный номер для получения подтверждающих звонков или СМС — выбор будет зависеть от того, какие возможности многофакторной аутентификации мы разрешили в параметрах Service Settings настроек Multi-factor Authentication раздела облачного сервиса.

После регистрации мы получим звонок или СМС на мобильный телефон. Только после ввода с цифровой клавиатуры запрошенного подтверждения или СМС-кода мы успешно аутентифицируемся в системе.

При успешной аутентификации Azure Active Directory выдаст JWT-токен (JSON Web Token), который можно использовать для авторизации (разрешения) действий пользователя в мобильном приложении. Токен подписан цифровой подписью, подтверждающей его целостность, и содержит ряд полей, по которым мы можем определять не только то, что пользователь успешно прошел аутентификацию, но и к каким ролям он принадлежит. Для реализации высокой степени защиты и безопасности нужно дополнительно проверять сертификат, которым подписан токен, на то, что он действительный. Также токен нужно передавать только через защищенные соединения и хранить в защищенных хранилищах.

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

Полный пример приложения на GitHub содержит операцию выхода/logout, которая очищает кеш токенов в приложении, а также cookie, которые могут в соответствии с настройками сервиса Azure Active Directory позволять пользователю не вводить повторно пароль в течение настроенного времени.

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

Статья Аутентификация и авторизация в микросервисных приложениях [Часть 1]

mrOkey

Доброго времени суток, codeby.

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

В качестве приложения для примера — выбраны микросервисы, из моей статьи о docker. Читателю также предлагается ознакомиться с ними самостоятельно. Стоит сказать, что приложение было модифицировано. Фронтенд вынесен в контейнер с ngnix, о чём я также расскажу во второй части, apigetway мы перепишем в рамках второй части.

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

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

Как раз в этом месте и начинается творчество. Проблема заключается в том, что ответы на приведённые вопросы сильно различаются. Нельзя не заметить, что различия коррелируют с особенностью рассматриваемой системы — ответы, которые правильны для системы А будут в корне не верны для системы Б и так далее.

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

Рассуждая теоретически, очень важно говорить на одном языке, поэтому давайте для начала определимся с некоторыми моментами.
Задача аутентификации — убедиться, что пользователь — тот за кого себя выдаёт.
Задача авторизации — убедиться, что пользователь имеет право делать то или иное действие в системе.
Данные бывают передаваемыми и хранимыми. Передаваемые данные — это данные которые “гуляют” от микросервиса до микросервиса. Хранимые — это данные которые хранятся в базах данных микросервисов.
Область действия — идентификатор для группы ресурсов, которые необходимо защитить. Например, все конечные точки способные изменить местоположение Пети, должны входить в группу location_information_write. Этакие наименования прав.
Маркер доступа — подписанный объект, используемый для предоставления доступа к микросервисам. Микросервис может запросить маркер доступа к любой области действий, если доступ разрешен — микросервис начинает взаимодействовать с разрешенной зоной.
OAuth и OpenId Connect — мы будем использовать эти протоколы для аутентификации и авторизации, реализацию возьмём из IdentityServer.

Разобравшись с понятиями давайте приступим к размышлениям. Напомни, что раньше мы использовали архитектуру frontend for backend, где в качестве бэкэнда мы использовали микросервисы. Тогда каждый фрагмент фронтенда либо прорисовывался, либо нет — в зависимости от того был ли запущен сервис. Сейчас же давайте изменим архитектуру на нечто такое:

Что произошло: я вынес фронтенд часть на волю ngnix, действительно, нет особой необходимости иметь целый .net core проект, который существует лишь для того, чтобы рендерить заглавную страницу сайта, ngnix легковесней, дешевле и быстрее, этого вполне достаточно чтобы сделать выбор в его пользу. Появилось бизнесс-требование, которое гласит: “Необходимо дать пользователю возможность предустанавливать свою страну и город, для корректного вывода погоды и курса валют”. Вот у нас и появился функционал, который должен быть разграничен пользовательским контекстом. Так для Пети из Москвы погода и курс рубля к доллару будет отличаться от Тараса из Харькова (курс валюты для Тараса будет представлен как гривна к доллару).
Появился микросервис Login, в рамках которого и строится дальнейшее проектирование, предполагается что микросервис логин будет аутентифицировать пользователей, так как только Петя может менять свои настройки, ну суть ясна я думаю.

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

Тут нам на помощь придёт промежуточное ПО, которое перенаправляет пользователей, которые не вошли в систему, в микросервис Login. Сам же микросервис Login решает как именно пользователь будет входить в систему и проводит его через процесс входа. В рамках статьи, Петя и Тарас смогут попасть в систему двумя способами:

  • логин и пароль
  • google auth

Вне зависимости от способа входа, микросервис Login должен предоставлять подтверждение API Gateway того, что пользователь аутентифицирован, в таком виде в котором API Gateway предоставляет возможность проверить подлинность. Для этого существуют различные протоколы, в данном случае мы будем использовать OpenId Connect.

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

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

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

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

Доверие микросервисов друг к другу

Поговорим о моменте, который нередко (разумеется во вред) упускается из вида. Смоделируем ситуацию атаки, допустим злоумышленник смог завладеть микросервисом валют и собирается отправить от его имени запрос на изменение логина и пароля Тараса на микросервис Login. В сценарии, где микросервисы доверяют друг другу и ничем не ограничены — мы, как blue team, потерпели сокрушительное фиаско. Однако, если голова нам дана “не чтоб шапку носить” и мы ограничили доступ к микросервису Login (разумно, чтоб его мог вызывать только Api Gateway, так как он находится на периферии) то всё будет хорошо.

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

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

Напоследок хочу сказать пару слов о том, как работает гугл аутентификация.

Давайте взглянем на картинку:

Процесс описан сверху вниз. В данном случае Client — это фронтенд часть приложения которое мы обсуждаем. Server — это его серверная часть, которая представлена у нас микросервисом Login. Google API Server — апи гугла, с которым мы будем взаимодействовать, а OAuth Dialog — это тот самый диалог, которые предоставляет гугл для аутентификации юзеров. Для использование google oauth нам нужен api-ключ: не имеет смысла расписывать пошагово как его получить, поэтому вот:

Ну а в следующей части я расскажу и покажу как всё это реализовать.

Аутентификация пользователей через Web интерфейс.

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

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

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

Есть довольно много методов для решения этой задачи, но используют в основном два способа:

  • шифруют пароль, введенный в веб-форме и сравнивают его с паролем в файле passwd или shadow
  • используют pop3 аутентификацию.
  • Первый метод весьма скользкий, ибо его реализация требует прав суперпользователя (root) для открытия файла зашифрованных паролей (shadow), и, как следствие, является дырой в безопасности сервера. Он реализуется путем исполнения cgi-скрипта с правами root (suid).

    Вообщем, алгоритм простой:

      взять пару логин/пароль с Web-формы;

    зашифровать пароль тем же алгоритмом, что и на сервере;

    открыть файл shadow для сравнения пароля, там хранящегося с полученным с web-формы.

    Ежели результат сравнения положителен, аутентификация прошла успешна и увы в противном случае.

    Не забыть позакрывать все файлы.

    Все вообщем-то довольно просто.

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

    В Unix системах шифрование происходит в одну сторону — к зашифрованному паролю добаваляется хорошая порция избыточной информации (salt — соли), и выдернуть пароль назад оттуда не представляется возможным. Так что, «взлом» паролей возможен лишь методом подбора оного. Ну, а если пользователь легальный и пароль действительный, то зашифруя его, мы сразу же успешно проходим аутентификацию.

    За что мне нравится Perl, так это ненужность изобретать велосипеды.

    проверка пароля сводится к вызову стандартной системной функции crypt($text,$salt). Действует она так :

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

    Аутентификация пользователей через Web интерфейс.

    Автор: Ковязин Дмитрий, P-Lib(p-lib.narod.ru)

    Про аутентификацию пользователей написано масса статей и для оной процедуры изготовлено сотни скриптов.
    Однако, в большинстве своем все эти методы рассчитаны на хранение логинов/паролей в отдельном файле, или на аутентификацию пользователей с помошью апачесвкого .htaccess.
    Здесь же речь пойдет про аутентификацию реальных пользователей Unix сервера через веб-интерфейс.
    Есть довольно много методов для решения этой задачи, но используют в основном два способа:

    * шифруют пароль, введенный в веб-форме и сравнивают его с паролем в файле passwd или shadow
    * используют pop3 аутентификацию.

    Первый метод весьма скользкий, ибо его реализация требует прав суперпользователя (root) для открытия файла зашифрованных паролей (shadow), и, как следствие, является дырой в безопасности сервера. Он реализуется путем исполнения cgi-скрипта с правами root (suid).
    Вообщем, алгоритм простой:

    * взять пару логин/пароль с Web-формы;
    * зашифровать пароль тем же алгоритмом, что и на сервере;
    * открыть файл shadow для сравнения пароля, там хранящегося с полученным с web-формы.
    * Ежели результат сравнения положителен, аутентификация прошла успешна и увы в противном случае.
    * Не забыть позакрывать все файлы.

    Все вообщем-то довольно просто.
    Открыли файл, прочитали в буфер, нашли нужную нам строчку, закриптовали пароль, сравнили с тем, что в файле и по делам ихним воздаем аутентифицирующемуся юзеру.
    В Unix системах шифрование происходит в одну сторону — к зашифрованному паролю добаваляется хорошая порция избыточной информации (salt — соли), и выдернуть пароль назад оттуда не представляется возможным. Так что, «взлом» паролей возможен лишь методом подбора оного. Ну, а если пользователь легальный и пароль действительный, то зашифруя его, мы сразу же успешно проходим аутентификацию.
    За что мне нравится Perl, так это ненужность изобретать велосипеды.
    проверка пароля сводится к вызову стандартной системной функции crypt($text,$salt). Действует она так :
    в качестве параметров подается пароль в «чистом» виде и зашифрованный, на выходе она должна выдать тот же зашифрованный пароль. Если этого не произошло, значит пароль в виде простого текста был неправильный.
    В общем вся процедура выглядит все где-то так:

    #!/usr/bin/suidperl
    #
    # читаем форму
    .
    &check_passwd;
    sub check_passwd <
    my $shadow = «/etc/shadow»;
    # ниже две строчки = переданные из формы пароль/логин
    $plaintext = $form<′password′>;
    $username = $form<′login′>;
    # пытаемся открыть файл зашифрованных паролей (на нормальной системе
    # он доступен только для чтения только root-ом.)
    # и заодно попытаемся его залочить.
    open (SHADOW, » new(′popserver′) || print «Cannot create connection «;
    # пробуем влогиниться
    # в $res будет возвращен результат логина
    $res = $pop->login($form<′login′>,$form<′password′>);
    if ($res == undef) <
    # неудача
    print «Incorrect username or password! «;
    > else <
    # влогинились
    # делаем, что надо
    #
    # следующий код нарисован для того, чтобы хоть что-то
    # делалось.
    if ($res eq «0E0») <
    # писем нет
    print «You have $res messages in mailbox. «;
    > else <
    # письма есть
    print «You have $res messages in mailbox. «;
    >
    >
    #закрываем соединение.
    $pop->quit();

    Намного проще и безопаснее, чем лезть в святая святых безопасности Unix систем- файл shadow.
    Да и не нужно просить сисадмина сервера установить на ваш скрипт setuid bit, хотя заранее можно сказать, что любой нормальный сисадмин вам в этом откажет, и будет на все сто прав.
    А библиотека Net есть практически на любом Web-сервере, где есть доступ к perl интерпретатору.

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