назовите методы с помощью которых можно внедрить многофакторную аутентификацию
Не только смс и токен: многофакторная аутентификация на базе SafeNet Authentication Service
Обычно при фразе “многофакторная аутентификация” люди в первую очередь вспоминают про смс-коды, которые приходят, когда оплачиваешь картой онлайн-покупки. Чуть реже на ум приходит флешка с цифрами, токен.
Сегодня я расскажу про другие способы многофакторной аутентификации и задачи, которые они помогают решить компании. Рассказывать буду на примере решения Gemalto Safenet Authentication Service (SAS), которое существует в формате облачного сервиса и on-premise версии, сертифицированной ФСТЭК.
Все примерно представляют, что такое многофакторная аутентификация: это когда помимо пароля (фактор знания) нужно ввести дополнительный подтверждающий фактор. Их два:
Ниже приведу несколько примеров того, какие задачи можно решить с помощью SafeNet Authentication Service.
Задача: соблюдение стандарта PCI DSS
Многофакторная аутентификация – одно из требований стандарта PCI DSS (п. 8.3.). Более того, стандарт требует, чтобы многофакторная аутентификация была одноэтапной: пароль и второй фактор должны вводиться в одном поле. Если злоумышленник попробует завладеть учеткой и ошибется при вводе, ему будет непонятно, где была допущена ошибка – в пароле или токене.
Решение: одноэтапная многофакторная аутентификация по схеме PIN + OTP
Такая схема аутентификации на базе SafeNet реализована в нашей IaaS-платформе, соответствующей требованиям PCI DSS и 152-ФЗ, – Cloud-152. Ее проходят администраторы платформы Cloud-152 для доступа к management-сегменту. Для авторизации нужно ввести в одном поле PIN и OTP, который приходит push-уведомлением в мобильном приложении Mobile Pass.
Так выглядит авторизация для администраторов Cloud-152 со стороны DataLine.
*Здесь должен был быть скриншот с SafeNet Mobile Pass, но приложение блокирует скриншоты.
Задача: двухфакторная аутентификация для сотрудников без смартфона и мобильного интернета
Компания собирается внедрять двухфакторную аутентификацию для входа на рабочие станции. У компании распределенная сеть офисов по всей России, у многих сотрудников нестабильный мобильный интернет или вообще нет смартфона. Получается, что Push-уведомления от мобильных приложений в качестве второго фактора не подойдут. СМС и физические токены отпадают из-за дороговизны.
Решение: использование в качестве второго фактора GrIDSure
GrIDSure – это одноразовый пароль (OTP). Он состоит из таблицы с символами и паттерна, который пользователь сам задает при настройке аутентификации. Для авторизации пользователь выбирает символы из таблицы по этому паттерну и вводит в качестве второго фактора.
Таблица с символами, которую пользователь получает при авторизации на рабочие станции.
Дальше пользователь просто следует выбранному паттерну. Например, вот такому.
В качестве символов можно использовать цифры, буквы и спецсимволы. Размер таблицы настраивается: это может быть таблица 5 на 5 или больше.
При каждой попытке аутентификации таблица обновляется, поэтому такой пароль не забрутфорсить.
С Gridsure также не нужно мобильное приложение, и следовательно, смартфон с мобильным интернетом. GrIDSure отображается в том же интерфейсе и устройстве, что и защищаемый сервис.
Задача: защита веб-сервиса от атаки методом перебора
Многофакторную аутентификацию на базе SafeNet можно использовать для защиты веб-сервисов, опубликованных в интернете, например, Outlook Web App (OWA). Safenet поддерживает RADIUS и SAML-протоколы, поэтому легко интегрируется с сервисами Microsoft Outlook, Office 365, Saleforce, Dropbox, Apache и т.д.
Если злоумышленник знает email’ы, то он сможет атаковать такие сервисы с помощью перебора паролей. Целью такой атаки не всегда может быть захват учетки, а ее блокировка. В теории можно заблокировать всей компании почту.
Решение: использование OTP в качестве второго фактора
Тут можно использовать GrIDSure или Mobile Pass в качестве второго фактора.
Задача: автоматизация выдачи и обслуживания токенов
В компании с распределенной сетью отделений на 20 тысяч сотрудников уже используют двухфакторную аутентификацию с GrIDSure в качестве второго фактора.
Проблема в том, что администраторам приходится тратить много времени на обслуживание токенов: выпускать новые, сбрасывать паттерны и т. д.
Решение: использование портала самообслуживания
В SafeNet есть портал самообслуживания, который поможет автоматизировать рутинные операции и снизить нагрузку на администраторов.
На портале самообслуживания пользователь может оставить всю информацию, необходимую для выпуска токена. Администратору остается только подтвердить ее и отправить ссылку на формирование токена. Если пользователь забыл, какую траекторию выбрал для GrIDSure, то опять-таки самостоятельно может сбросить ее здесь и задать новую.
Задач: Регламентирование доступа к рабочим станциям
В call-центре работают 200 сотрудников посменно. Для экономии ресурсов на двух сотрудников приходится одна рабочая станция. Нужно настроить доступы так, чтобы не было конкурентных сессий.
Решение: внедрение входа по токенам и политики доступа
SafeNet можно установить на каждую рабочую станцию и через него задать политики доступа по времени и IP-адресам. Если смена сотрудника еще не началась, то он не сможет зайти на свою рабочую станцию. Администратор сможет проследить, когда тот или иной сотрудник заходил в систему и с какого IP-адреса в журнале.
Многофакторная аутентификация становится все актуальнее, так как статический пароль даже с большим количеством символов – уже не сложное препятствие на пути злоумышленника.
Еще одна из тенденций в этом направлении – использование токена для доступа сразу к нескольким системам или приложениям компании (SSO-вход). Такой сценарий также можно реализовать с помощью SafeNet. Если интересно, расскажу про него в отдельном посте.
Как ты реализуешь аутентификацию, приятель?
Все знают о стандартной аутентификации пользователя в приложении. Это олдскульная процедура регистрации — пользователь вводит адрес почты, пароль и т. д., — а затем при входе мы сравниваем почту и/или пароль с сохранёнными данными. Если совпадает, даём доступ. Но времена изменились, и сегодня появилось много других методов аутентификации. Если хотите оставаться востребованным программистом/разработчиком в этом меняющемся, словно калейдоскоп, мире разработки ПО, то вы должны знать обо всех этих новых методах.
Нельзя отрицать, что в любых приложениях и ОС «аутентификация» — крайне важный элемент обеспечения сохранности пользовательских данных и регулирования доступа к информации. Чтобы понять, какой метод аутентификации для вас лучше, нужно разбираться в достоинствах и недостатках всех методов, а также неплохо представлять, как же они работают.
Здесь я постараюсь рассказать о большинстве распространённых сегодня методов аутентификации. Это не подробное техническое руководство, а лишь способ познакомить вас с ними. Хотя методы описаны с учётом применения в вебе, эти идеи можно реализовать и в других условиях.
Будем считать, вы уже знаете о том, что большая часть веба/интернета построена на протоколе HTTP. Также вам нужно знать, как работают веб-приложения, что означает аутентификация пользователя в приложении и что такое клиент-серверная архитектура.
Аутентификация на основе сессий
Протокол HTTP не отслеживает состояния, и, если мы аутентифицируем пользователя с помощью имени и пароля, наше приложение не будет знать, тот ли это человек, что и в предыдущем запросе. Нам придётся аутентифицировать снова. При каждом запросе HTTP не знает ничего о том, что происходило до этого, он лишь передаёт запрос. Так что, если вам нужны личные данные, придётся снова логиниться, чтобы приложение знало, что это точно вы. Может сильно раздражать.
Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.
Процедура аутентификации на основе сессий:
У этого метода несколько недостатков.
Аутентификация на основе токенов
Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.
При аутентификации на основе токенов состояния не отслеживаются. Мы не будем хранить информацию о пользователе на сервере или в сессии и даже не будем хранить JWT, использованные для клиентов.
Процедура аутентификации на основе токенов:
У метода есть ряд преимуществ:
Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.
Беспарольная аутентификация
Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»
В наши головы внедрено убеждение, что пароли — абсолютный источник защиты наших аккаунтов. Но если изучить вопрос глубже, то выяснится, что беспарольная аутентификация может быть не просто безопасной, но и безопаснее традиционного входа по имени и паролю. Возможно, вы даже слышали мнение, что пароли устарели.
Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:
Вместо ввода почты/имени и пароля пользователи вводят только свою почту. Ваше приложение отправляет на этот адрес одноразовую ссылку, пользователь по ней кликает и автоматически входит на ваш сайт / в приложение. При беспарольной аутентификации приложение считает, что в ваш ящик пришло письмо со ссылкой, если вы написали свой, а не чужой адрес.
Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.
И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.
Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.
Medium предоставляет доступ к своему сайту только по почте. Я недавно обнаружил, что Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.
Что может пойти не так?
Если кто-то получит доступ к пользовательским почтам, он получит и доступ к приложениям и сайтам. Но это не ваша головная боль — беспокоиться о безопасности почтовых аккаунтов пользователей. Кроме того, если кто-то получит доступ к чужой почте, то сможет перехватить аккаунты в приложениях с беспарольной аутентификацией, воспользовавшись функцией восстановления пароля. Но мы ничего не можем поделать с почтой наших пользователей. Пойдём дальше.
В чём преимущества?
Как часто вы пользуетесь ссылкой «забыли пароль» для сброса чёртового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.
Беспарольная аутентификация хороша не только для пользователей, но и для вас как разработчика. Вам не нужно реализовывать механизм восстановления паролей. Все в выигрыше.
Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.
Сегодня беспарольная аутентификация быстро набирает популярность.
Единая точка входа (Single Sign On, SSO)
Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автомагически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но всё же раздельные продукты. Как они аутентифицируют пользователя во всех продуктах после единственного входа?
Этот метод называется единой точкой входа (Single Sign On, SSO).
Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:
Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.
Выглядит очень просто, но конкретные реализации бывают очень сложными. Подробнее об этом методе аутентификации.
Аутентификация в соцсетях
Уверен, эта картинка знакома всем:
Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.
Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.
Лучшее из двух миров
Пользователи могут войти в ваше приложение одним кликом, если у них есть аккаунт в одной из соцсетей. Им не нужно помнить логины и пароли. Это сильно улучшает опыт использования вашего приложения. Вам как разработчику не нужно волноваться о безопасности пользовательских данных и думать о проверке адресов почты — они уже проверены соцсетями. Кроме того, в соцсетях уже есть механизмы восстановления пароля.
Как использовать
Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth2 (некоторые используют OAuth1, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).
Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.
Двухфакторная аутентификация (2FA)
Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.
Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищённым, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.
Вместо одноразового пароля в качестве второго фактора могут использоваться отпечатки пальцев или снимок сетчатки.
При двухфакторной аутентификации пользователь должен предоставить два из трёх:
Большинство хакеров охотятся за паролями и PIN-кодами. Гораздо труднее получить доступ к генератору токенов или биологическим свойствам, поэтому сегодня двухфакторка обеспечивает высокую безопасность аккаунтов.
То есть это универсальное решение? Возможно, нет.
И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.
Аутентификация или авторизация?
Некоторые путают термины «аутентификация» и «авторизация». Это разные вещи.
Поздравляю, вы успешно дочитали длинную, нудную и скучную статью.
Многофакторная аутентификация по-взрослому. Куем серьезный софт с помощью бесплатного инструментария
Содержание статьи
Профиты многофакторной аутентификации для корпоративных приложений
Мы рассмотрим реализацию этой задачи с помощью следующих продуктов и технологий:
Также с помощью 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
Xakep #230. Социальная инженерия
Заполняем поля новой учетной записи приложения:
Нажимаем 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.
Быстрый способ — используем готовый исходный код
clientID — это Application ID из наших настроек облачного сервиса выше.
returnURI — это Redirect URI из наших настроек облачного сервиса выше.
Все готово. Теперь мы рассмотрим также создание приложения с нуля.
Детальный способ — создаем приложение с нуля
Запускаем Visual Studio (я сейчас использую VS 2017, версия 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).
Получив новый проект, проверим запуск мобильного приложения, по умолчанию стартовый проект выделен жирным шрифтом — 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 в общем для всех платформ проекте, создаем в нем новый файл 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 позволять пользователю не вводить повторно пароль в течение настроенного времени.
Итак, если учетные данные верны и второй фактор подтвержден, мы успешно пройдем многофакторную аутентификацию и увидим данные из полученного токена подтвержденного пользователя.