Многоуровневой (n-tier), или промежуточной, аутентификацией называется регистрация программного обеспечения промежуточного уровня от своего имени для выполнения в базе данных каких-либо действий по поручению пользователя. Это позволяет создавать промежуточные приложения, использующие собственную схему аутентификации, например, с помощью сертификатов X509 или другого процесса однократной регистрации и регистрироваться от имени пользователя, не зная его пароля в базе данных. Хотя регистрация выполнена не от имени пользователя, а от имени промежуточного ПО, для базы данных он зарегистрирован.
Рассмотрим следующий пример - достаточно типичное современное Web-приложение:
Клиент представляет собой Web-браузер, отображающий HTML-страницы и обращающийся к Web-серверу/серверу приложений по протоколу HTTP (1). Само приложение находится на Web-сервере/сервере приложений, например, в виде Java-сервлета, модуля сервера Apache и т.д. На представленной выше схеме промежуточный сервер использует службу каталогов (directory service), доступную по протоколу LDAP, которой и передаются предоставленные пользователем реквизиты (2). Служба каталогов используется как средство аутентификации сеанса браузера. Если аутентификация прошла успешно, сервер приложений получает соответствующее уведомление (3) и, наконец, подключается к одной из нескольких баз данных (4) для получения данных и обработки транзакций.
"Реквизиты", передаваемые из браузера серверу приложений на шаге (1), могут быть разного вида - имя пользователя/пароль, ключ с сервера однократной регистрации, некий цифровой сертификат - все; что угодно. Имя пользователя базы данных и его пароль, как правило, не передается.
Проблема, конечно же, в том, что серверу приложений необходимо имя пользователя базы данных и пароль для аутентификации пользователя в используемой базе данных. Более того, комбинации имя пользователя/пароль в каждом случае будут разными. В рассмотренном выше примере имеется четыре базы данных:
• база данных ошибок, в которой надо регистрироваться, скажем, как TKYTE;
• база данных затрат, в которой надо регистрироваться как TKYTE_US;
• база данных планировщика, в которой надо регистрироваться как WEB$TKYTE;
• и так далее...
Правда, хорошо было бы аутентифицироваться один раз - на сервере приложений - и обеспечить доступ сервера приложений ко всем необходимым базам данных от нашего имени (или по нашему заданию), не передавая пароли для каждой базы данных? Именно это и обеспечивает многоуровневая аутентификация.
На уровне базы данных для этого достаточно задать опцию подключения. В Oracle 8i оператор ALTER USER был изменен и поддерживает конструкцию GRANT CONNECT THROUGH (подробнее она рассматривается далее, в разделе "Предоставление привилегии"). Рассмотрим доступ к базе данных затрат в представленном ранее приложении:
Служба каталогов содержит информацию сопоставления, связывающую пользователя TomKyte с клиентом базы данных TKYTE_US. После успешного получения этой информации сервер приложений (промежуточный сервер) может подключаться к базе данных со своими реквизитами от имени клиента базы данных, TKYTE_US. Серверу приложений при этом пароль пользователя TKYTE_US знать не надо.
Чтобы это можно было сделать, администратор базы данных затрат должен предоставить учетной записи APP_SERVER право подключаться от имени клиента:
alter user tykte_us grant connect through app_server
Сервер приложений будет работать в базе данных от имени и с привилегиями пользователя TKYTE_US, как если бы пользователь TKYTE_US зарегистрировался в базе данных непосредственно.
Таким образом, сервер Oracle 8i расширяет модель защиты настолько, что сервер приложений может безопасно работать от имени клиента, не требуя от него пароля соответствующей учетной записи в базе данных и не запрашивая многочисленные привилегии для доступа к объектам или процедурам, которые ему непосредственно не нужны.
Кроме того, система проверки также была расширена и включает действия, выполняемые сервером приложений от имени клиента. Другими словами, мы можем узнать, выполнил ли сервер приложений определенное действие от имени клиента.
Предоставление привилегии
Соответствующий оператор ALTER USER имеет следующий базовый синтаксис:
Alter user <имя пользователя> grant connect through
Это дает возможность пользователям, перечисленным в списке промежуточных пользователей, подключаться от имени указанного после ALTER USER пользователя.
По умолчанию для этих пользователей будут устанавливаться все роли данного пользователя. Другая разновидность этого оператора:
Alter user <имя пользователя> grant connect through
<промежуточный пользователь> WITH NONE;
позволяет промежуточной учетной записи подключаться от имени указанного пользователя, но только с ее базовыми привилегиями -роли включаться не будут. Кроме того, можно использовать:
Alter user <имя пользователя> grant connect through
Alter user <имя пользователя> grant connect through
<промежуточный пользователь> ROLE ALL EXCEPT имя_роли,имя_роли,...
Два представленных выше оператора дают промежуточной учетной записи возможность подключаться в качестве пользователя, но при этом включены будут только определенные роли. Необязательно давать учетной записи сервера приложений все привилегии - достаточно предоставить роли, необходимые для выполнения его функций. По умолчанию сервер Oracle пытается включить все стандартные роли пользователя и роли PUBLIC. Вполне допустимо разрешить серверу приложений использовать только роль HR данного пользователя, и никакие другие прикладные роли этого пользователя.
В этой главе мы изучили возможности многоуровневой, или промежуточной, аутентификации, которые доступны при программировании с использованием библиотеки OCI. Многоуровневая аутентификация позволяет серверу приложений промежуточного уровня действовать в качестве пользующегося доверием агента в базе данных от имени известного приложению клиента.
//не нашла в Кайте самого термина "сквозная аутентификация", так что хз как это будет в итоге