Отличие аутентификации от авторизации: Аутентификация, авторизация и идентификация

Содержание

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

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

Определения

Что же значат все эти термины, и чем соответствующие процессы отличаются друг от друга?

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

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

Авторизация – предоставление определенному лицу прав на выполнение определенных действий.

Примеры

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

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

После этого Google просит ввести пароль, пользователь его вводит, и система соглашается, что пользователь действительно настоящий, ведь пароль совпал, — это аутентификация.

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

После этого система предоставит пользователю право читать письма в его почтовом ящике и все остальное — это авторизация.

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

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

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

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

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

Что еще важно знать

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

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

Если испытываете трудности с их запоминанием — вам всегда придет на помощь менеджер паролей. Он же поможет их сгенерировать.

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

По материалам сайтов kaspersky.ru, support.google.com

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

Опубликовано Olga Geo Ноя 17, 2015 |

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

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

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

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

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

В виртуальном мире все практически так же, как в реальном. Только имена “персонажей” меняются. Сотрудник охраны — это сервер, контролирующий вход на сайт. А пришедший на работу менеджер — пользователь, который хочет попасть в свой аккаунт.

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

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

Чтобы выполнить какие-либо действия на сайте, клиент должен “представиться” системе. Идентификация пользователя — предъявление им оснований для входа на сайт или сервис. Обычно в роли идентификаторов выступают логин или адрес электронной почты, указанный при регистрации. Если сервер находит в своей базе данные, совпадающие с указанными, то происходит идентификация клиента.

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

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

одноразовый пароль или PIN-код;
магнитные карты, смарт-карты, сертификаты с цифровой подписью;
биометрические параметры: голос, сетчатка глаза, отпечатки пальцев.

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

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

Two factor authentication может быть как односторонней — когда только пользователь доказывает системе свою истинность, так и двусторонней — сервер и клиент взаимно подтверждают свою подлинность по системе “запрос-ответ”. Такой тип 2FA используется в токене Protectimus Ultra и позволяет, среди прочего, устранить риск попадания на фишинговые сайты.

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

Между терминами “авторизация” и “аутентификация” разница довольно значительна. Часто можно услышать или прочитать в интернете выражение “двухфакторная авторизация”, но оно, строго говоря, не является корректным. Ведь авторизация пользователя — это предоставление ему полномочий в какой-либо системе, окончательный ответ на вопрос: “Можно ли допустить этого человека к той или иной информации или функциям?”. И в силу своей однозначности авторизация никак не может быть двухфакторной.

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

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

Summary

Article Name

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

Description

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

Author

Olga Geo

Publisher Name

Protectimus.com

Publisher Logo

You have Successfully Subscribed!

Разница между аутентификацией и авторизацией — Технология

Содержание:

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

Сравнительная таблица
Определение
Ключевые отличия
Вывод

Сравнительная таблица


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

Определение аутентификации

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

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

Пример :

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

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

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

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

Пример :

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

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

Вывод

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

Есть ли разница между аутентификацией и авторизацией?

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

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

security

Поделиться

Источник

paxdiablo

16 июня 2011 в 06:20

17 ответов

141

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

Кто является пользователем?
Действительно ли пользователь является тем, кем он себя представляет?

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

Имеет ли пользователь X право доступа к ресурсу R?
Имеет ли пользователь X право выполнять операцию P?
Имеет ли пользователь X право выполнять операцию P на ресурсе R?

Стив Райли написал довольно хорошее эссе о том, почему они должны оставаться различными.

Поделиться

Michael Foukarakis

16 июня 2011 в 06:27

Аутентификация относится к проверке идентичности объекта. Авторизация относится к тому, что аутентифицированному объекту разрешено делать (например, права доступа к файлам).

Поделиться

jpm

16 июня 2011 в 06:23

Самое главное-это:

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

Поделиться

Moch Yusup

30 сентября 2014 в 03:08

Идентификация:

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

Разрешение:

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

Поделиться

Humoyun Ahmad

