19. Методы авторизации

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

В 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 предусмотрены возможности доступа к данным, минуя авторизацию). Даже более того: при разработке методов программист должен явно следить за использованием средств, обеспечивающих авторизацию доступа к данным . Так же, разработчик каждого конкретного метода может запрограммировать какую-то свою логику доступа к методу, элементам иерархии, объектам данных и т.п., которая будет дополнять системный механизм авторизации или даже заменять его (замена возможна в случае данных, в случае же метода, внутренняя логика ограничения доступа может лишь сузить, но не заменить системную авторизацию).

ПРИМЕР:

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

	Авторизация с использованием уникального номера сессии.
	Авторизация с использованием authinfo.
	Авторизация с использованием доверенных IP-адресов.
	Авторизация при локальном вызове функций VDSmanager.

Также в данном документе рассматривается использование протоколов HTTP и HTTPS при работе с панелью управления.

Авторизация с использованием уникального номера сессии

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

https://IP-адрес/manager/vdsmgr?auth=номер_сессии&out=xml&func=функция&параметр1=значение&параметр2=значение...

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

https://IP-адрес/manager/vdsmgr?out=xml&func=auth&username=имя_пользователя&password=пароль

После этого VDSmanager вернёт либо сообщение об ошибке, либо XML документ следующего вида:

<?xml version="1.0" encoding="UTF-8"?>

<doc>

<auth id="номер сессии"/>

</doc>

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

Авторизация с использованием authinfo

Данный метод авторизации удобен для удалённого обращения к панели управления. Для вызова какой-либо функции VDSmanager необходимо добавить дополнительный параметр authinfo и указать в нём имя пользователя и пароль, под которыми вы хотите выполнить операцию, например,

https://IP-адрес/manager/vdsmgr?authinfo=admin1:mypasswd&out=xml&func=функция&параметр1=значение&параметр2=значение...

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

Авторизация с использованием доверенных IP-адресов

Данный метод авторизации особенно удобен для удалённого обращения к панели управления, когда все обращения производятся с определённого IP-адреса. В качестве примера можно привести сервер, на котором располагается биллинговая система, которая периодически опрашивает панель управления для получения информации об использовании трафика, дискового пространства, количества сайтов и прочего. Данный метод позволяет отказаться от авторизации как таковой, указав в файле конфигурации панели управления vdsmgr.conf следующую строку:

TrustIP IP-адрес пользователь

В качестве параметра "IP-адрес" необходимо указать адрес сервера, с которого будут приходить запросы к панели управления. В качестве параметра "пользователь" - имя пользователя, с правами которого будут осуществляться операции с панелью управления. Данный параметр является опциональным. Если его нет, запросы будут обрабатываться с правами root.

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

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