Авторизация — различия между версиями
Gordeev (обсуждение | вклад) (Новая страница: « category:Архитектура UMI.CMS == Общее описание == В UMI.CMS встроен механизм разграничения полномо…») |
Mad grant (обсуждение | вклад) |
||
| (не показаны 2 промежуточные версии 1 участника) | |||
| Строка 1: | Строка 1: | ||
| − | + | ||
| + | [[Категория:Модуль Пользователи]] | ||
== Общее описание == | == Общее описание == | ||
| − | В UMI.CMS встроен механизм разграничения полномочий по использованию функционала системы на основании разрешений, даваемых | + | В UMI.CMS встроен механизм разграничения полномочий по использованию функционала системы на основании разрешений, даваемых пользователям и группам пользователей на доступ к определенным методам модулей и элементам иерархии . |
Процесс, в ходе которого система проверяет полномочия данного пользователя на выполнение определенного метода модуля или на доступ к определенному элементу иерархии, называется '''авторизацией'''. Авторизация осуществляется каждый раз при вызове метода или попытке получения элемента иерархии. В зависимости от результата авторизации пользователю может быть отказано в доступе к конкретным методам или элементам, или же при разрешении доступа к методу результат выборки элементов может различаться для различных пользователей. | Процесс, в ходе которого система проверяет полномочия данного пользователя на выполнение определенного метода модуля или на доступ к определенному элементу иерархии, называется '''авторизацией'''. Авторизация осуществляется каждый раз при вызове метода или попытке получения элемента иерархии. В зависимости от результата авторизации пользователю может быть отказано в доступе к конкретным методам или элементам, или же при разрешении доступа к методу результат выборки элементов может различаться для различных пользователей. | ||
| − | Чтобы произвести авторизацию, система соотносит | + | Чтобы произвести авторизацию, система соотносит разрешения , назначенные методу и элементу, с идентификатором пользователя, запрашивающего действие. Для этого она должна иметь представление о том, какой именно пользователь пытается получить доступ к функционалу, то есть обладать данными на текущего пользователя. Процесс, в ходе которого система определяет, какой именно пользователь, из зарегистрированных в системе, является текущим, называется '''аутентификацией'''. В отличие от авторизации, которая выполняется при каждом программном запросе к методам и элементам, аутентификация производится один раз по требованию пользователя и ее данные хранятся в сессии . |
| − | Аутентификация, в свою очередь, возможна при наличии некоторых данных, переданных пользователем, которые система соотносит с данными из списка зарегистрированных пользователей (чаще всего - логин и пароль). Процесс и правила | + | Аутентификация, в свою очередь, возможна при наличии некоторых данных, переданных пользователем, которые система соотносит с данными из списка зарегистрированных пользователей (чаще всего - логин и пароль). Процесс и правила передачи таких данных называется '''идентификацией'''. Как правило, идентификация инициирует аутентификацию, то есть пользователь согласно определенным правилам передает системе свои идентификационные данные, а система, получив их, считает, что на основании их требуется произвести (ре)аутентификацию. |
Таким образом, можно сказать, что каждый пользователь системы для получения доступа к ее функционалу должен произвести идентификацию, которая инициирует аутентификацию, результат которой используется в дальнейшем при авторизации. | Таким образом, можно сказать, что каждый пользователь системы для получения доступа к ее функционалу должен произвести идентификацию, которая инициирует аутентификацию, результат которой используется в дальнейшем при авторизации. | ||
| − | До тех пор, пока пользователь не идентифицирует себя явным образом, он аутентифицируется системой как | + | До тех пор, пока пользователь не идентифицирует себя явным образом, он аутентифицируется системой как Гость . |
| − | |||
== Идентификация == | == Идентификация == | ||
Пользователь может идентифицироваться в системе несколькими способами : | Пользователь может идентифицироваться в системе несколькими способами : | ||
| − | * передав логин и пароль | + | * передав логин и пароль учетной записи пользователя CMS в качестве параметров http-запроса 'login' и 'password' - в случае аутентификации методом /users/login_do |
| − | * передав логин и пароль | + | * передав логин и пароль учетной записи пользователя CMS в качестве параметров или заголовков http-запроса 'u-login' и 'u-password' (или 'u-password-md5') при запросе любой страницы - в случае "прозрачной преавторизации " |
| − | * (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля | + | * (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля учетной записи пользователя CMS логин и пароль учетной записи AD|MS ActiveDirectory (AD) - при условии, что модуль "Пользователи" сопряжен с AD, и что в CMS существует учетная запись, сопоставленная соответствующему аккаунту в AD |
| − | * (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля | + | * (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля учетной записи пользователя CMS идентификатор и пароль [[OpenId - при условии, что модуль "Пользователи" сопряжен с механизмом OpenId, и что в CMS существует учетная запись, сопоставленная соответствующему OpenId |
| − | * (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля | + | * (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля учетной записи пользователя CMS идентификатор и пароль аккаунта в форумах PhpBB или IPB - при условии, что модуль "Пользователи" сопряжен с одним из этих форумов, и что в CMS существует учетная запись, сопоставленная соответствующему аккаунту форума |
== Аутентификация == | == Аутентификация == | ||
| − | Если пользователь правильно передал системе идентификационные данные, UMI.CMS пытается произвести его аутентификацию. Прежде всего система проверяет наличие соответствующего внутреннего аккаунта, затем (если не удалось) - последовательно ищет аккаунты в | + | Если пользователь правильно передал системе идентификационные данные, UMI.CMS пытается произвести его аутентификацию. Прежде всего система проверяет наличие соответствующего внутреннего аккаунта, затем (если не удалось) - последовательно ищет аккаунты в AD , OpenId , PhpBB , IPB и пытается соотнести их со своими внутренними аккаунтами. |
| − | В любом случае, в результате аутентификации | + | В любом случае, в результате аутентификации CMS запоминает в сессии идентификатор одной из '''собственных''' учетных записей . Если системе не удается сопоставить запросу ни один из аккаунтов, в качестве текущей считается учетная запись "Гость" . Во всех последующих запросах клиента при работе от лица той же учетной записи идентификационные данные передавать не следует, посколько аутентификация будет производиться средствами механизма сессий , при необходимости же "сменить пользователя" клиент должен просто передать новые идентификационные данные. |
| − | Если | + | Если программа-клиент идентифицируется двумя способами одновременно - и посредством "прозрачной преавторизации ", и при помощи /users/login_do , - то система выполнит оба этих запроса именно в такой последовательности: сначала "преавторизацию ", затем /users/login_do . Таким образом, если будут переданы верные идентификационные данные двух существующих, но различных учетных записей, итоговая аутентификация будет осуществлена согласно данным, переданным в метод /users/login_do . |
== Авторизация == | == Авторизация == | ||
| − | Итак, любой доступ к функционалу системы всегда осуществляется от лица какой-то учетной записи пользователя (в частности, возможно, от Гостя). Функционал системы доступен пользователям посредством вызова определенных | + | Итак, любой доступ к функционалу системы всегда осуществляется от лица какой-то учетной записи пользователя (в частности, возможно, от Гостя). Функционал системы доступен пользователям посредством вызова определенных методов модулей (напрямую через url или в виде макросов , в том числе макросов страницы по-умолчанию ). Методы модулей могут, выполняя свои функции, обращаться к элементам иерархии. |
Авторизация в таком случае производится в два этапа: во-первых проверяется, есть ли у текущего пользователя доступ к данному методу, далее - при доступе к каждому элементу - есть ли у текущего пользователя права на данный элемент. | Авторизация в таком случае производится в два этапа: во-первых проверяется, есть ли у текущего пользователя доступ к данному методу, далее - при доступе к каждому элементу - есть ли у текущего пользователя права на данный элемент. | ||
Если текущий пользователь включен в несколько групп, которые имеют различные права доступа к элементам и методам, то итоговые права используют самые широкие из возможных полномочий. | Если текущий пользователь включен в несколько групп, которые имеют различные права доступа к элементам и методам, то итоговые права используют самые широкие из возможных полномочий. | ||
| − | Следует отметить, что при разработке методов программист может "обойти" авторизацию доступа к элементам (в API предусмотрены возможности доступа к данным, минуя авторизацию). Даже более того: при разработке методов программист должен явно | + | Следует отметить, что при разработке методов программист может "обойти" авторизацию доступа к элементам (в API предусмотрены возможности доступа к данным, минуя авторизацию). Даже более того: при разработке методов программист должен явно следить за использованием средств, обеспечивающих авторизацию доступа к данным . |
Так же, разработчик каждого конкретного метода может запрограммировать какую-то свою логику доступа к методу, элементам иерархии, объектам данных и т.п., которая будет дополнять системный механизм авторизации или даже заменять его (замена возможна в случае данных, в случае же метода, внутренняя логика ограничения доступа может лишь сузить, но не заменить системную авторизацию). | Так же, разработчик каждого конкретного метода может запрограммировать какую-то свою логику доступа к методу, элементам иерархии, объектам данных и т.п., которая будет дополнять системный механизм авторизации или даже заменять его (замена возможна в случае данных, в случае же метода, внутренняя логика ограничения доступа может лишь сузить, но не заменить системную авторизацию). | ||
Текущая версия на 21:42, 4 июня 2013
Общее описание
В UMI.CMS встроен механизм разграничения полномочий по использованию функционала системы на основании разрешений, даваемых пользователям и группам пользователей на доступ к определенным методам модулей и элементам иерархии .
Процесс, в ходе которого система проверяет полномочия данного пользователя на выполнение определенного метода модуля или на доступ к определенному элементу иерархии, называется авторизацией. Авторизация осуществляется каждый раз при вызове метода или попытке получения элемента иерархии. В зависимости от результата авторизации пользователю может быть отказано в доступе к конкретным методам или элементам, или же при разрешении доступа к методу результат выборки элементов может различаться для различных пользователей.
Чтобы произвести авторизацию, система соотносит разрешения , назначенные методу и элементу, с идентификатором пользователя, запрашивающего действие. Для этого она должна иметь представление о том, какой именно пользователь пытается получить доступ к функционалу, то есть обладать данными на текущего пользователя. Процесс, в ходе которого система определяет, какой именно пользователь, из зарегистрированных в системе, является текущим, называется аутентификацией. В отличие от авторизации, которая выполняется при каждом программном запросе к методам и элементам, аутентификация производится один раз по требованию пользователя и ее данные хранятся в сессии .
Аутентификация, в свою очередь, возможна при наличии некоторых данных, переданных пользователем, которые система соотносит с данными из списка зарегистрированных пользователей (чаще всего - логин и пароль). Процесс и правила передачи таких данных называется идентификацией. Как правило, идентификация инициирует аутентификацию, то есть пользователь согласно определенным правилам передает системе свои идентификационные данные, а система, получив их, считает, что на основании их требуется произвести (ре)аутентификацию.
Таким образом, можно сказать, что каждый пользователь системы для получения доступа к ее функционалу должен произвести идентификацию, которая инициирует аутентификацию, результат которой используется в дальнейшем при авторизации.
До тех пор, пока пользователь не идентифицирует себя явным образом, он аутентифицируется системой как Гость .
Идентификация
Пользователь может идентифицироваться в системе несколькими способами :
- передав логин и пароль учетной записи пользователя CMS в качестве параметров http-запроса 'login' и 'password' - в случае аутентификации методом /users/login_do
- передав логин и пароль учетной записи пользователя CMS в качестве параметров или заголовков http-запроса 'u-login' и 'u-password' (или 'u-password-md5') при запросе любой страницы - в случае "прозрачной преавторизации "
- (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля учетной записи пользователя CMS логин и пароль учетной записи AD|MS ActiveDirectory (AD) - при условии, что модуль "Пользователи" сопряжен с AD, и что в CMS существует учетная запись, сопоставленная соответствующему аккаунту в AD
- (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля учетной записи пользователя CMS идентификатор и пароль [[OpenId - при условии, что модуль "Пользователи" сопряжен с механизмом OpenId, и что в CMS существует учетная запись, сопоставленная соответствующему OpenId
- (опция в разработке) передав в одном из двух вышеобозначенных случаев вместо логина и пароля учетной записи пользователя CMS идентификатор и пароль аккаунта в форумах PhpBB или IPB - при условии, что модуль "Пользователи" сопряжен с одним из этих форумов, и что в CMS существует учетная запись, сопоставленная соответствующему аккаунту форума
Аутентификация
Если пользователь правильно передал системе идентификационные данные, UMI.CMS пытается произвести его аутентификацию. Прежде всего система проверяет наличие соответствующего внутреннего аккаунта, затем (если не удалось) - последовательно ищет аккаунты в AD , OpenId , PhpBB , IPB и пытается соотнести их со своими внутренними аккаунтами. В любом случае, в результате аутентификации CMS запоминает в сессии идентификатор одной из собственных учетных записей . Если системе не удается сопоставить запросу ни один из аккаунтов, в качестве текущей считается учетная запись "Гость" . Во всех последующих запросах клиента при работе от лица той же учетной записи идентификационные данные передавать не следует, посколько аутентификация будет производиться средствами механизма сессий , при необходимости же "сменить пользователя" клиент должен просто передать новые идентификационные данные.
Если программа-клиент идентифицируется двумя способами одновременно - и посредством "прозрачной преавторизации ", и при помощи /users/login_do , - то система выполнит оба этих запроса именно в такой последовательности: сначала "преавторизацию ", затем /users/login_do . Таким образом, если будут переданы верные идентификационные данные двух существующих, но различных учетных записей, итоговая аутентификация будет осуществлена согласно данным, переданным в метод /users/login_do .
Авторизация
Итак, любой доступ к функционалу системы всегда осуществляется от лица какой-то учетной записи пользователя (в частности, возможно, от Гостя). Функционал системы доступен пользователям посредством вызова определенных методов модулей (напрямую через url или в виде макросов , в том числе макросов страницы по-умолчанию ). Методы модулей могут, выполняя свои функции, обращаться к элементам иерархии. Авторизация в таком случае производится в два этапа: во-первых проверяется, есть ли у текущего пользователя доступ к данному методу, далее - при доступе к каждому элементу - есть ли у текущего пользователя права на данный элемент.
Если текущий пользователь включен в несколько групп, которые имеют различные права доступа к элементам и методам, то итоговые права используют самые широкие из возможных полномочий.
Следует отметить, что при разработке методов программист может "обойти" авторизацию доступа к элементам (в API предусмотрены возможности доступа к данным, минуя авторизацию). Даже более того: при разработке методов программист должен явно следить за использованием средств, обеспечивающих авторизацию доступа к данным . Так же, разработчик каждого конкретного метода может запрограммировать какую-то свою логику доступа к методу, элементам иерархии, объектам данных и т.п., которая будет дополнять системный механизм авторизации или даже заменять его (замена возможна в случае данных, в случае же метода, внутренняя логика ограничения доступа может лишь сузить, но не заменить системную авторизацию).
