1504 Глава 22

тельного контроля доступа (см. главу 21) функционируют так, как если бы зарегистрировался пользователь SCOTT. Триггеры на событие регистрации пользователя SCOTT срабатывают. И так далее. Я не нашел ни одной возможности, которая б1ла бы недоступна при использовании многоуровневой аутентификации.

Есть, однако, одна деталь реализации, которая может привести к проблемам. При использовании многоуровневой аутентификации сервер будет автоматически включать набор ролей. Если вы используете атрибут OCI ATTR INITIAL CLIENT ROLES, как в представленном выше коде, то ожидаете, что в набор войдут только явно заданные роли. Однако всегда включаются также все роли, предоставленные роли PUBLIC. Например, если предоставить роль PLUSTRACE роли PUBLIC (роль PLUSTRACE позволяла использовать установку AUTOTRACE, которую мы постоянно применяли по ходу изложения в среде SQL*Plus для оценки производительности):

sys@TKYTE816> grant plustrace to public-Grant succeeded.

Теперь при подключении с помощью нашей утилиты ни-SQL*Plus : c:\oracle\rdbms\demo>cdemo2 tkyte/tkyte scott connect OCISQL> select * from session roles;

ROLE CONNECT

PLUSTRACE

2 rows processed.

оказывается, что кроме роли CONNECT включена также роль PLUSTRACE. Сначала это не кажется опасным. Однако, если с помощью оператора ALTER USER явно потребовать предоставлять пользователю только строго ограниченный набор ролей:

sys@TKYTE816> alter user scott grant connect through tkyte with role -> CONNECT; User altered.

окажется, что:

c:\oracle\rdbms\demo>cdemo2 tkyte/tkyte scott connect Ошибка - ORA-28156: Proxy user TKYTE not authorized to set role PLUSTRACE for client SCOTT

пользователю TKYTE не разрешено включать эту роль при подключении от имени пользователя SCOTT. Решить эту проблему можно только так:

1. не предоставлять ролей роли PUBLIC;

2. всегда добавлять соответствующие роли к списку ролей в операторе ALTER USER Например, если выполнить:

sys@TKYTE816> alter user scott grant connect through tkyte with role

2 connect, plustrace; User altered.

Многоуровневая аутентификация 1505

следующая команда сработает, как и предполагалось:

c:\oracle\rdbms\demo>cdemo2 tkyte/tkyte scott connect OGISQL> select * from session roles;

ROLE

GONNEGT PLUSTRAGE

Резюме

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

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

Права вызывающего и

создателя

Для начала представим ряд определений, чтобы гарантировать однозначное понимание терминов вызывающий и создатель:

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

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

До версии Oracle 8i все скомпилированные хранимые объекты выполнялись с правами создателя объекта. По отношению к соответствующей схеме происходило и разрешение имен. Другими словами, набор привилегий, непосредственно предоставленных владельцу (создателю) объекта использовался при компиляции для определения того:

к каким объектам (таблицам и т.д.) фактически обращаться;

есть ли у создателя необходимые для доступа к этим объектам привилегии.

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