Программирование >>  Oracle 

1 ... 357 358 359 [ 360 ] 361 362 363 ... 469


Многоуровневая аутентификация 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

OS USERNAME

: Thomas?Kyte

USERNAME

: SCOTT

USERHOST

TERMINAL

: TKYTE-DELL

TIMESTAMP

: 08-may-2001 19:19:29

OWNER

OBJ NAME

ACTION

: 101

ACTION NAME

: LOGOFF

NEW OWNER

NEW NAME

OBJ PRIVILEGE

SYS PRIVILEGE

ADMIN OPTION

GRANTEE

AUDIT OPTION

SES ACTIONS

LOGOFF TIME

: 08-may-2001 19:19:30

LOGOFF LREAD

: 23

LOGOFF PREAD

LOGOFF LWRITE

LOGOFFDLOCK

COMMENT TEXT

: Authenticated by: PROXY:

SESSIONID

: 8234

ENTRYID

STATEMENTID

: 1

RETORNGODE

: 0

PRIV USED

: GREATE SESSION

Интересно отметить, что при подключении пользователя 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. Средства тща-



1 ... 357 358 359 [ 360 ] 361 362 363 ... 469

© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика