Системы и методы аутентификации пользователей

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

 

 

1. Введение
2. Однофакторная аутентификация
1. 2.1. Пароли
2. 2.2. Цифровые сертификаты и ЭЦП
3. 2.3. Аппаратные токены
4. 2.4. Биометрия
3. Двухфакторная аутентификация
4. Выводы

 

Введение

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

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

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

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

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

 

Однофакторная аутентификация

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

Пароли

Классика удостоверения личности в информационных системах – пароль. Он так прочно ассоциируется с аутентификацией, что иногда считается ее сущностью. Например, в ГОСТе по судебно-технической экспертизе (Р 57429-2017) значится, что аутентификация пользователя – это «процедура проверки подлинности пользователя путём сравнения введенного им пароля с паролем, сохраненным в базе данных пользователей». Кажется очевидным, что здесь подразумевается постоянный, или многоразовый, пароль, который пользователь запоминает и воспроизводит каждый раз, когда ему нужно подтвердить свою подлинность.

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

Попытка решить проблему постоянных паролей – концепция паролей временных, или одноразовых, которые нужно получать заново для каждой попытки входа. Такой подход ликвидирует большинство недостатков постоянных кодовых слов – временный пароль не нуждается ни в особой сложности, ни в хранении, ни в запоминании. В то же время пользователю обычно нужно иметь при себе какое-либо устройство, позволяющее получать пароли, а система аутентификации закономерно усложняется изнутри, т.к. хранить в базе данных постоянный пароль гораздо проще, чем генерировать его, сопоставлять с учетными записями, следить за сроком действия и т.п. Впрочем, обработку одноразовых паролей можно переложить на «подрядчика»: скажем, Google предлагает всем желающим воспользоваться приложением Authenticator, которое берет работу с одноразовыми паролями на себя. В этом случае можно не разрабатывать свою систему, а воспользоваться уже существующей – что и делает, например, популярное геймерское приложение Discord. Впрочем, это – уже тема для разговора о двухфакторной аутентификации.

 

Рисунок 1. Одноразовый пароль по SMS

 

Для парольной защиты настоящим является тот пользователь, который знает условную комбинацию символов. Вполне очевидно, что этот вариант никак не гарантирует подлинности лица, допускаемого к работе с системой: достаточно узнать пароль тем или иным способом. В случае одноразового пароля эта процедура сложнее, но технически она вполне возможна и реализуема – были бы желание и выгода. Например, передачу временного кода по SMS, которую практикуют многие банки, относительно просто перехватить путем анализа радиосигнала или посредством обычного вируса. Потому, кстати, этот способ доставки одноразовых паролей обоснованно считается ненадежным, и финансовые организации переходят на альтернативные варианты вроде использования Push-уведомлений. Национальный институт стандартов и технологий США призвал отказаться от SMS-аутентификации еще два года назад.

Цифровые сертификаты и ЭЦП

Цифровой сертификат – элемент криптографической защиты информации, электронное удостоверение, которое подтверждает, что открытый ключ шифрования принадлежит определенному пользователю. Он является обязательной частью инфраструктуры открытых ключей (public key infrastructure, PKI), поскольку без подобной верификации открытый ключ уязвим для злонамеренных манипуляций.

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

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

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

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

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

Аппаратные токены

Аппаратный токен – это устройство, предназначенное специально для аутентификации.

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

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

 

Рисунок 2. Аппаратный токен с генерацией одноразовых ключей RSA SecurID

 

Однако даже в тех случаях, когда токен или смарт-карта играют роль обычного удостоверения, «изнутри» процедура аутентификации тоже может быть построена на сопоставлении временных паролей или на криптографических операциях. Например, устройство пользователя может получать от сервера случайную последовательность данных, шифровать ее и отправлять обратно, позволяя системе определить, чьим именно ключом было проведено преобразование. В отечественных реалиях криптографические алгоритмы токена должны соответствовать ГОСТу и иметь сертификат Федеральной службы безопасности.

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

Биометрия

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

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

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

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

 

Многофакторная (двухфакторная) аутентификация

Идеология многофакторной аутентификации (multi-factor authentication, MFA) заключается в том, чтобы взаимно компенсировать недостатки нескольких отдельных факторов, как минимум двух, у которых различаются ключевые риски. Чаще всего на практике используется двухфакторная аутентификация. Например, систему, построенную на аппаратных ключах, которые пользователи должны иметь при себе, можно усилить за счет механизма паролей, которые пользователи должны помнить. Тогда злоумышленник с токеном не будет знать пароля, а взломщик, укравший пароль, не будет иметь токена. Конечно, самый распространенный и общеизвестный вариант двухфакторной аутентификации – это два пароля, постоянный и одноразовый; однако сущность этой конструкции аналогична описанной выше, потому что базовым способом доставки одноразового пароля остается мобильная связь. Иными словами, подлинным признается тот пользователь, который знает постоянный пароль и имеет при себе смартфон, куда приходит пароль временный – так что устройство связи де-факто играет роль аппаратного токена.

Популярность и относительная надежность двухфакторной аутентификации приводят к тому, что на рынке появляются готовые решения, избавляющие клиента от необходимости разрабатывать все самому. Одно из них – упоминавшийся выше Google Authenticator, однако это приложение – не единственный вариант. Например, Symantec предлагает сервис VIP – Validation and Identity Protection (бывший VeriSign Identity Protection), который не бесплатен, но предлагает довольно разнообразные функции вроде бесконтактной разблокировки, когда сотруднику не нужно ничего вставлять в считыватель или подносить к нему – достаточно находиться рядом.

Стоит, однако, иметь в виду, что двухфакторная аутентификация не решает проблем той же парольной защиты в корне – она лишь усложняет задачу злоумышленника за счет ввода еще одного фактора. Ключевой изъян – отсутствие прямой связи с личностью пользователя – остается на месте. Поскольку возможность выдать себя за другого человека сохраняется, взломщики ищут (и находят) обходные пути. Например, при удаленной аутентификации не обязательно узнавать постоянный пароль: можно «доверить» пользователю ввести его самостоятельно, а затем перехватить или выманить одноразовый код. Такой подход уже состоит на вооружении у некоторых мошенников, в нужный момент присылающих сообщения вида «вам придет код, назовите мне его».

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

 

Выводы

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

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

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

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

Первая страница > Руководство по безопасности > Настройка аутентификации пользователя > Настройка аутентификации пользователя

Существует 5 методов аутентификации пользователя: аутентификация кода пользователя, простая аутентификация, аутентификация Windows, аутентификация LDAP и аутентификация сервера интеграции. Выберите способ аутентификаци на панели управления, а затем выполните необходимые настройки. Настройки зависят от метода аутентификации. Определите аутентификацию администратора, а затем аутентификацию пользователя.

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

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

Виды аутентификации пользователей

Тип	Подробнее
Аутентификация кода пользователя	Аутентификация производится с использованием восьмизначных кодов пользователей. Производится аутентификация каждого кода, а не каждого пользователя. Необходимо заранее зарегистрировать код пользователя в адресной книге аппарата.
Простая аутентификация	Аутентификация производится с использованием адресной книги аппарата. Необходимо заранее зарегистрировать пользователей в адресной книге аппарата. Можно аутентифицировать каждого пользователя индивидуально.
Аутентификация Windows	Аутентификация производится через сервер Windows, который находится в одной сети с аппаратом, при помощи контроллера домена. Можно аутентифицировать каждого пользователя индивидуально.
Аутентификация LDAP	Аутентификация производится через сервер LDAP, который находится в одной сети с аппаратом. Можно аутентифицировать каждого пользователя индивидуально.
Аутентификация сервера интеграции	Аутентификация производится через внешний сервер аутентификации, который находится в одной сети с аппаратом. Таким образом устанавливается операционная среда, где аутентифицируются все пользователи устройств (например многофункциональных портов и компьютеров) в сети. Можно аутентифицировать каждого пользователя индивидуально. Для создания внешнего сервера аутентификации необходимо программное обеспечение, в которое входит Менеджер Аутентификации (Authentication Manager), например, Remote Communication Gate S.

Адрес электронной почты пользователя, полученный посредством аутентификации Windows, LDAP или сервера интеграции, можно использовать в качестве фиксированного адреса отправителя («От») при отправке электронных сообщений в режиме сканера или при переадресации полученных факсов для предотвращения мошеничества с идентификаторами.

Если произошло переключение метода аутентификации пользователя

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

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

• С точки зрения безопасности, при переключении с аутентификации по коду пользователя на другой метод аутентификации рекомендуется удалить учетные записи, которые вы не используете, или установить пароль для входа в систему. Для получения подробных сведений об удалении учетных записей см. руководство «Подсоединение аппарата/Настройки системы». Для получения подробной информации об изменении паролей см. Указание имен пользователя и паролей для входа в систему.

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

• Аутентификацию пользователя можно также задать через Web Image Monitor. Для получения подробных сведений см. справку по Web Image Monitor.

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

