Авторизация - История изменений

Mad grant в 21:42, 4 июня 2013

2013-06-04T21:42:54Z

Gordeev в 08:47, 5 марта 2011

2011-03-05T08:47:51Z

Внесённые изменения

Gordeev: /* Общее описание */

2011-02-24T20:41:28Z

‎Общее описание

Gordeev: Новая страница: « category:Архитектура UMI.CMS == Общее описание == В UMI.CMS встроен механизм разграничения полномо…»

2011-02-24T20:38:14Z

Новая страница: « category:Архитектура UMI.CMS == Общее описание == В UMI.CMS встроен механизм разграничения полномо…»

Новая страница

[[category:Архитектура UMI.CMS]]
== Общее описание ==

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

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

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

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

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

До тех пор, пока пользователь не идентифицирует себя явным образом, он аутентифицируется системой как [[гость|Гость]].

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

Пользователь может идентифицироваться в системе несколькими способами :
* передав логин и пароль [[учетная запись|учетной записи пользователя CMS]] в качестве параметров http-запроса 'login' и 'password' - в случае аутентификации методом [[users::login_do|/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|/users/login_do]]. Таким образом, если будут переданы верные идентификационные данные двух существующих, но различных учетных записей, итоговая аутентификация будет осуществлена согласно данным, переданным в метод [[users::login_do|/users/login_do]].

== Авторизация ==

Итак, любой доступ к функционалу системы всегда осуществляется от лица какой-то учетной записи пользователя (в частности, возможно, от Гостя). Функционал системы доступен пользователям посредством вызова определенных [[метод|методов модулей]] (напрямую через url или в виде [[макрос|макросов]], в том числе [[дефолтный макрос|макросов страницы по-умолчанию]]). Методы модулей могут, выполняя свои функции, обращаться к элементам иерархии.
Авторизация в таком случае производится в два этапа: во-первых проверяется, есть ли у текущего пользователя доступ к данному методу, далее - при доступе к каждому элементу - есть ли у текущего пользователя права на данный элемент.

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

Следует отметить, что при разработке методов программист может "обойти" авторизацию доступа к элементам (в API предусмотрены возможности доступа к данным, минуя авторизацию). Даже более того: при разработке методов программист должен явно [[контроль доступа к данным|следить за использованием средств, обеспечивающих авторизацию доступа к данным]].
Так же, разработчик каждого конкретного метода может запрограммировать какую-то свою логику доступа к методу, элементам иерархии, объектам данных и т.п., которая будет дополнять системный механизм авторизации или даже заменять его (замена возможна в случае данных, в случае же метода, внутренняя логика ограничения доступа может лишь сузить, но не заменить системную авторизацию).

← Предыдущая		Версия 21:42, 4 июня 2013
Строка 1:		Строка 1:
−	[[~~category~~:~~Архитектура UMI.CMS~~]]	+
		+	[[Категория:Модуль Пользователи]]
	== Общее описание ==		== Общее описание ==

← Предыдущая		Версия 20:41, 24 февраля 2011
Строка 13:		Строка 13:

	До тех пор, пока пользователь не идентифицирует себя явным образом, он аутентифицируется системой как [[гость\|Гость]].		До тех пор, пока пользователь не идентифицирует себя явным образом, он аутентифицируется системой как [[гость\|Гость]].
		+	== Идентификация ==
		+
		+	Пользователь может идентифицироваться в системе несколькими способами :
		+	* передав логин и пароль [[учетная запись\|учетной записи пользователя CMS]] в качестве параметров http-запроса 'login' и 'password' - в случае аутентификации методом [[users::login_do\|/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\|/users/login_do]]. Таким образом, если будут переданы верные идентификационные данные двух существующих, но различных учетных записей, итоговая аутентификация будет осуществлена согласно данным, переданным в метод [[users::login_do\|/users/login_do]].
		+
		+	== Авторизация ==
		+
		+	Итак, любой доступ к функционалу системы всегда осуществляется от лица какой-то учетной записи пользователя (в частности, возможно, от Гостя). Функционал системы доступен пользователям посредством вызова определенных [[метод\|методов модулей]] (напрямую через url или в виде [[макрос\|макросов]], в том числе [[дефолтный макрос\|макросов страницы по-умолчанию]]). Методы модулей могут, выполняя свои функции, обращаться к элементам иерархии.
		+	Авторизация в таком случае производится в два этапа: во-первых проверяется, есть ли у текущего пользователя доступ к данному методу, далее - при доступе к каждому элементу - есть ли у текущего пользователя права на данный элемент.
		+
		+	Если текущий пользователь включен в несколько групп, которые имеют различные права доступа к элементам и методам, то итоговые права используют самые широкие из возможных полномочий.
		+
		+	Следует отметить, что при разработке методов программист может "обойти" авторизацию доступа к элементам (в API предусмотрены возможности доступа к данным, минуя авторизацию). Даже более того: при разработке методов программист должен явно [[контроль доступа к данным\|следить за использованием средств, обеспечивающих авторизацию доступа к данным]].
		+	Так же, разработчик каждого конкретного метода может запрограммировать какую-то свою логику доступа к методу, элементам иерархии, объектам данных и т.п., которая будет дополнять системный механизм авторизации или даже заменять его (замена возможна в случае данных, в случае же метода, внутренняя логика ограничения доступа может лишь сузить, но не заменить системную авторизацию).

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