10 ноября 2016 в 12:17

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

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

Поделиться

nageeb

16 июня 2011 в 06:23

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

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

Поделиться

Aziz Shaikh

16 июня 2011 в 06:29

Если я могу войти в систему, мои учетные данные проверяются, и я AUTHENTICATED. Если я могу выполнить какую-то конкретную задачу, то я должен это сделать.

Поделиться

Puneet Pandey

09 июня 2015 в 06:03

Аутентификация проверяет, кто вы есть, а авторизация-что вы имеете право делать. Например, вам разрешен вход на ваш сервер Unix через клиент ssh, но вы не авторизованы на браузер /data2 или любую другую файловую систему. Авторизация происходит после успешной аутентификации……..

Поделиться

Bmw

26 марта 2016 в 21:21

Поделиться

vinit payal

25 апреля 2014 в 21:05

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

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

Авторизация: определение того, что пользователь может делать.

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

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

Поделиться

Smrity

03 декабря 2015 в 05:10

Идентификация

Аутентификация проверяет, кто вы есть. Например, вы можете войти на свой сервер с помощью клиента ssh или получить доступ к серверу email с помощью клиента POP3 и SMTP.

Разрешение

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

Поделиться

Bilali Hamisi

03 декабря 2015 в 05:24

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

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

Поделиться

Shankar Ghimire

02 декабря 2016 в 03:20

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

Поделиться

sambhu

15 сентября 2017 в 21:20

Я попытался создать образ, чтобы объяснить это самыми простыми словами

1) средства аутентификации «Are you who you say you are?»

2) авторизация означает «должны ли вы быть в состоянии сделать то, что вы пытаетесь сделать?».

Это также описано на рисунке ниже.

Поделиться

Rohit Ailani

19 апреля 2018 в 10:57

Идентификация :

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

Тип проверки подлинности:

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

OpenID -это открытый стандарт аутентификации.

Разрешение

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

OAuth -это открытый стандарт авторизации.

Поделиться

Steffi Keran Rani J

29 ноября 2018 в 11:39

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

Авторизация заключается в проверке того, может ли пользователь получить доступ к приложению или нет, или к чему пользователь может получить доступ, а к чему нет.
Источник: Authentcation Vs Authorization

Поделиться

rahulnikhare

22 июня 2020 в 07:06

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

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

Говоря об аутентификации (также называемой AuthN), подумайте об идентичности. Аутентификация пытается ответить “is this person who they say they are?” это программный эквивалент паспорта или национального чека ID. Или, говоря более реалистично, аутентификация-это тот же процесс, что и в тот момент, когда вы смотрите на лицо другого человека, чтобы узнать, что это ваш друг из колледжа, а не ваш раздражающий сосед по второму этажу.

С другой стороны, авторизация (также называемая AuthZ) — это все о разрешениях. Авторизация отвечает на вопрос “what is this person allowed to do in this space?” вы можете думать об этом как о своем домашнем ключе или служебном значке. Ты можешь открыть входную дверь? Может ли ваш раздражающий сосед войти в вашу квартиру по своему желанию? И еще, оказавшись в вашей квартире, кто может воспользоваться туалетом? Кто может есть из вашего тайного запаса печенья, спрятанного в кухонном шкафу?

Поделиться

Warren Parad

25 июня 2020 в 14:28

Авторизация доступа | Компьютерные сети

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

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

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

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

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

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

Централизованная схема, базирующаяся на сервере. В этой схеме сервер управляет процессом предоставления ресурсов сети пользователю. Главная цель таких систем — реализовать «принцип единого входа». В соответствии с централизованной схемой пользователь один раз логически входит в сеть и получает на все время работы некоторый набор разрешений по доступу к различным ресурсам сети. Система Kerberos с ее сервером безопасности и архитектурой клиент-сервер, а также более современная система Shibboleth, построенная в той же архитектуре, являются наиболее известными системами этого типа. Системы TACACS и RADIUS, часто применяемые совместно с системами удаленного доступа, также реализуют этот подход.
Децентрализованная схема, базирующаяся на рабочих станциях. При этом подходе средства авторизации работают на каждой машине. Администратор должен отслеживать работу механизмов безопасности каждого отдельного приложения — электронной почты, справочной службы, локальных баз данных и т. п.

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