Аутентификация – это процедура проверка подлинности пользователя перед предоставлением ему доступа к корпоративным ресурсам или сервисам. В “классическом” случае пользователь предъявляет пароль, соответствующий его учетной записи.

Усиленная аутентификация – это процедура проверки, при которой в дополнение или вместо “классической” проверки пароля, выполняются более надежные проверки.

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

Как правило, корпоративная система аутентификации включает в себя:

• сервисы аутентификации, например в составе службы каталогов Microsoft AD, шлюзов VPN и защищенного удаленного доступа, межсетевых экранов, точек доступа и контроллеров беспроводных сетей, коммутаторов и маршрутизаторов;
• систему управления аутентификацией и учетными данными;
• средства (носители) усиленной аутентификации, например USB-токены, смарт-карты, виртуальные токены, OTP-токены, программные средства аутентификации.

Основные функции корпоративной системы аутентификации

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

Законодательные требования

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

Результат применения решения

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

Предлагаемые решения

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

Примеры реализованных проектов

✅ Аутентификация: Определение, Методы, Виды — Определение

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

Она не тождественна идентификации и авторизации. Эти три термина являются элементами защиты информации. Первая стадия — идентификация. На ней происходит распознавание информации о пользователе, например, логин и пароль. Вторая стадия — аутентификация. Это процесс проверки информации о пользователе. Третья стадия — авторизация. Здесь происходит проверка прав пользователя и определяется возможность доступа.

Зачем нужна аутентификация

Аутентификация нужна для доступа к:

1. Соцсетям
2. Электронной почте
3. Интернет-магазинам
4. Форумам
5. Интернет-банкингу
6. Платежным системам

Элементы аутентификации

1. Субъект — пользователь
2. Характеристика субъекта — информация, предоставляемая пользователем для проверки подлинности.
3. Владелец системы аутентификации — владелец ресурса.
4. Механизм аутентификации — принцип проверки
5. Механизм авторизации — управление доступом

Методы аутентификации

1. Парольные
2. Комбинированные
3. Биометрические
4. Информация о пользователе
5. Пользовательские данные

Парольные

Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом. 

Комбинированные

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

Биометрические

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

Информация о пользователе

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

Пользовательские данные

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

Классификация видов аутентификации

В зависимости от количества используемых методов

• Однофакторная. Используется только один метод.
• Многофакторная. Используется несколько методов.

В зависимости от политики безопасности систем и уровня доверия

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

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

Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.

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

• Login
• PAP (Password Authentication Protocol) — логин и пароль
• Карта доступа — USB и сертификаты
• Биометрические данные

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

• Cookies. Используются для отслеживания сеанса, сохранения предпочтений и сбора статистики. Степень защиты невысокая, однако привязка к IP-адресу решает эту проблему.
• Kerberos. Протокол взаимной аутентификации с помощью криптографического ключа.
• SAML (Security Assertion Markup Language) Язык разметки, который позволяет сторонам обмениваться данными аутентификации.
• SNMP (Simple Network Management Protocol) Протокол, который контролирует подключенные к сети устройства.
• Сертификаты X.509 Сертификаты с открытым ключом.
• OpenID Connect. Используется для создания единой учетной записи для аутентификации на разных ресурсах.

Ресурсы

1. В этой статье детально рассмотрены элементы, факторы и способы аутентификации.
2. В этой статье объясняют, для доступа на какие сервисы нужна аутентификация и рассматривают классификацию её методов.

Обновлено: 31.07.2020

Оцените, насколько полезна статья «Аутентификация»

Оценка: 5 / 5 (17)

Идентификация, аутентификация и авторизация

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

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

Определения

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

• Идентификация — процесс распознавания пользователя по его идентификатору.
• Аутентификация — процедура проверки подлинности, доказательство что пользователь именно тот, за кого себя выдает.
• Авторизация — предоставление определённых прав.

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

Механизмы идентификации, аутентификации и авторизации

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

• Нечто, присущее только пользователю. Биометрические данные: сканеры лица, отпечатки пальцев или сетчатки глаза.
• Нечто, известное только пользователю. Сюда относятся pin-коды, пароли, графические ключи, секретные слова.
• Нечто, имеющееся у пользователя. В данном качестве может выступать токен, то есть компактное устройство, предназначенное для обеспечения информационной безопасности пользователя, также используется для идентификации владельца. Самые простые токены не требуют физического подключения к компьютеру – у них имеется дисплей, где отображается число, которое пользователь вводит в систему для осуществления входа; более сложные подключаются к компьютерам посредством USB и Bluetooth-интерфейсов.

Самый распространенный тип аутентификационных данных – это пароль. Именно поэтому так важно создавать и правильно хранить свои пароли. Подробнее об этом можно прочитать в статьях «Создание надежных паролей» и «Как правильно выбирать и хранить пароли». После ввода пользователем пароля система проверяет: соответствует ли условный пароль «Q45fp02@13» пользователю с именем Александр Петров. Таким образом происходит аутентификация. Если все верно, и пара логин-пароль верны, то система предоставит пользователю доступ к его ресурсам и совершение банковских операций, то есть произойдет авторизация. Описанные процессы всегда происходят только в таком порядке: идентификация, аутентификация, авторизация. Вся цепочка потеряет смысл, если, например, сайт сначала предоставит доступ к денежным средствам пользователя, а потом будет уточнять, он ли это на самом деле. Процессы идентификации, аутентификации и авторизации характерны не только для онлайн-банкинга, но и для электронной почты, социальных сетей и других ресурсов. В реальной жизни мы также сталкиваемся идентификацией, аутентификацией и авторизацией. Примером может служить проверка документов сотрудником полиции. Вы представились как Александр Петров, и сотрудник полиции идентифицировал Вас как Александра Петрова. Для аутентификации необходим паспорт, в котором видно, что Александр Петров выглядит так же, как и вы. Авторизацией в данном случае будет то, что сотрудник отпустит вас и пожелает счастливого пути, т.е. предоставит право свободного перемещения. Процессы идентификации, аутентификации и авторизации есть во многих сферах. Даже в простейших детских сказках. Сказка «Волк и семеро козлят» является идеальным примером для демонстрации. Здесь козлята выступают в роли системы безопасности, идентифицируя каждого, кто подходит к двери. В качестве данных для аутентификации выступает биометрия – тонкий голосок мамы-козы. И если в первый раз волк не смог пройти аутентификацию (его выдал грубый голос), то со второй попытки (после того как ему перековали горло, и он запел тонким голоском) он аутентифицировался как мама-коза и козлята «авторизовали» его в свою избу. Несмотря на то, что сказка закончилась благополучно, доступ к козлятам был получен неправомерно. Волку удалось обмануть процессы идентификации и аутентификации и тем самым пройти авторизацию. Если в старой детской сказке это оказалось возможным, то что говорить о современных злоумышленниках. Чтобы защитить свои денежные средства и персональные данные и козлят от волка от злоумышленника необходимо использовать более сложные способы аутентификации.

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

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

Однофакторная двухэтапная аутентификация

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

Аутентификация происходит следующим образом:

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

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

Рекомендации

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

Обзор способов и протоколов аутентификации в веб-приложениях

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

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Аутентификация по паролю

Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.

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

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:

1. Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус “401 Unauthorized” и добавляет заголовок “WWW-Authenticate” с указанием схемы и параметров аутентификации.
2. Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
3. Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок “Authorization”, в котором передаются данные пользователя для аутентификации сервером.
4. Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.

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

1. Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.
   
   Пример HTTP аутентификации с использованием Basic схемы.
2. Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
3. NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
4. Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.

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

Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

1. Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
2. Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.

Другие протоколы аутентификации по паролю

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

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

1. URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
2. Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
3. HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.

Распространенные уязвимости и ошибки реализации

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

Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:

• Веб-приложение позволяет пользователям создавать простые пароли.
• Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
• Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
• Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению, либо в строке URL.
• Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
• Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
• Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
• Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
• Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
• Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.
• Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
• Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.
• Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.

Аутентификация по сертификатам

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

certificate authority

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

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

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

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.

Аутентификация по одноразовым паролям

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

two-factor authentication

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

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

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

access key, API key

) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.

Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем

Single Sign-On

