|
Программирование >> Oracle
Многоуровневая аутентификация 1501 OCISQL> select distinct authentication type from v$session connect info 2 where sid = (select sid from v$mystat where rownum =1); AUTHENTICATION E PROXY 1 row processed. OGISQL> exit G:\oracle\RDBMS\demo> Вот и все. Мы успешно зарегистрировались от имени пользователя SCOTT, не зная его пароля. Кроме того, мы увидели, как можно проверить, что мы работаем через промежуточную учетную запись, сравнивая значение USER c атрибутом PROXY USER, воз-вращаем1м функцией SYS CONTEXT, или просматривая информацию сеанса в представлении VSSESSION CONNECT INFO. Кроме того, явно видно, что включены роли CONNECT и RESOURCE. Если подключиться следующим образом: c:\oracle\rdbms\demo>cdemo2 tkyte/tkyte scott connect OGISQL> select * from session roles; ROLE GONNEGT 1 row processed. Видно, что включена роль CONNECT, - мы контролируем, какие роли включает сервер приложений . Предоставление привилегии Соответствующий оператор ALTER USER имеет следующий базовый синтаксис: Alter user <имя пользователя> grant connect through <омежуточный пользовательх, омежуточный пользователь>... Это дает возможность пользователям, перечисленным в списке промежуточных пользователей, подключаться от имени указанного после ALTER USER пользователя. По умолчанию для этих пользователей будут устанавливаться все роли данного пользователя. Другая разновидность этого оператора: Alter user <имя пользователя> grant connect through <омежуточный пользователь> WITH NONE; позволяет промежуточной учетной записи подключаться от имени указанного пользователя, но только с ее базовыми привилегиями -роли включаться не будут. Кроме того, можно использовать: Alter user <имя пользователя> grant connect through <омежуточный пользователь> ROLE мя роли,имя роли,.. . Alter user <имя пользователя> grant connect through <омежуточный пользователь> ROLE ALL EXGEPT имя роли,имя роли,.. . 1502 Глава 22 Два представленных выше оператора дают промежуточной учетной записи возможность подключаться в качестве пользователя, но при этом включены будут только определенные роли. Необязательно давать учетной записи сервера приложений все привилегии - достаточно предоставить роли, необходимые для выполнения его функций. По умолчанию сервер Oracle пытается включить все стандартные роли пользователя и роли PUBLIC. Вполне допустимо разрешить серверу приложений использовать только роль HR данного пользователя, и никакие другие прикладные роли этого пользователя. Разумеется, можно и отобрать соответствующую привилегию: Alter user <имя пользователя> EVO connect through <промежуточн1й пользователь><,промежуточный пользователь>... Есть административное представление, PROXY USERS, которое можно использовать для получения информации обо всех промежуточных учетных записях. После выполнения оператора ALTER user SCOTT GRANT CONNECT through tkyte в представлении PROXY USERS будет: TKYTE@TKYTE816> select * from proxy users; PROXY CLIENT ROLE FLAGS TKYTE SCOTT PROXY MAY ACTIVATE ALL CLIENT ROLES Проверка промежуточных учетных записей Вот новый синтаксис оператора AUDIT для работы с промежуточными учетными записями: AUDIT <действие> BY <промежуточный пользователь>, <промежуточный пользователь> ... ON BEHALF OF <клиент>, <клиент>.. ; или: AUDIT <действие> BY <промежуточный пользователь>, <промежуточный пользователь> ON BEHALF OF ANY; Новая часть - BY <промежуточн1й пользователь>... ON BEHALF OF. Она позволяет явно проверять действия, выполняемые указанными промежуточными пользователями от имени некоторых или всех учетных записей. Предположим, администратор включил проверку, установив параметр инициализации AUDIT TRAIL=TRUE и перезапустив экземпляр. Тогда можно использовать: sys@TKYTE816>audit connect by tkyte on behalf of scott; Audit succeeded. Теперь, если использовать для подключения измененную программу cdemo2.c: C:\oracle\RDBMS\demo>cdemo2 tkyte/tkyte scott connect OCISQL> exit В таблице DBA AUDIT TRAIL я обнаружу следующее: Многоуровневая аутентификация 1503
Интересно отметить, что при подключении пользователя SCOTT или пользователя TKYTE с помощью утилиты SQL*Plus записи проверки не создаются. Проверка строго ограничена конструкцией: connect by tkyte on behalf of scott; При необходимости можно проверять подключение пользователей TKYTE или SCOTT, просто в данном случае я решил этого не делать. Этот пример демонстрирует, что средства многоуровневой аутентификации не противоречат учету действий в базе данных (можно определить, что именно пользователь SCOTT выполнил определенное действие), позволяя также определить, когда действие от имени пользователя SCOTT выполнил сервер приложений. Проблемы Обычно многоуровневая аутентификация работает вполне предсказуемо. Если подключиться следующим образом: C:\oracle\RDBMS\demo>cdemo2 tkyte/tkyte scott connect Это будет равносильно непосредственной регистрации пользователя SCOTT. Средства обеспечения работы с правами вызывающего и правами создателя (см. главу 23) функционируют так, как если бы зарегистрировался пользователь SCOTT. Средства тща-
|
© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки. |