Руководство Django Часть 8: Аутентификация и авторизация пользователя — Изучение веб-разработки

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

Требования:	Завершить изучение предыдущих тем руководства, включая Руководство Django Часть 7: Работа с сессиями.
Цель:	Понимать как настроить и использовать механизм аутентификации пользователя и разграничений прав доступа.

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

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

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

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

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

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

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

Соответствующие настройки сделаны в параметрах INSTALLED_APPS и MIDDLEWARE файла проекта (locallibrary/locallibrary/settings.py), как показано ниже:

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

MIDDLEWARE = [
    ...
    'django.contrib.sessions.middleware.SessionMiddleware',  
    ...
    'django.contrib.auth.middleware.AuthenticationMiddleware',  
    ....

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

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

from django.contrib.auth.models import User


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


user.first_name = 'John'
user.last_name = 'Citizen'
user.save()

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

Запустите сервер разработки и перейдите к административной панели вашего сайта (http://127.0.0.1:8000/admin/). Залогиньтесь на сайте при помощи параметров (имя пользователя и пароля) аккаунта суперпользователя. Самая «верхняя» страница панели Администратора показывает все наши модели. Для того, чтобы увидеть записи в разделе Authentication and Authorisation вы можете нажать на ссылку Users, или Groups.

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

Нажмите на кнопку Add (Добавить) (рядом с Group) и создайте новую группу; для данной группы введите Name (Имя) «Library Members».
Для данной группы не нужны какие-либо разрешения, поэтому мы просто нажимаем кнопку SAVE (Сохранить) (вы перейдете к списку групп).

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

Перейдите обратно на домашнюю страницу административной панели
Для перехода к диалогу добавления пользователя нажмите на кнопку Add, соответствующую строке Users (Пользователи).
Введите соответствующие Username (имя пользователя) и Password/Password confirmation (пароль/подтверждение пароля) для вашего тестового пользователя
Нажмите SAVE для завершения процесса создания пользователя.
Административная часть сайта создаст нового пользователя и немедленно перенаправит вас на страницу Change user (Изменение параметров пользователя) где вы можете, соответственно, изменить ваш username, а кроме того добавить информацию для дополнительных полей модели User. Эти поля включают в себя имя пользователя, фамилию, адрес электронной почты, статус пользователя, а также соответствующие параметры доступа (может быть установлен только флаг Active). Ниже вы можете определить группу для пользователя и необходимые параметры доступа, а кроме того, вы можете увидеть важные даты, относящиеся к пользователю (дату подключения к сайту и дату последнего входа).
В разделе Groups, из списка Доступные группы выберите группу Library Member, а затем переместите ее в блок «Выбранные группы» (нажмите стрелку-«направо», находящуюся между блоками).
Больше нам не нужно здесь нечего делать, просто нажмите «Save»(Сохранить), и вы вернетесь к списку созданых пользователей.

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

Note: Попробуйте создать другого пользователя, например «Библиотекаря». Так же создайте группу «Библиотекарей» и добавьте туда своего только что созданного библиотекаря

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

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

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

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

Проектирование URLs

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


urlpatterns += [
    path('accounts/', include('django.contrib.auth.urls')),
]

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

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

accounts/ login/ [name='login']
accounts/ logout/ [name='logout']
accounts/ password_change/ [name='password_change']
accounts/ password_change/done/ [name='password_change_done']
accounts/ password_reset/ [name='password_reset']
accounts/ password_reset/done/ [name='password_reset_done']
accounts/ reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/ reset/done/ [name='password_reset_complete']

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

Exception Type:    TemplateDoesNotExist
Exception Value:    registration/login.html

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

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

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

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

Примечание: Ваша структура папок теперь должна выглядеть как показано внизу:
locallibrary (django project folder)
|_catalog
|_locallibrary
|_templates (new)
|_registration

Чтобы сделать эти директории видимыми для загрузчика шаблонов (т. е. помещать этот каталог в путь поиска шаблона) откройте настройки проекта (/locallibrary/locallibrary/settings.py), и обновите в секции TEMPLATES строку 'DIRS' как показано.

TEMPLATES = [
    {
        ...
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        ...

Шаблон аутентификации

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

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

{% extends "base_generic.html" %}

{% block content %}

{% if form.errors %}
  <p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
  {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
  {% else %}
    <p>Please login to see this page.</p>
  {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>

<tr>
  <td>{{ form.username.label_tag }}</td>
  <td>{{ form.username }}</td>
</tr>

<tr>
  <td>{{ form.password.label_tag }}</td>
  <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login" />
<input type="hidden" name="next" value="{{ next }}" />
</form>

{# Assumes you setup the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

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

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

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

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


LOGIN_REDIRECT_URL = '/'

Шаблон выхода

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

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

{% extends "base_generic.html" %}

{% block content %}
<p>Logged out!</p>

<a href="{% url 'login'%}">Click here to login again.</a>
{% endblock %}

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

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

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

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

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

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

{% extends "base_generic.html" %}
{% block content %}

<form action="" method="post">{% csrf_token %}
    {% if form.email.errors %} {{ form.email.errors }} {% endif %}
        <p>{{ form.email }}</p>
    <input type="submit" value="Reset password" />
</form>

{% endblock %}

Сброс пароля

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

{% extends "base_generic.html" %}
{% block content %}
<p>We've emailed you instructions for setting your password. If they haven't arrived in a few minutes, check your spam folder.</p>
{% endblock %}

Сброс пароля по email

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

Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

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

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

{% extends "base_generic.html" %}

{% block content %}

    {% if validlink %}
        <p>Please enter (and confirm) your new password.</p>
        <form action="" method="post">
            {% csrf_token %}
            <table>
                <tr>
                    <td>{{ form.new_password1.errors }}
                        <label for="id_new_password1">New password:</label></td>
                    <td>{{ form.new_password1 }}</td>
                </tr>
                <tr>
                    <td>{{ form.new_password2.errors }}
                        <label for="id_new_password2">Confirm password:</label></td>
                    <td>{{ form.new_password2 }}</td>
                </tr>
                <tr>
                    <td></td>
                    <td><input type="submit" value="Change my password" /></td>
                </tr>
            </table>
        </form>
    {% else %}
        <h2>Password reset failed</h2>
        <p>The password reset link was invalid, possibly because it has already been used.  Please request a new password reset.</p>
    {% endif %}

{% endblock %}

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

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

{% extends "base_generic.html" %}
{% block content %}

<h2>The password has been changed!</h2>
<p><a href="{% url 'login' %}">log in again?</a></p>

{% endblock %}

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

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

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

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

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

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

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

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

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

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

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

  <ul>

    ...

   {% if user.is_authenticated %}
     <li>User: {{ user.get_username }}</li>
     <li><a href="{% url 'logout'%}?next={{request.path}}">Logout</a></li>
   {% else %}
     <li><a href="{% url 'login'%}?next={{request.path}}">Login</a></li>
   {% endif %} 
  </ul>

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

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

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

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

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

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

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

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

from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    ...

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

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

Для получения дополнительной информации ознакомьтесь с Django docs here.

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

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

Модели

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

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

from django.contrib.auth.models import User

Затем добавьте поле borrower в модель BookInstance:

borrower = models.ForeignKey(User, on_delete=models.SET_NULL, null=True, blank=True)

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

from datetime import date

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

@property
def is_overdue(self):
    if self. due_back and date.today() > self.due_back:
        return True
    return False

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

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

python3 manage.py makemigrations
python3 manage.py migrate

Admin

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

@admin.register(BookInstance)
class BookInstanceAdmin(admin.ModelAdmin):
    list_display = ('book', 'status', 'borrower', 'due_back', 'id')
    list_filter = ('status', 'due_back')

    fieldsets = (
        (None, {
            'fields': ('book','imprint', 'id')
        }),
        ('Availability', {
            'fields': ('status', 'due_back','borrower')
        }),
    )

Займите несколько книг

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

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

Займ в представлении

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

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

from django.contrib.auth.mixins import LoginRequiredMixin

class LoanedBooksByUserListView(LoginRequiredMixin,generic.ListView):
    """
    Generic class-based view listing books on loan to current user.
    """
    model = BookInstance
    template_name ='catalog/bookinstance_list_borrowed_user.html'
    paginate_by = 10

    def get_queryset(self):
        return BookInstance.objects.filter(borrower=self.request.user).filter(status__exact='o').order_by('due_back')

Чтобы ограничить наш запрос только объектами BookInstance для текущего пользователя, мы повторно реализуем get_queryset(), как показано выше. mybooks/$’, views.LoanedBooksByUserListView.as_view(), name=’my-borrowed’),
]

Шаблон для заёмных книг

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

{% extends "base_generic.html" %}

{% block content %}
    <h2>Borrowed books</h2>

    {% if bookinstance_list %}
    <ul>

      {% for bookinst in bookinstance_list %}
      <li>
        <a href="{% url 'book-detail' bookinst.book.pk %}">{{bookinst.book.title}}</a> ({{ bookinst.due_back }})
      </li>
      {% endfor %}
    </ul>

    {% else %}
      <p>There are no books borrowed.</p>
    {% endif %}
{% endblock %}

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

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

Добавить список на боковую панель

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

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

 <ul>
   {% if user.is_authenticated %}
   <li>User: {{ user.get_username }}</li>
   <li><a href="{% url 'my-borrowed' %}">My Borrowed</a></li>
   <li><a href="{% url 'logout'%}?next={{request. path}}">Logout</a></li>
   {% else %}
   <li><a href="{% url 'login'%}?next={{request.path}}">Login</a></li>
   {% endif %}
 </ul>

На что это похоже?

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

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

Модели

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

class BookInstance(models.Model):
    ...
    class Meta:
        ...
        permissions = (("can_mark_returned", "Set book as returned"),)

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

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

Шаблоны

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

{% if perms.catalog.can_mark_returned %}
    <!-- We can mark a BookInstance as returned. -->
    <!-- Perhaps add code to link to a "book return" view here. -->
{% endif %}

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

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

Функция в представлении с декоратором:

from django.contrib.auth.decorators import permission_required

@permission_required('catalog.can_mark_returned')
@permission_required('catalog.can_edit')
def my_view(request):
    ...

Требуется разрешение mixin для представлений на основе классов.

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'catalog.can_mark_returned'
    
    permission_required = ('catalog.can_mark_returned', 'catalog.can_edit')

Пример

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

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

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

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

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

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

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

2.1.27 Аутентификация, авторизация, аудит | Копилка знаний

Авторизация доступа

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

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

избирательный доступ;
мандатный доступ.

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

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

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

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

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

централизованная схема авторизации, базирующаяся на сервере;
децентрализованная схема, базирующаяся на рабочих станциях.

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

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

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

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

Аудит

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

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

Поскольку никакая система безопасности не гарантирует защиту на уровне 100 %, то последним рубежом в борьбе с нарушениями оказывается система аудита.

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

Аутентификация и авторизация | Okta

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

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

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

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

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

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

	Аутентификация	Авторизация
Для чего он нужен?	Проверяет учетные данные	Предоставляет или отклоняет разрешения
Как это работает?	Через пароли, биометрические данные, одноразовые пины или приложения	Через настройки, поддерживаемые службами безопасности
Это видно пользователю?	Есть	№
Может изменяться пользователем?	Частично	№
Как перемещаются данные?	Через жетоны идентификатора	Через токены доступа

Системы

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

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

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

Предоставление разрешений с Okta

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

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

Возможности оптимизации IAM в вашей организации безграничны. Узнайте, как Okta может защитить вас, ваших сотрудников и ваше предприятие.

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

Auth0 использует протокол OpenID Connect (OIDC) и структуру авторизации OAuth 2.0 для аутентификации пользователей и получения их авторизации для доступа к защищенным ресурсам. С Auth0 вы можете легко поддерживать различные потоки в ваших собственных приложениях и API, не беспокоясь о OIDC / OAuth 2.0 или другие технические аспекты аутентификации и авторизации.

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

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

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

Вот краткий обзор различий между аутентификацией и авторизацией:

Аутентификация	Авторизация
Определяет, являются ли пользователи тем, кем они себя называют	Определяет, какие пользователи могут и не могут получить доступ.
Предлагает пользователю проверить учетные данные (например, с помощью паролей, ответов на вопросы безопасности или распознавания лиц)	Проверяет, разрешен ли доступ с помощью политик и правил
Обычно выполняется до авторизации	Обычно выполняется после успешной аутентификации
Как правило, передает информацию через идентификационный токен	Обычно передает информацию через токен доступа
Обычно регулируется протоколом OpenID Connect (OIDC)	Обычно регулируется OAuth 2. 0 рамки
Пример: сотрудники компании должны пройти аутентификацию через сеть, прежде чем получить доступ к электронной почте своей компании	Пример: после успешной аутентификации сотрудника система определяет, к какой информации сотрудникам разрешен доступ

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

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

Если вы не уверены, какой поток использовать, мы можем помочь вам решить. Краткое руководство см. В разделе «Какой поток OAuth 2.0 следует использовать?».

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

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

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

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

При использовании межмашинных приложений (M2M), таких как интерфейсы командной строки, демоны или службы, запущенные на вашем сервере, система аутентифицирует и авторизует приложение, а не пользователя. Для этого сценария типичные схемы аутентификации, такие как имя пользователя + пароль или вход в социальные сети, не имеют смысла. Вместо этого приложения M2M используют поток учетных данных клиента (определенный в OAuth 2.0 RFC 6749, раздел 4.4).

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

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

Разница между аутентификацией и авторизацией

Разница между аутентификацией и авторизацией

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

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

Давайте посмотрим на разницу между аутентификацией и авторизацией:

С.НЕТ	Аутентификация	Авторизация
1.	В процессе аутентификации личность пользователей проверяется для предоставления доступа к системе.	В процессе авторизации проверяются права доступа человека или пользователя к ресурсам.
2.	В процессе аутентификации проверяются пользователи или лица.	В ходе этого процесса проверяются пользователи или лица.
3.	Это делается до авторизации.	Пока этот процесс выполняется после процесса аутентификации.
4.	Обычно требуются данные для входа в систему.	Хотя для этого нужны права пользователя или уровни безопасности.
5.	Аутентификация определяет, является ли человек пользователем или нет.	Пока определяет Какое разрешение у пользователя?

Вниманию читателя! Не прекращайте учиться сейчас.Получите все важные концепции теории CS для собеседований SDE с помощью курса CS Theory Course по приемлемой для студентов цене и будьте готовы к работе в отрасли.

Аутентификация против авторизации. Сегодня я собираюсь обсудить две темы… | пользователя Anum Siddiqui | Data Driven Investor

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

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

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

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

Однофакторная аутентификация: Это простейшая форма метода аутентификации, который требует пароля для предоставления пользователю доступа к определенной системе, такой как веб-сайт. или сеть.Человек может запросить доступ к системе, используя только одну из учетных данных для подтверждения своей личности. Например, запрос пароля только для имени пользователя может быть способом проверки учетных данных для входа с использованием однофакторной аутентификации.
Двухфакторная аутентификация: Эта аутентификация требует двухэтапного процесса проверки, который требует не только имени пользователя и пароля, но также части информации, известной только пользователю. Использование имени пользователя и пароля вместе с конфиденциальной информацией значительно усложняет хакерам кражу ценных и личных данных.
Многофакторная аутентификация: Это наиболее продвинутый метод аутентификации, который требует двух или более уровней безопасности из независимых категорий аутентификации для предоставления пользователю доступа к системе. В этой форме аутентификации используются независимые друг от друга факторы, чтобы исключить возможность раскрытия данных. Финансовые организации, банки и правоохранительные органы часто используют многофакторную аутентификацию.

Авторизация

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

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

В чем разница между аутентификацией и авторизацией?

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

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

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

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

Факторные методологии основаны на комбинации переменных вокруг защищенной строки или ключа. Эти переменные делятся на три категории:

Физические : что-то, что есть у пользователя
Биометрические : что-то, что пользователь
Секрет : что-то, что знает пользователь

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

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

Реализация аутентификации требует, чтобы один элемент из двух или более категорий считался Многофакторным . Итак, технически говоря, Two-Factor — это многофакторное решение. Однако, когда у вас есть что-то из всех трех типов, вы вводите класс Multi-Factor, который не является синонимом Two-Factor. Например, предположим, что наша схема аутентификации также требует USB-ключа безопасности или «чего-то, что есть у пользователя». Если бы та же самая система потребовала пароля и идентификации по отпечатку пальца, она стала бы многофакторной аутентификацией, помимо двухфакторной.

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

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

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

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

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

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

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

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

OAuth Confusion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое аутентификация и авторизация | BeyondTrust

Определение аутентификации

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

Аутентификация вашей личности = логин + общий секрет (пароль)

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

Вот пример однофакторной аутентификации.Если бы меня звали Джон Титор, мой логин мог бы быть «jtitor» или [email protected], поскольку имя моей учетной записи является сокращением моего фактического имени. Однако логин также может быть чем-то более сложным, например, номером сотрудника, который лучше скрывает личность пользователя и не обязательно угадывается без какой-либо формы информации для сопоставления личности с именем пользователя учетной записи. Для высокозащищенных сред этот второй подход предпочтительнее, особенно для учетных записей администратора или root. По сути, вы не можете визуально определить привилегии или роль учетной записи, просто взглянув на учетную запись или имя пользователя.Это по сравнению с названием учетной записи вроде «x-admin». Незаметность — это не безопасность, но она часто помогает и, при определении authN, может повысить безопасность системы однофакторной аутентификации, не используя угадываемое имя пользователя.

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

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

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

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

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

Авторизация

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

Шифрование

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

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

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

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

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

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

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Отличие аутентификации от авторизации: Аутентификация, авторизация и идентификация — DiPHOST.Ru wiki system

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

Определения

Примеры

Что еще важно знать

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

You have Successfully Subscribed!

Разница между аутентификацией и авторизацией — Технология

Содержание:

Сравнительная таблица

Определение аутентификации

Пример :

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

Пример :

Вывод

Есть ли разница между аутентификацией и авторизацией?

17 ответов

Похожие вопросы:

Авторизация доступа | Компьютерные сети

Руководство Django Часть 8: Аутентификация и авторизация пользователя — Изучение веб-разработки

Проектирование URLs

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

Шаблон аутентификации

Шаблон выхода

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

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

Сброс пароля

Сброс пароля по email

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

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

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

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

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

Модели

Admin

Займите несколько книг

Займ в представлении

Шаблон для заёмных книг

Добавить список на боковую панель

На что это похоже?

Модели

Шаблоны

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

Пример

2.1.27 Аутентификация, авторизация, аудит | Копилка знаний

Аутентификация и авторизация | Okta

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

Разница между аутентификацией и авторизацией

Аутентификация против авторизации. Сегодня я собираюсь обсудить две темы… | пользователя Anum Siddiqui | Data Driven Investor

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

Авторизация

В чем разница между аутентификацией и авторизацией?

OAuth Confusion

Что такое аутентификация и авторизация | BeyondTrust

Определение аутентификации

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

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

Авторизация

Шифрование

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

Добавить комментарий Отменить ответ