(SSO), где одно приложение (

service provider

или

relying party

) делегирует функцию аутентификации пользователей другому приложению (

identity provider

или

authentication service

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

доверяет

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

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
3. Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
2. Токен предназначается текущему SP-приложению (проверка поля audience).
3. Срок действия токена еще не истек (проверка поля expiration date).
4. Токен подлинный и не был изменен (проверка подписи).

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

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

1. Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.

   Пример SWT токена (после декодирования).
   

   Issuer=http://auth.myservice.com&
   Audience=http://myservice.com&
   ExpiresOn=1435937883&
   UserName=John Smith&
   UserRole=Admin&
   HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w

   
   
2. JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.

   Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
   

   { «alg»: «HS256», «typ»: «JWT» }.
   { «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
   S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY

3. Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

1. Assertions — собственный формат SAML токенов в XML формате.
2. Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
3. Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
4. Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

• Формат и способы обмена метаданными о сервисах.
• Функцию единого выхода из всех систем (single sign-out).
• Сервис атрибутов, предоставляющий дополнительную информацию о пользователе.
• Сервис псевдонимов, позволяющий создавать альтернативные имена пользователей.
• Поддержку пассивных клиентов (браузеров) посредством перенаправления.

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

1. Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
2. Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
3. Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

1. Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
2. Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
3. Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
4. Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).

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

1. Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
2. Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Способ	Основное применение	Протоколы
По паролю	Аутентификация пользователей	HTTP, Forms
По сертификатам	Аутентификация пользователей в безопасных приложениях; аутентификация сервисов	SSL/TLS
По одноразовым паролям	Дополнительная аутентификация пользователей (для достижения two-factor authentication)	Forms
По ключам доступа	Аутентификация сервисов и приложений	—
По токенам	Делегированная аутентификация пользователей; делегированная авторизация приложений	SAML, WS-Federation, OAuth, OpenID Connect

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

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

Аутентификация пользователей в Django — Документация Django 1.9

Django поставляется с системой аутентификации пользователей. Она обеспечивает пользовательские аккаунты, группы, права и сессии на основе куки. Этот раздел документации объясняет как работает стандартная реализация и как можно расширить и настроить её под нужды своего проекта.

Введение

Система аутентификации Django отвечает за оба аспекта: аутентификацию и авторизацию. Если коротко, то аутентификация проверяет пользователя, а авторизация определяет, что аутентифицированный пользователь может делать. Далее термин “аутентификация” будет использоваться для обозначения обоих аспектов.

Система аутентификации состоит из:

• Пользователей

• Прав: Бинарные (да/нет) флаги, определяющие наличие у пользователя права выполнять определённые действия.

• Групп: Общий способ назначения меток и прав на множество пользователей.

• Настраиваемой системы хеширования паролей

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

• Системы плагинов

Аутентификационная система Django старается быть очень простой и не предоставляет некоторые фичи, распространённые в других системах веб аутентификации. Такие фичи реализованы в сторонних пакетах:

• Проверка сложности пароля

• Ограничение попыток входа

• Аутентификация через сторонние сервисы (OAuth, например)

Установка

Поддержка аутентификации скомпонована в виде модуля в django.contrib.auth. По умолчанию, требуемые настройки уже включены в settings.py, создаваемый с помощью команды django-admin startproject, и представляют собой две записи в параметре конфигурации INSTALLED_APPS:

1. 'django.contrib.auth' содержит ядро системы аутентификации и её стандартные модели.

2. 'django.contrib.contenttypes' является фреймворком типов, который позволяет правам быть назначенными на создаваемые вами модели.

и записи в параметре конфигурации MIDDLEWARE_CLASSES:

1. SessionMiddleware управляет сессиями во время запросов.

2. AuthenticationMiddleware ассоциирует пользователей с запросами с помощью сессий.

3. SessionAuthenticationMiddleware разлогинит пользователя из всех его сессий, если он поменяет пароль.

При наличии этих настроек, применение команды manage.py migrate создаёт в базе данных необходимые для системы аутентификации таблицы, создаёт права для любых моделей всех зарегистрированных приложений.

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

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

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

Аутентификация пользователя — это процесс, который позволяет устройству проверить идентификацию того, кто подключается к сетевому ресурсу. Сейчас есть много технологий доступный сетевому администратору для аутентификации пользователей. Fireware работает с часто используемыми приложениями, включая RADIUS, Windows Active Directory, LDAP и SecurID на основе токенов.Firebox также имеет собственный сервер аутентификации. Вы можете использовать функции аутентификации Firebox для мониторинга и управления подключениями. через топку.

Аутентификация очень важна при использовании динамической IP-адресации (DHCP) для компьютеров в доверенной или дополнительной сети. Это также важно, если вы должны идентифицировать своих пользователей, прежде чем позволить им подключаться к ресурсам во внешней сети. Поскольку Firebox связывает имя пользователя с IP-адресом, мы не рекомендуем использовать функции аутентификации в сети с многопользовательскими компьютерами, такими как серверы Unix, серверы терминалов или серверы Citrix.Firebox аутентифицирует одного пользователя на каждом компьютере.

С WatchGuard System Manager вы может настроить аутентификацию для каждой политики. Например, вы можете заставить некоторые пользователи должны пройти аутентификацию перед подключением к FTP-серверу, хотя они может просматривать Интернет без аутентификации.

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

Вернуться к началу

Copyright 1996–2005 WatchGuard Technologies, Inc. Все права защищены.
Официальное уведомление / Условия использования

Основные сведения и полезные советы

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

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

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

1. Что такое аутентификация пользователя
2. Как работает аутентификация пользователя
3. Важность аутентификации пользователя
4. Основные методы аутентификации пользователя
5. Как улучшить аутентификацию пользователя

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

Давайте перейдем к первому разделу.

1. Что такое аутентификация пользователя

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

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

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

2. Как работает аутентификация пользователя

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

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

Проще говоря, аутентификация пользователя имеет три задачи:

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

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

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

3. Важность аутентификации пользователей

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

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

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

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

Swoop — это простой и безопасный сервис аутентификации без пароля. Благодаря нашей запатентованной технологии Magic Link ™ и Magic Message ™ ваш веб-сайт может повысить безопасность и повысить конверсию клиентов за счет удаления паролей. Попробуйте Swoop для Бесплатно

4. Основные методы аутентификации пользователей

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

• Факторы знания. Факторы, которые пользователь должен знать для входа в систему, считаются фактором знания. Это может быть что угодно, от имени пользователя, пароля или пин-кода. Проблема с этими факторами заключается в том, что они могут быть слабыми с точки зрения безопасности, поскольку их можно разделить или угадать.
• Факторы владения. Все, что необходимо пользователю для входа в систему, называется фактором владения.Жетоны одноразового пароля, такие как Magic Link ™, брелки, идентификационные карты и физические жетоны, считаются факторами владения.
• Факторы наследования. Использование биологических характеристик человека известно как фактор наследования. В эту категорию попадает любой процесс биометрической аутентификации, такой как сканирование отпечатков пальцев и распознавание лиц.

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

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

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

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

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

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

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

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

Более того, 54% пользователей используют пять или меньше разных паролей для своих учетных записей.

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

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

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

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

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

Биометрия

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

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

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

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

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

• Создавая эталонный отпечаток с характеристиками, типичными для большинства отпечатков пальцев, хакеры могут обмануть сканеры в 65% случаев.
• Кроме того, высококачественных изображений можно использовать для обмана систем распознавания лиц.
• Если кому-то удастся украсть ваши отпечатки пальцев или изображение лица, вы больше никогда не сможете безопасно использовать этот метод аутентификации.
• Биометрия доступна не всем ; для этого метода аутентификации требуется специальное устройство, которое может сканировать отпечатки пальцев, радужную оболочку глаза или лица, что может быть очень дорогостоящим для пользователя.
• В свете недавних событий некоторые крупные технологические компании, такие как IBM, полностью отказываются от бизнеса по распознаванию лиц.Во многом это происходит из-за боязни массового наблюдения и расового профилирования, которые возможны с помощью таких технологий.

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

Аутентификация по электронной почте

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

Процесс аутентификации электронной почты может выглядеть по-разному в зависимости от инструментов, которые вы выбрали для начала работы. Swoop предлагает высокотехнологичную аутентификацию электронной почты для предприятий всех форм и размеров с двумя основными методами аутентификации — Magic Link ™ и Magic Message ™. Процесс входа в систему Magic Message ™ выглядит следующим образом:

1. Пользователь перенаправляется на службу Swoop через OAuth 2.0 для аутентификации.
2. В окне браузера пользователь нажимает кнопку «Отправить Magic Message ™»: Кнопка активирует ссылку mailto, которая генерирует заранее написанное электронное письмо для отправки пользователем.
3. Пользователь отправляет электронное письмо: Здесь происходит волшебство. После отправки электронной почты сервер исходящей электронной почты генерирует и встраивает полностью зашифрованный цифровой ключ размером 1024/2048 бит в заголовок электронного письма. Сервер аутентификации Swoop следует криптографической процедуре с открытым ключом для расшифровки этого ключа.Каждое отправленное письмо получает уникальный ключ для этого сообщения. Уровень безопасности этих зашифрованных ключей несравним с традиционными паролями.
4. Пользователь вошел в свою учетную запись: Когда ключ расшифровывает и проходит все уровни проверки, сервер аутентификации Swoop дает указание веб-сайту открыть учетную запись пользователя и начать сеанс. Все это происходит в считанные секунды и значительно упрощает взаимодействие с пользователем.

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

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

5. Как улучшить аутентификацию пользователей

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

Поощряйте использование более надежных паролей для повышения безопасности.

Мы знаем, что пароли — не лучшая идея из-за различных уязвимостей, которые они приносят с собой из-за небезопасных учетных данных, создаваемых пользователями. Однако может потребоваться время, чтобы перевести весь Интернет (или даже только ваших пользователей) в режим онлайн без пароля.

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

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

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

Еще больше советов по паролям можно найти на этом изображении:

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

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

Реализовать аутентификацию SSO.

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

Google — отличный пример того, как работает эта система. Когда пользователь входит в свою учетную запись Gmail, он получает доступ ко всем сервисам Google — YouTube, Google Analytics, Google Диск и т. Д. — без необходимости повторного входа.

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

Включение стратегии многофакторной аутентификации.

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

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

Изучите аутентификацию без пароля.

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

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

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

Наше любимое решение? Методы аутентификации электронной почты Swoop’s Magic. Узнайте больше о том, как Swoop может помочь вам и вашему бизнесу в будущем без пароля с помощью этой интерактивной демонстрации.

---

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

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

Django Tutorial Part 8: User authentication and permissions — Learn web development

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

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

Примечание

Согласно Django, система аутентификации должна быть очень общей и поэтому не предоставляет некоторых функций, предоставляемых в других системах веб-аутентификации. Решения некоторых распространенных проблем доступны в виде пакетов сторонних производителей. Например, регулирование попыток входа в систему и аутентификация от третьих лиц (например, OAuth).

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

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

Мы также покажем вам, как создавать разрешения и проверять статус входа и разрешения как в представлениях, так и в шаблонах.

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

Примечание

Необходимая конфигурация была сделана за нас, когда мы создали приложение с помощью команды django-admin startproject . Таблицы базы данных для пользователей и разрешений модели были созданы при первом вызове python manage.py migrate .

Конфигурация устанавливается в разделах INSTALLED_APPS и MIDDLEWARE файла проекта ( locallibrary / locallibrary / settings.py ), как показано ниже:

  INSTALLED_APPS = [
    ...
    'django.contrib.auth',
    'django.contrib.contenttypes',
    ....

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ = [
    ...
    'django.contrib.sessions.middleware.SessionMiddleware',
    ...
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    ....
  

Вы уже создали своего первого пользователя, когда мы просматривали сайт администратора Django в учебнике 4 (это был суперпользователь, созданный с помощью команды python manage.py createduperuser) . Наш суперпользователь уже аутентифицирован и имеет все разрешения, поэтому нам нужно создать тестового пользователя, который будет представлять обычного пользователя сайта. Мы будем использовать сайт администратора для создания групп locallibrary и логинов на веб-сайтах, поскольку это один из самых быстрых способов сделать это.

Примечание

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

  из django.contrib.auth.models import User


user = User.objects.create_user ('myusername', '[email protected]', 'mypassword')


user.first_name = 'Джон'
user.last_name = 'Гражданин'
user.save ()
  

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

Запустите сервер разработки и перейдите на сайт администратора в локальном веб-браузере (http://127.0.0.1:8000/admin/). Войдите на сайт, используя учетные данные своей учетной записи суперпользователя. На верхнем уровне сайта администратора отображаются все ваши модели, отсортированные по «приложению Django». В разделе Аутентификация и авторизация вы можете щелкнуть ссылки Пользователи или Группы , чтобы просмотреть свои существующие записи.

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

1. Нажмите кнопку « Добавить » (рядом с «Группа»), чтобы создать новую группу ; введите Имя «Члены библиотеки» для группы.
2. Нам не нужны разрешения для группы, поэтому просто нажмите СОХРАНИТЬ (вы попадете в список групп).

Теперь создадим пользователя:

1. Вернуться на главную страницу админки
2. Нажмите кнопку Добавить рядом с Пользователи , чтобы открыть диалоговое окно Добавить пользователя .
3. Введите соответствующее имя пользователя и пароль / Подтверждение пароля для вашего тестового пользователя
4. Нажмите СОХРАНИТЬ , чтобы создать пользователя.

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

5. В разделе Группы выберите группу Элемент библиотеки из списка Доступных групп , а затем нажмите стрелку вправо между полями, чтобы переместить ее в поле Выбранные группы .
6. Нам больше здесь ничего делать не нужно, поэтому просто выберите SAVE еще раз, чтобы перейти к списку пользователей.

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

Примечание

Вам следует попробовать создать другого пользователя-члена библиотеки. Кроме того, создайте группу для библиотекарей и добавьте в нее пользователя!

Django предоставляет почти все необходимое для создания страниц аутентификации для обработки входа в систему, выхода из системы и управления паролями «из коробки». Это включает в себя преобразователь URL-адресов, представления и формы, но не включает шаблоны — мы должны создать свои собственные!

В этом разделе мы покажем, как интегрировать систему по умолчанию в веб-сайт LocalLibrary и создать шаблоны.Мы разместим их в основных URL-адресах проекта.

Примечание

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

Примечание

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

URL-адреса проектов

Добавьте в конец файла проекта urls.py ( locallibrary / locallibrary / urls.py ) следующее:

 

urlpatterns + = [
    путь ('accounts /', include ('django.contrib.auth.urls')),
]
  

Перейдите по URL-адресу http://127.0.0.1:8000/accounts/ (обратите внимание на косую черту в конце!), И Django покажет ошибку, что ему не удалось найти этот URL-адрес, и перечислит все URL-адреса, которые он пробовал.Отсюда вы можете увидеть URL-адреса, которые будут работать, например:

Примечание

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

  учетных записей / логин / [имя = 'логин']
аккаунты / logout / [name = 'logout']
учетные записи / password_change / [name = 'password_change']
account / password_change / done / [name = 'password_change_done']
учетные записи / password_reset / [name = 'password_reset']
учетные записи / password_reset / done / [name = 'password_reset_done']
account / reset /  /  / [name = 'password_reset_confirm']
учетные записи / сброс / готово / [name = 'password_reset_complete']  

Теперь попробуйте перейти по URL-адресу для входа (http: // 127.0.0.1: 8000 / accounts / login /). Это снова не удастся, но с ошибкой, говорящей о том, что нам не хватает необходимого шаблона ( registration / login.html ) в пути поиска шаблона. Вы увидите следующие строки, перечисленные в желтом разделе вверху:

  Тип исключения: TemplateDoesNotExist
Значение исключения: registration / login.html  

Следующим шагом является создание каталога регистрации на пути поиска, а затем добавление файла login.html .

Каталог шаблонов

URL-адреса (и неявно представления), которые мы только что добавили, ожидают найти связанные с ними шаблоны в каталоге / registration / где-нибудь в пути поиска шаблонов.

Для этого сайта мы поместим наши HTML-страницы в каталог templates / registration / . Этот каталог должен находиться в корневом каталоге вашего проекта, то есть в том же каталоге, что и папки каталога и locallibrary ). Пожалуйста, создайте эти папки сейчас.

Примечание

Ваша структура папок теперь должна выглядеть следующим образом:
locallibrary (папка проекта Django)
| _catalog
| _locallibrary
| _templates (new)
| _registration

Чтобы сделать каталог templates видимым для загрузчика шаблонов, нам нужно добавить его в путь поиска шаблонов. Откройте настройки проекта ( /locallibrary/locallibrary/settings.py ).

Затем импортируйте модуль os (добавьте следующую строку в верхней части файла).

Обновите строку 'DIRS' раздела TEMPLATES , как показано:

  ...
    ШАБЛОНЫ = [
      {
       ...
       'DIRS': [os.path.join (BASE_DIR, 'templates')],
       "APP_DIRS": Верно,
       ...
      

Шаблон входа

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

Создайте новый файл HTML с именем / locallibrary / templates / registration / login.html и дайте ему следующее содержимое:

  {% extends "base_generic.html"%}

{% блокировать содержание%}

  {% if form.errors%}
    
 Ваше имя пользователя и пароль не совпадают. Пожалуйста, попробуйте еще раз. 
  {% endif%}

  {% если следующий%}
    {% if user.is_authenticated%}
      
 У вашей учетной записи нет доступа к этой странице. Продолжать,
      пожалуйста, войдите с учетной записью, у которой есть доступ. 
    {% еще %}
      
 Пожалуйста, войдите, чтобы увидеть эту страницу. 
    {% endif%}
  {% endif%}

  

    {% csrf_token%}
    <таблица>
      
         {{форма.username.label_tag}} 
         {{form.username}} 
      
      
         {{form.password.label_tag}} 
         {{form.password}} 
      
    
    
    
  

  {# Предполагается, что вы установили представление password_reset в своем URLconf #}
  
  Забыли пароль?  

{% endblock%}  

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

После сохранения шаблона вернитесь на страницу входа (http://127.0.0.1:8000/accounts/login/) и увидите что-то вроде этого:

Если вы войдете в систему с действительными учетными данными, вы будете перенаправлены на другую страницу (по умолчанию это будет http: // 127.0.0.1: 8000 / accounts / profile /). Проблема в том, что по умолчанию Django ожидает, что при входе в систему вы захотите попасть на страницу профиля, что может быть, а может и нет. Поскольку вы еще не определили эту страницу, вы получите еще одну ошибку!

Откройте настройки проекта ( /locallibrary/locallibrary/settings.py ) и добавьте текст ниже внизу. Теперь, когда вы входите в систему, вы по умолчанию должны быть перенаправлены на домашнюю страницу сайта.

Шаблон выхода из системы

Если вы перейдете по URL-адресу выхода (http: // 127.0.0.1: 8000 / accounts / logout /), то вы увидите странное поведение — ваш пользователь наверняка выйдет из системы, но вы попадете на страницу выхода Admin . Это не то, что вам нужно, хотя бы потому, что ссылка для входа на этой странице приведет вас к экрану входа в систему администратора (и он доступен только пользователям, имеющим разрешение is_staff ).

Создайте и откройте / locallibrary / templates / registration / logged_out.html . Скопируйте в текст ниже:

  {% extends "base_generic.html "%}

{% блокировать содержание%}
  
 Вышел из системы! 
   Нажмите здесь, чтобы снова войти в систему. 
{% endblock%}  

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

Шаблоны сброса пароля

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

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

Форма для сброса пароля

Это форма, используемая для получения адреса электронной почты пользователя (для отправки электронного письма для сброса пароля). Создайте /locallibrary/templates/registration/password_reset_form.html и присвойте ему следующее содержимое:

  {% extends "base_generic.html "%}

{% блокировать содержание%}
  

  {% csrf_token%}
  {% if form.email.errors%}
    {{form.email.errors}}
  {% endif%}
      
 {{form.email}} 
    
  
{% endblock%}
  

Пароль сброшен

Эта форма отображается после получения вашего адреса электронной почты. Создайте /locallibrary/templates/registration/password_reset_done.html и присвойте ему следующее содержимое:

  {% extends "base_generic.html "%}

{% блокировать содержание%}
  
 Мы отправили вам по электронной почте инструкции по установке пароля. Если они не пришли через несколько минут, проверьте папку со спамом. 
{% endblock%}
  

Электронная почта для сброса пароля

Этот шаблон содержит текст электронного письма в формате HTML, содержащего ссылку для сброса, которую мы отправим пользователям. Создайте /locallibrary/templates/registration/password_reset_email.html и присвойте ему следующее содержимое:

  Кто-то попросил сбросить пароль для электронной почты {{email}}.Перейдите по ссылке ниже:
{{протокол}}: // {{домен}} {% url 'password_reset_confirm' uidb64 = uid token = token%}
  

Подтверждение сброса пароля

На этой странице вы вводите новый пароль, щелкнув ссылку в электронном письме для сброса пароля. Создайте /locallibrary/templates/registration/password_reset_confirm.html и присвойте ему следующее содержимое:

  {% extends "base_generic.html"%}

{% блокировать содержание%}
    {% if validlink%}
        
 Пожалуйста, введите (и подтвердите) ваш новый пароль.
        

        {% csrf_token%}
            <таблица>
                
                     {{form.new_password1.errors}}
                         Новый пароль:  
                     {{form.new_password1}} 
                
                
                     {{form.new_password2.errors}}
                         Подтвердите пароль:  
                     {{форма.new_password2}} 
                
                
                     
                      
                
            
        
    {% еще %}
         
 Не удалось сбросить пароль 
 
        
 Ссылка для сброса пароля недействительна, возможно, потому, что она уже использовалась. Запросите новый сброс пароля. 
    {% endif%}
{% endblock%}
  

Сброс пароля завершен

Это последний шаблон сброса пароля, который отображается, чтобы уведомить вас об успешном сбросе пароля.Создайте /locallibrary/templates/registration/password_reset_complete.html и присвойте ему следующее содержимое:

  {% extends "base_generic.html"%}

{% блокировать содержание%}
   
 Пароль изменен! 
 
  
  войти снова?  
{% endblock%}  

Тестирование новых страниц аутентификации

Теперь, когда вы добавили конфигурацию URL и создали все эти шаблоны, страницы аутентификации должны работать!

Вы можете протестировать новые страницы аутентификации, попытавшись войти в свою учетную запись суперпользователя, а затем выйти из нее, используя следующие URL-адреса:

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

Примечание

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

  EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend ' 

Для получения дополнительной информации см. Отправка электронной почты (документы Django).

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

Тестирование в шаблонах

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

Обычно вы сначала проверяете переменную шаблона {{user.is_authenticated}} , чтобы определить, имеет ли пользователь право на просмотр определенного содержания. Чтобы продемонстрировать это, теперь мы обновим нашу боковую панель, чтобы отобразить ссылку «Войти», если пользователь вышел из системы, и ссылку «Выход», если он вошел в систему.

Откройте базовый шаблон ( /locallibrary/catalog/templates/base_generic.html ) и скопируйте следующий текст в блок боковой панели непосредственно перед тегом шаблона endblock .

  


    ...

   {% if user.is_authenticated%}
     
 Пользователь: {{user.get_username}} 
     
  Выйти  
   {% еще %}
     
  Войти  
   {% endif%}
  
  

Как видите, мы используем if - else - endif теги шаблона для условного отображения текста в зависимости от того, является ли {{user.is_authenticated}} верно. Если пользователь аутентифицирован, мы знаем, что у нас есть действующий пользователь, поэтому мы вызываем {{user.get_username}} , чтобы отобразить его имя.

Мы создаем URL-адреса ссылок для входа и выхода, используя тег шаблона url и имена соответствующих конфигураций URL. Также обратите внимание, как мы добавили ? Next = {{request.path}} в конец URL-адресов. При этом в конец связанного URL-адреса добавляется параметр следующий , содержащий адрес (URL) текущей страницы .После того, как пользователь успешно выполнил вход / выход, представления будут использовать это значение « следующий » для перенаправления пользователя обратно на страницу, где они впервые щелкнули ссылку входа / выхода.

Примечание

Попробуйте! Если вы находитесь на домашней странице и нажимаете «Вход / выход» на боковой панели, то после завершения операции вы должны вернуться на ту же страницу.

Тестирование в представлениях

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

  из django.contrib.auth.decorators import login_required

@login_required
def my_view (запрос):
    ...  

Примечание

Вы можете сделать то же самое вручную, протестировав request.user.is_authenticated , но декоратор намного удобнее!

Аналогичным образом, самый простой способ ограничить доступ для зарегистрированных пользователей в представлениях на основе классов - это унаследовать от LoginRequiredMixin . Вам нужно объявить этот миксин первым в списке суперклассов, перед основным классом представления.

  из django.contrib.auth.mixins import LoginRequiredMixin

класс MyView (LoginRequiredMixin, View):
    ...  

Он имеет точно такое же поведение перенаправления, что и декоратор login_required . Вы также можете указать альтернативное расположение для перенаправления пользователя, если он не аутентифицирован ( login_url ), и имя параметра URL вместо « next » для вставки текущего абсолютного пути ( redirect_field_name ).

  класс MyView (LoginRequiredMixin, View):
    login_url = '/ логин /'
    redirect_field_name = 'redirect_to'
  

Для получения дополнительных сведений ознакомьтесь с документацией по Django здесь.

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

К сожалению, у нас пока нет возможности брать книги напрокат! Поэтому, прежде чем мы сможем создать список книг, мы сначала расширим модель BookInstance для поддержки концепции заимствования и воспользуемся приложением Django Admin, чтобы одолжить несколько книг нашему тестирующему пользователю.

Models

Во-первых, мы собираемся предоставить пользователям возможность иметь экземпляр BookInstance на правах аренды (у нас уже есть статус и дата due_back , но у нас еще нет связь между этой моделью и пользователем.Мы создадим его, используя поле ForeignKey (один ко многим). Нам также нужен простой механизм для проверки того, просрочена ли кредитная книга.

Откройте каталог catalog / models.py и импортируйте модель User из django.contrib.auth.models (добавьте это чуть ниже предыдущей строки импорта вверху файла, чтобы пользователь User был доступен для последующий код, который его использует):

  из django.contrib.auth.models import User
  

Затем добавьте поле заемщика в модель BookInstance :

  заемщик = модели.ForeignKey (Пользователь, on_delete = models.SET_NULL, null = True, blank = True)
  

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

Добавьте это где-нибудь в верхней части файла:

  от даты импорта даты и времени  

Теперь добавьте следующее определение свойства к классу BookInstance :

  @property
def is_overdue (сам):
    если сам.due_back и date.today ()> self.due_back:
        вернуть True
    возврат Ложь  

Примечание

Мы сначала проверяем, является ли due_back пустым, прежде чем проводить сравнение. Пустое поле due_back приведет к тому, что Django выдаст ошибку вместо отображения страницы: пустые значения не сопоставимы. Это не то, чего мы хотели бы, чтобы наши пользователи испытали!

Теперь, когда мы обновили наши модели, нам нужно выполнить новые миграции в проекте, а затем применить эти миграции:

  python3 manage.миграция
python3 manage.py мигрировать
  

Admin

Теперь откройте каталог catalog / admin.py и добавьте поле заемщика в класс BookInstanceAdmin в обоих наборах полей list_display и , как показано ниже. Это сделает поле видимым в разделе администратора, что позволит нам при необходимости назначить пользователя и BookInstance .

  @ admin.register (BookInstance)
класс BookInstanceAdmin (admin.ModelAdmin):
    list_display = ('книга', 'статус', 'заемщик', 'due_back', 'id')
    list_filter = ('статус', 'due_back')

    fieldsets = (
        (Никто, {
            'поля': ('книга', 'отпечаток', 'идентификатор')
        }),
        ('Доступность', {
            'fields': ('status', 'due_back', 'заемщик')
        }),
    )  

Ссудите несколько книг

Теперь, когда можно ссудить книги конкретному пользователю, перейдите и одолжите несколько записей BookInstance . Задайте для своего тестового пользователя поле заимствованных , сделайте статус «В ссуде» и установите даты платежа в будущем и в прошлом.

Примечание

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

Представление взаймы

Теперь мы добавим представление для получения списка всех книг, которые были переданы текущему пользователю. Мы будем использовать то же общее представление списка на основе классов, с которым мы знакомы, но на этот раз мы также импортируем и унаследуем от LoginRequiredMixin , чтобы только зарегистрированный пользователь мог вызывать это представление. Мы также выберем объявление template_name вместо использования значения по умолчанию, потому что у нас может получиться несколько разных списков записей BookInstance с разными представлениями и шаблонами.

Добавьте в каталог / views.py следующее:

  из django.contrib.auth.mixins import LoginRequiredMixin

класс LoanedBooksByUserListView (LoginRequiredMixin, generic.ListView):
    "" "Общий просмотр на основе классов со списком книг, предоставленных текущему пользователю." ""
    model = BookInstance
    template_name = 'catalog / bookinstance_list_borrowed_user.html'
    paginate_by = 10

    def get_queryset (сам):
        вернуть BookInstance.objects.filter (заемщик = self.request.user) .filter (status__exact = 'o').order_by ('due_back')  

Чтобы ограничить наш запрос только объектами BookInstance для текущего пользователя, мы повторно реализуем get_queryset () , как показано выше. Обратите внимание, что «o» — это сохраненный код для «взаймы», и мы заказываем по дате due_back , чтобы в первую очередь отображались самые старые элементы.

URL conf для ссудных книг

Теперь откройте /catalog/urls.py и добавьте путь () , указывающий на приведенный выше вид (вы можете просто скопировать текст ниже в конец файла).

  шаблоны URL + = [
    путь ('mybooks /', views.LoanedBooksByUserListView.as_view (), name = 'my-заимствовано'),
]  

Шаблон для кредитных книг

Теперь все, что нам нужно сделать для этой страницы, — это добавить шаблон. Сначала создайте файл шаблона /catalog/templates/catalog/bookinstance_list_borrowed_user.html и дайте ему следующее содержимое:

  {% extends "base_generic.html"%}

{% блокировать содержание%}
     
 Взятые книги 
 

    {% if bookinstance_list%}
    


      {% для bookinst в bookinstance_list%}
      

         {{bookinst.book.title}}  ({{bookinst.due_back}})
      
      {% endfor%}
    

    {% еще %}
      
 Книги взаймы нет. 
    {% endif%}
{% endblock%}  

Этот шаблон очень похож на те, которые мы создали ранее для объектов Book и Author . Единственное, что здесь «ново», это то, что мы проверяем метод, который мы добавили в модель (bookinst.is_overdue ), и используем его для изменения цвета просроченных элементов.

Когда сервер разработки запущен, теперь вы должны иметь возможность просмотреть список для вошедшего в систему пользователя в своем браузере по адресу http://127.0.0.1:8000/catalog/mybooks/. Попробуйте это, когда ваш пользователь вошел в систему и вышел из нее (во втором случае вы должны быть перенаправлены на страницу входа).

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

Откройте базовый шаблон ( / locallibrary / catalog / templates / base_generic.html ) и добавьте строку «Мое заимствование» на боковую панель в позиции, показанной ниже.

  

   {% if user.is_authenticated%}
   
 Пользователь: {{user.get_username}} 

   
  Мое заимствование  
   
   
  Выйти  
   {% еще %}
   
  Войти  
   {% endif%}
 
  

Как это выглядит?

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

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

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

Models

Определение разрешений выполняется в разделе модели « class Meta » с использованием поля permissions . Вы можете указать столько разрешений, сколько вам нужно в кортеже, каждое разрешение само определяется во вложенном кортеже, содержащем имя разрешения и отображаемое значение разрешения.Например, мы могли бы определить разрешение, позволяющее пользователю отмечать, что книга была возвращена, как показано:

  класс BookInstance (models.Model):
    ...
    класс Мета:
        ...
        permissions = (("can_mark_returned", "Установить книгу как возвращенную"),)  

Затем мы могли бы назначить разрешение группе «Библиотекарь» на сайте администратора.

Откройте каталог catalog / models.py и добавьте разрешение, как показано выше. Вам нужно будет повторно запустить миграцию (вызовите python3 manage.py makemigrations и python3 manage.py migrate ), чтобы обновить базу данных соответствующим образом.

Шаблоны

Права доступа текущего пользователя хранятся в переменной шаблона с именем {{perms}} . Вы можете проверить, есть ли у текущего пользователя конкретное разрешение, используя конкретное имя переменной в соответствующем «приложении» Django — например, {{perms.catalog.can_mark_returned}} будет Истинно, , если у пользователя есть это разрешение, и Ложь, в противном случае.Обычно мы проверяем наличие разрешения с помощью тега шаблона {% if%} , как показано:

  {% if perms.catalog.can_mark_returned%}
    
    
{% endif%}
  

Представления

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

Декоратор представления функций:

  из django.contrib.auth.decorators import permission_required

@permission_required ('catalog.can_mark_returned')
@permission_required ('catalog.can_edit')
def my_view (запрос):
    ...  

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

  из django.contrib.auth.mixins импорт PermissionRequiredMixin

класс MyView (PermissionRequiredMixin, View):
    permission_required = 'каталог.can_mark_returned '
    
    разрешение_required = ('catalog.can_mark_returned', 'catalog.can_edit')
    
      

Примечание

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

• @permission_required перенаправляет на экран входа в систему (статус HTTP 302).
• PermissionRequiredMixin возвращает 403 (HTTP-статус запрещен).

Обычно вам нужно поведение PermissionRequiredMixin : вернуть 403, если пользователь вошел в систему, но не имеет правильных разрешений.Чтобы сделать это для представления функции, используйте @login_required и @permission_required с raise_exception = True , как показано:

  из django.contrib.auth.decorators import login_required, permission_required

@login_required
@permission_required ('catalog.can_mark_returned', raise_exception = Истина)
def my_view (запрос):
    ...  

Пример

Мы не будем обновлять LocalLibrary здесь; возможно, в следующем уроке!

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

Вы должны быть в состоянии следовать той же схеме, что и для другого вида. Основное отличие состоит в том, что вам нужно ограничить просмотр только библиотекарями. Это можно сделать в зависимости от того, является ли пользователь сотрудником (декоратор функции: staff_member_required , переменная шаблона: user.is_staff ), но мы рекомендуем вместо этого использовать разрешение can_mark_returned и PermissionRequiredMixin , как описано в предыдущем разделе.

Важно

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

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

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

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

Общие сведения об аутентификации, авторизации и шифровании: TechWeb: Бостонский университет

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

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

Авторизация

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

Шифрование

• Шифрование включает в себя процесс преобразования данных, чтобы их не мог прочитать любой, у кого нет ключа дешифрования.
• Протоколы Secure Shell (SSH) и Socket Layer (SSL) обычно используются в процессах шифрования. SSL управляет защищенной частью сайтов «http s : //», используемых на сайтах электронной коммерции (таких как E-Bay и Amazon.ком.)
• Все данные в транзакциях SSL шифруются между клиентом (браузером) и сервером (веб-сервером) перед передачей данных между ними.
• Все данные в сеансах SSH зашифрованы между клиентом и сервером при обмене данными в оболочке.
• Путем шифрования данных, которыми обмениваются клиент и сервер, информация, такая как номера социального страхования, номера кредитных карт и домашние адреса, может быть отправлена ​​через Интернет с меньшим риском перехвата во время передачи.

Использование аутентификации, авторизации и шифрования

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

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

Вот несколько примеров того, как компьютеры используют шифрование, аутентификацию и авторизацию:

• Шифрование следует использовать всякий раз, когда люди предоставляют личную информацию для регистрации или покупки продукта.Это обеспечивает конфиденциальность человека во время общения. Шифрование также часто используется, когда данные, возвращаемые сервером клиенту, должны быть защищены, например, финансовый отчет или результаты тестирования.
• Аутентификацию следует использовать всякий раз, когда вы хотите точно знать, кто использует или просматривает ваш сайт. Weblogin — это основной метод аутентификации Бостонского университета. Другие коммерческие веб-сайты, такие как Amazon.com, требуют, чтобы люди входили в систему перед покупкой продуктов, чтобы они точно знали, кто их покупатели.
• Авторизация должна использоваться всякий раз, когда вы хотите контролировать доступ зрителей к определенным страницам. Например, студентам Бостонского университета не разрешается просматривать определенные веб-страницы, посвященные профессорам и администрации. Требования авторизации для сайта обычно определяются в файле .htaccess.
• Аутентификация и авторизация часто используются вместе. Например, студенты Бостонского университета должны пройти аутентификацию перед доступом к Студенческой ссылке.Предоставляемая ими аутентификация определяет, какие данные им разрешено просматривать. На этапе авторизации учащиеся не могут просматривать данные других учащихся.

Ссылки для обучения настройке авторизации, аутентификации и шифрования

• Использование аутентификации и авторизации на институциональных веб-серверах BU [www.bu.edu, people.bu.edu]
• Настройка вашего веб-сервера для использования шифрования
• клиентов SSH

Аутентификация конечного пользователя с помощью OAuth 2.0 — OAuth

Аутентификация пользователя с помощью OAuth 2.0

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

OAuth 2.0 не является протоколом аутентификации.

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

Эта статья предназначена для того, чтобы помочь потенциальным поставщикам удостоверений решить вопрос о том, как создать API аутентификации и идентификации, используя OAuth 2.0 в качестве основы. По сути, если вы говорите: «У меня есть OAuth 2.0, и мне нужны аутентификация и идентификация», читайте дальше.

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

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

Однако OAuth ничего не сообщает приложению. OAuth абсолютно ничего не говорит о пользователе и не говорит, как пользователь доказал свое присутствие или даже если он еще там.Что касается клиента OAuth, он запросил токен, получил токен и в конечном итоге использовал этот токен для доступа к некоторому API. Ему ничего не известно о том, кто авторизовал приложение и был ли там вообще пользователь. Фактически, большая часть смысла OAuth заключается в предоставлении этого делегированного доступа для использования в ситуациях, когда пользователь не присутствует в соединении между клиентом и ресурсом, к которому осуществляется доступ. Это отлично подходит для авторизации клиентов, но действительно плохо для аутентификации, когда все дело в том, чтобы выяснить, находится ли пользователь там или нет (и кто они).

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

Однако оказывается, что есть несколько вещей, которые можно использовать вместе с OAuth, чтобы создать протокол аутентификации и идентификации поверх этого протокола делегирования и авторизации. Почти во всех этих случаях основные функции OAuth остаются неизменными, и происходит то, что пользователь делегирует доступ к своему удостоверению приложению, в которое он пытается войти. Затем клиентское приложение становится потребителем API идентификации, тем самым выясняя, кто первым авторизовал клиента.Одним из основных преимуществ создания аутентификации поверх авторизации таким образом является то, что она позволяет управлять согласием конечных пользователей, что очень важно для междоменной федерации удостоверений в масштабе Интернета. Еще одно важное преимущество заключается в том, что пользователь может одновременно делегировать доступ к другим защищенным API наряду с своей идентичностью, что значительно упрощает управление как разработчикам приложений, так и конечным пользователям. С помощью одного вызова приложение может узнать, вошел ли пользователь в систему, что приложение должно вызывать пользователя, загружать фотографии для печати и публиковать обновления в своем потоке сообщений.Эта простота очень убедительна, но, выполняя обе функции одновременно, многие разработчики объединяют две функции.

Аутентификация против авторизации: метафора

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

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

И на самом деле, существует ряд хорошо известных рецептов, как сделать это с конкретными поставщиками, такими как Facebook Connect, Sign In With Twitter и OpenID Connect (который, среди прочего, поддерживает систему входа Google).Каждый из этих рецептов добавляет в OAuth ряд элементов, например API общего профиля, для создания протокола аутентификации. Можете ли вы создать протокол аутентификации без OAuth? Конечно, существует множество видов помадки, равно как и множество видов нешоколадной помадки. Но сегодня мы поговорим о проверке подлинности, построенной на основе OAuth 2.0, о том, что может пойти не так, а также о том, как сделать ее безопасной и вкусной.

Распространенные ошибки аутентификации с использованием OAuth

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

Жетоны доступа как доказательство аутентификации

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

Эта проблема возникает из-за того, что клиент не является целевой аудиторией маркера доступа OAuth. Вместо этого это авторизованный презентатор этого жетона , а аудитория фактически является защищенным ресурсом.Защищенный ресурс обычно не в состоянии определить, присутствует ли пользователь по-прежнему только по токену, поскольку по самой природе и конструкции протокола OAuth пользователь не будет доступен при соединении между клиентом и защищенным ресурс. Чтобы противостоять этому, должен быть артефакт, направленный на самого клиента. Это может быть сделано путем двойного назначения токена доступа, определения формата, который клиент может проанализировать и понять. Однако, поскольку общий OAuth не определяет конкретный формат или структуру для самого токена доступа, протоколы, такие как токен ID OpenID Connect и подписанный ответ Facebook Connect, предоставляют дополнительный токен вместе с токеном доступа, который передает информацию аутентификации непосредственно клиенту.Это позволяет основному токену доступа оставаться непрозрачным для клиента, как и в обычном OAuth.

Доступ к защищенному API как доказательство аутентификации

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

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

Внедрение токенов доступа

Дополнительная (и очень опасная) угроза возникает, когда клиенты принимают токены доступа из источников, отличных от обратного вызова от конечной точки токена. Это может произойти для клиента, который использует неявный поток (где токен передается непосредственно в качестве параметра в хэше URL-адреса) и неправильно использует параметр состояния OAuth . Эта проблема также может возникнуть, если разные части приложения передают маркер доступа между компонентами, чтобы «совместно использовать» доступ между ними.Это проблематично, потому что это открывает место для токенов доступа, которые потенциально могут быть введены в приложение внешней стороной (и потенциально могут просочиться за пределы приложения). Если клиентское приложение не проверяет токен доступа через какой-либо механизм, у него нет возможности отличить действительный токен от токена атаки.

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

Отсутствие ограничения аудитории

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

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

Внедрение неверной информации о пользователе

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

Различные протоколы для каждого потенциального поставщика удостоверений

Одна из самых больших проблем с API идентификации на основе OAuth заключается в том, что даже при использовании полностью совместимого со стандартами механизма OAuth разные поставщики неизбежно будут реализовывать детали фактического API идентификации по-разному. Например, идентификатор пользователя может быть найден в поле user_id у одного провайдера, но в поле subject у другого провайдера. Несмотря на то, что они семантически эквивалентны, для их обработки потребуются два отдельных пути кода.Другими словами, хотя авторизация может происходить одинаково у каждого провайдера, передача информации аутентификации может быть разной. Эта проблема может быть смягчена провайдерами, использующими стандартный протокол аутентификации , построенный на основе OAuth, так что независимо от того, откуда исходит идентификационная информация, она передается одинаково.

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

Стандарт для аутентификации пользователей с использованием OAuth: OpenID Connect

OpenID Connect - это открытый стандарт, опубликованный в начале 2014 года, который определяет способ взаимодействия с OAuth 2.0 для аутентификации пользователей. По сути, это широко опубликованный рецепт шоколадной помадки , который был опробован и протестирован большим количеством экспертов.Вместо того, чтобы создавать разные протоколы для каждого потенциального поставщика удостоверений, приложение может использовать один протокол для стольких поставщиков, с которыми они хотят работать. Поскольку это открытый стандарт, OpenID Connect может быть реализован кем угодно без ограничений или проблем интеллектуальной собственности.

OpenID Connect построен непосредственно на OAuth 2.0 и в большинстве случаев развертывается вместе с инфраструктурой OAuth (или поверх нее). OpenID Connect также использует набор спецификаций JSON Object Signing And Encryption (JOSE) для передачи подписанной и зашифрованной информации в разных местах.Фактически, развертывание OAuth 2.0 с возможностями JOSE - это уже долгий путь к определению полностью совместимой системы OpenID Connect, и разница между ними относительно мала. Но эта дельта имеет большое значение, и OpenID Connect удается избежать многих ошибок, описанных выше, путем добавления нескольких ключевых компонентов в базу OAuth:

ID жетонов

Токен идентификатора OpenID Connect - это подписанный веб-токен JSON (JWT), который предоставляется клиентскому приложению вместе с обычным токеном доступа OAuth.Идентификационный токен содержит набор утверждений о сеансе аутентификации, включая идентификатор пользователя ( sub ), идентификатор поставщика удостоверений, выпустившего токен ( iss, ), и идентификатор клиента, для которого это токен создан ( aud ). Кроме того, ID Token содержит информацию о действительном (и обычно коротком) времени жизни токена, а также любую информацию о контексте аутентификации, которая должна быть передана клиенту, например, как давно пользователю был представлен первичный механизм аутентификации.Поскольку формат идентификатора токена известен клиенту, он может анализировать содержимое токена напрямую и получать эту информацию, не полагаясь на внешнюю службу для этого. Кроме того, он выдается в дополнение (а не вместо) токена доступа, позволяя токену доступа оставаться непрозрачным для клиента, как это определено в обычном OAuth. Наконец, сам токен подписывается закрытым ключом поставщика удостоверений, добавляя дополнительный уровень защиты к утверждениям внутри него в дополнение к транспортной защите TLS, которая использовалась в первую очередь для получения токена, предотвращая класс олицетворения. атаки.Применяя несколько простых проверок к этому токену идентификатора, клиент может защитить себя от большого количества распространенных атак.

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

Конечная точка UserInfo

Следует отметить, что от клиентов не требуется использовать токен доступа, так как ID Token содержит всю необходимую информацию для обработки события аутентификации. Однако для обеспечения совместимости с OAuth и соответствия общей тенденции параллельной авторизации удостоверений и другого доступа к API OpenID Connect всегда выдает токен ID вместе с токеном доступа OAuth.

В дополнение к утверждениям в идентификаторе идентификатора OpenID Connect определяет стандартный защищенный ресурс, который содержит утверждения о текущем пользователе.Заявления здесь не являются частью процесса аутентификации, как обсуждалось выше, а вместо этого предоставляют объединенные атрибуты идентификации, которые делают протокол аутентификации более ценным для разработчиков приложений. В конце концов, лучше сказать «Доброе утро, Джейн Доу» вместо «Доброе утро, 9XE3-JI34-00132A». OpenID Connect определяет набор стандартизированных областей действия OAuth, которые сопоставляются с подмножествами этих атрибутов: профиль , электронная почта , телефон и адрес , что позволяет простым запросам авторизации OAuth нести необходимую информацию для запроса.OpenID Connect определяет специальную область openid , которая включает выдачу токена ID, а также доступ к конечной точке UserInfo с помощью токена доступа. Области OpenID Connect могут использоваться вместе с другими областями OAuth, отличными от OpenID-Connect, без конфликтов, а выданный токен доступа потенциально может быть нацелен на несколько различных защищенных ресурсов. Это позволяет системе идентификации OpenID Connect плавно сосуществовать с системой авторизации OAuth.

Динамическое обнаружение сервера и регистрация клиента

OAuth 2.0 был написан для обеспечения множества различных развертываний, но по замыслу не указывает, как эти развертывания должны быть настроены или как компоненты узнают друг о друге. Это нормально в обычном мире OAuth, где один сервер авторизации защищает определенный API, а два тесно связаны. С помощью OpenID Connect общий защищенный API развертывается для самых разных клиентов и поставщиков, каждый из которых должен знать друг о друге для работы. Было бы не масштабируемо для каждого клиента заранее знать каждого поставщика, и было бы еще менее масштабируемым требовать, чтобы каждый поставщик знал о каждом потенциальном клиенте.

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

Совместимость с OAuth 2.0

Даже при всей этой надежной возможности аутентификации OpenID Connect (по замыслу) по-прежнему совместим с обычным OAuth 2.0, что делает его очень хорошим выбором для развертывания поверх системы OAuth с минимальными усилиями разработчика. Фактически, если служба уже использует OAuth и спецификации JSON Object Signing and Encryption (JOSE) (включая JWT), эта служба уже находится на пути к поддержке OpenID Connect.

Чтобы облегчить создание хороших клиентских приложений, рабочая группа OpenID Connect опубликовала документы по созданию базового клиента OpenID Connect с использованием потока кода авторизации, а также по созданию неявного клиента OpenID Connect.Оба этих документа проводят разработчика через создание базового клиента OAuth 2.0 и добавление нескольких компонентов, необходимых для OpenID Connect.

Расширенные возможности

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

Дополнительная литература

• В статье OAuth 2.0 и входа в систему, Витторио Берточчи подробно описывает границы безопасности между сторонами и объясняет, почему уровень авторизации имеет смысл в качестве нижнего уровня, над которым нужно строить, и предоставляет источник украденной выше метафоры шоколад против помадки.
• Джастин Ричер представил подробный обзор задействованных здесь технологий и их взаимосвязи в Auth * In the Extended Enterprise в Массачусетском технологическом институте.
• Джон Брэдли написал серию статей по этой теме, в том числе:

Эта статья написана Джастином Ричером при участии сообщества OAuth. и находится под лицензией Creative Commons Attribution 4.0 Международная лицензия.

Советы по безопасной аутентификации пользователей - ENISA

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

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

Риски для паролей

Сегодня пароли можно украсть несколькими способами, в том числе:

1. Атаки социальной инженерии, такие как фишинговые учетные данные с использованием поддельных страниц, голосовой фишинг (так называемый Vishing), серфинг через плечо (например, подглядывание за человеком, который набирает его пароль на ноутбуке) и даже получение рукописных паролей из заметок.
2. Кража с использованием специализированного программного обеспечения или физических клавиатурных шпионов. Некоторые из этих атак требуют физического присутствия или близости к ноутбуку или устройству.
3. Путем перехвата сообщений, использования поддельных точек доступа или атак типа «злоумышленник посередине» (MiTM) на сетевом уровне, что более распространено в общедоступных сетях Wi-Fi в отелях, кафе, аэропортах и ​​т. Д.
4. Подбор паролей путем перебора всех комбинаций, словарных атак или простого угадывания пароля.
5. Получение паролей непосредственно от утечки данных и их использование с помощью методов распыления паролей для других законных служб.

Рекомендации по повышению безопасности паролей

1. По возможности активируйте функцию многофакторной аутентификации для всех ваших учетных записей.
2. Не используйте повторно свои пароли. Киберпреступники исходят из предположения, что многие пользователи повторно используют пароли, отсюда и их высокие показатели успешности взлома учетных записей.
3. Используйте функцию единого входа в сочетании с многофакторной аутентификацией, чтобы снизить риск взлома учетной записи.
4. Воспользуйтесь менеджером паролей.
5. Создавайте надежные и уникальные пароли или парольные фразы в соответствии с последними доступными рекомендациями для каждого отдельного веб-сайта и службы.Вот здесь и пригодятся менеджеры паролей.
6. Проверьте, не появляются ли какие-либо ваши учетные записи в существующих утечках данных, и действуйте немедленно, изменив свои пароли для указанных услуг.
7. Многие веб-сайты предлагают функции напоминания пароля. Убедитесь, что вы не полагаетесь на легко доступную личную информацию для сброса пароля, например имя вашего питомца, ваша дата рождения, ваша средняя школа и т. д.
8. Используйте VPN или, по крайней мере, мобильные точки доступа при доступе к электронному банкингу или другим частным услугам через общедоступную сеть Wi-Fi.
9. Будьте в курсе того, что вас окружает в залах ожидания, аэропортах, поездах и кафе, и убедитесь, что за вами никто не пытается перехватить ваш пароль. Вот здесь и пригодятся фильтры конфиденциальности экрана.
10. Не оставляйте свои устройства без присмотра / разблокированными в общественных местах, таких как отели, общественный транспорт, залы ожидания и т. Д.

Дополнительная информация:

Для получения дополнительных материалов по вопросам безопасности посетите веб-сайт мероприятия по повышению осведомленности о Европейском месяце кибербезопасности (ECSM), которое координируется ENISA.

Рекомендации

Cyber ​​Hygiene можно найти в Отчете ENISA - Cyber ​​Hygiene.

Для получения дополнительной информации, касающейся аспектов кибербезопасности пандемии COVID19, обратитесь к страницам ENISA, посвященным этой проблеме, в разделе «Тема - COVID19».

По вопросам прессы и интервью обращайтесь в press (at) enisa.europa.eu

Настроить методы аутентификации пользователей | Аутентификация и встроенные пользовательские межсетевые экраны Руководство пользователя

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

Когда пользователь пытается инициировать HTTP, HTTPS, запрос на соединение FTP или Telnet, для которого требуется политика, требующая аутентификации, устройство перехватывает запрос и запрашивает пользователь для ввода имени пользователя и пароля. В зависимости от конфигурации, устройство проверяет имя пользователя и пароль, сравнивая их с те, которые хранятся в локальной базе данных или при внешней аутентификации сервер.

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

• Аутентификация и авторизация RADIUS (совместима с Серверы Juniper Steel-Belted Radius)

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

• Только аутентификация LDAP (поддерживает LDAP версии 3, совместимый с Windows AD)

• Только аутентификация SecurID (используется внешний RSA SecurID). сервер аутентификации)

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

Примечание.

Для назначения IPv4-адреса используется семейный inet. Ты используешь семейство inet6 для назначения IPv6-адреса. Интерфейс можно настроить с адресами IPv4 и IPv6. Для краткости эти в примерах используются только адреса IPv4.

Рисунок 1: Поиск в политике для пользователя

Шаги на Рисунке 1 следующие:

1. Клиент-пользователь отправляет FTP, HTTP, HTTPS или Telnet пакет на 198.51.100.9.

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

3. Устройство запрашивает у пользователя данные для входа через FTP, HTTP, HTTPS или Telnet.

4. Пользователь отвечает, вводя имя пользователя и пароль.

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

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

7. Для трафика HTTP, HTTPS или Telnet устройство пересылает пакет из своего буфера на его IP-адрес назначения, 198.51.100.9/24. Однако для FTP-трафика после успешной аутентификации устройство закрывает сеанс, и пользователь должен повторно подключиться к FTP-серверу в IP-адрес 198.51.100.9 / 24.

Примечание:

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

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