Авторизация в Оракуле

← →
{bas} (2002-10-21 15:48) [0]

Есть проблема отлавливания всех коннектов к базе и проверка в своих таблицах на возможность входа. Я сделал триггер after logon on DATBASE, но больно он стремный какой-то:
1. При его поломке (инвалидности) никто не может войти в систему
2. При наличие двух схем непонятно что будет - Оракул не б. знать из какой схемы брать таблицы

Вот как мне сделать авторизацию по нормальному, причем ХП не подходят, т.к. не только из проги может зайти пользователь.

Спасибо

← →
Reindeer Moss Eater (2002-10-21 16:05) [1]

А может пусть сервер сам этим занимается?

← →
MishGan (2002-10-21 16:11) [2]

>>1. При его поломке (инвалидности) никто не может войти в систему
sys сможет всегда.
..
А маломальски приемлимую защиту можно сделать так:
1) Нужно использовать роли, причем не просто роли, а роли с паролями.
CREATE ROLE APPUSER IDENTIFIED BY "1234567890";
2) Пользователям никаких прав на работу с объектами не даешь, только через роли.
3) Пользователяем не назначаешь никаких дефолтовых ролей.
grant APPUSER to user1;
alter user user1 default role none;
4) При начале работы твоего приложения активизируешь роль для текущей сессии.
set role APPUSER identified by "1234567890"
..
Пароли для ролей хранить нужно где-то в зашифрованном виде, чтоб ни один юзер до них добраться не мог.

← →
{bas} (2002-10-21 16:20) [3]

Конкретно мне нужно проверить при коннекте - м. данный юзер входить с данной машине и зарегестрированы юзер и машина в моих таблицах

роли и ХП тут не подходят

← →
Reindeer Moss Eater (2002-10-21 16:39) [4]

Если юзер знает правильные логин и пароль, он может входить. А то, что ты хочешь получить решается не таким способом

← →
{bas} (2002-10-22 13:29) [5]

>> Reindeer Moss Eater
А каким???

← →
petr_v_a (2002-10-22 15:20) [6]

create table T_USER_LOGON_TERMINAL(
USER_ID integer -- сюда записываем UID user`а, можно
-- набраться наглости и сослаться на
-- sys.user$, но не нужно
VALID_TERMINAL varchar2(4000) -- машина с, которой разрешен
-- вход, null если со всех,
-- следите, чтобы не было
-- записей и с null и с именами
-- компьютеров
)

create trigger db_after_logon
after logon on database
declare
x integer;
begin
select null
into x
from T_USER_LOGON_TERMINAL -- для верности можно
-- <схема>.T_USER_LOGON_TERMINAL
where USER_ID = uid
and ( VALID_TERMINAL = userenv("TERMIAL") or
VALID_TERMINAL is null
)
exception
when NO_DATA_FOUND then
raise_application_error(-20001,"Кыш на СВОЕ рабочее место");
when others then
raise;
end;

Возможны опечатки, писал прям отсюда, но идея верна! :))))
При работе в BDE сообщение об ошибке будет съедено и заменено на какую-то BDE`шную чушь, но юзер не прорвется :)

← →
{bas} (2002-10-22 16:02) [7]

>>petr_v_a
это - то как раз ясно - я так и сделал
но поблема не в этом
2. При наличие двух одинаковых(по таблицам и логике) схем непонятно что будет - Оракул не б. знать из какой схемы брать таблицы -> На самом деле эти две схемы(С1 и С2) живут со своими T_USER_LOGON_TERMINAL и при коннекте к базе из какой табл (из с1.T_USER_LOGON_TERMINAL или с2.T_USER_LOGON_TERMINAL)брать значения Оракул не знает и не должен знать , т.к. это коннект к базе

← →
MishGan (2002-10-22 16:33) [8]

Объясни, почему не подходят роли.
Можно сделать так:
1) Пароль для роли хранить в таблице БД. Прямого доступа к этой таблице никому давать нельзя.
2) Приложение при старте посылает запрос к серверу (т.е. вызывет некую ХП, в которой проверяется корректность данного подключения, например IP-адрес клиента). Если пользователь авторизован успешно - процедура возвращает пароль для активации роли.
3) Далее пытаемся активировать роль.

← →
{bas} (2002-10-22 16:42) [9]

>>MishGan
ну в принципе можно наверное - но хотелось более эллегантый способ решения проблеммы -на уровне триггеров, что бы не трогать клиента, т.к. клиентских приложений много и переписывать их совсем неохота

а так спасибо за идею

← →
Yuvich (2002-10-22 18:15) [10]

> {bas}

1) Про наличие двух одинаковых схем и двух триггеров:
Для себя я сделал вывод, что триггеры уровня database, типа after logon, after drop, after grant, должны быть в единственном
числе и у пользователя sys.

2) Правомочьность использования триггера after logon для проверки входа - сомнительна.

Предположим, таблица прав существует в единственном числе у пользователя sys, тогда эту таблицу надо вести для всех пользователей и для всех объектов. Если их много - иногда физически невозможно.

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

В этом и состоит Сомнительность.

Правильно - делать как предлагает MishGan: использовать роли, только проще - без паролей (пользователь должен иметь дефолтовую роль с единственным правом CREATE SESSION и ALTER SESSION). Твое приложение должно подключить роль с правами к сессии.

← →
petr_v_a (2002-10-22 18:53) [11]

да триггер-то работает с правами sys и ему доступны любые таблицы и на права входящего пользователя ему наплевать. Если таблица автроизации существует в нескольких схемах, можно либо создать для нее public synonym либо в тексте триггера явно указать схему. А в схеме sys создавть свои объекты нехорошо.

← →
Yuvich (2002-10-22 20:09) [12]

> petr_v_a
"да триггер-то работает с правами sys и ему доступны любые таблицы и на права входящего пользователя ему наплевать ..."
- возможно, но что это меняет?

"... Если таблица автроизации существует в нескольких схемах, можно либо создать для нее public synonym либо в тексте триггера явно указать схему ..."
- все это решает частные случаи (количество схем, их имена - известны, состав постоянен), но не решает общий случай (количество схем меняется, их имена - изменяются, состав не постоянен)

"... А в схеме sys создавть свои объекты нехорошо ..."
- схема sys ничем не отличается от, скажем, схемы public

← →
petr_v_a (2002-10-22 20:35) [13]

>Yuvich За свои объекты в схеме sys с чистой совестью снимают с техподдержки, сколько бы Вы за нее ни платили, от других она отличается хотя бы тем, что войти под sys можно несмотря ни на какие триггеры, и даже при незапущенном экземпляре ( internal - это он же, родимый ). Если состав и и имена схем настолько не постоянны, что даже sys от Вашего баловства не застрахован, то в настолько общем случае задача, наверно,действительно не решаема :))
Но обычно существует схема, в которой лежат все ( или почти все) объекты, с которыми работает приложение, и она так же уважаема, как SYS, в ней-то и стоит создать таблицу авторизации

← →
{bas} (2002-10-22 21:27) [14]

>> petr_v_a
Вы всё говорите об одной схеме - я с ней уже разобрался

>>Yuvich
Т.е. самый лучший способ, при старте приложения вызывать ХП и в ней назначать на сесию роли.

>> ALL
И это единственный способ нормальной авторизации - не м. б(вызов ХП перед стартом).

← →
Yuvich (2002-10-23 18:04) [15]

> {bas}
"Т.е. самый лучший способ, при старте приложения вызывать ХП и в ней назначать на сесию роли"
- не получится, т.к. ХП будет назначать роль не той сессии. Надо делать из приложения и из той сессии в которой будет происходить работа с БД.

Не хотелось бы попусту спорить. Я лучше расскажу о своей системе администрирования. Она работает с 1997г. в шести проектах: двух на Informix 7.1, 7.3 и четырех на oracle 7.3, 8.0.5, 8.1.7.

Сначала определим несколько понятий:
Учетная Система (УС) - ERP система, обслуживающая определенную предметную область;
Система Администрирования (СА) - часть ERP системы, относительно независимая, отвечающая за разграничение прав доступа к объектам УС;

Основные принципы, вытекшие из ТЗ:

- число серверов, обслуживающих УС - бесконечно;
- число баз данных (схем, пользователей-владельцев схем) на дном сервере - бесконечно;
- пользователи УС не имеют своих объектов oracle и получают права доступа к объектам oracle от пользователей-владельцев баз данных УС;
- число пользователей УС (и подчиняющихся СА) на каждом сервере - бесконечно;
- пользователи УС - подмножество всех пользователей данного сервера oracle;
- пользователь, имеющий определенные права в одной базе данных, на другом сервере или в другой базе данных на этом же сервере, может иметь совершенно другие права;
- пользователь должен мочь работать с одного рабочего места (из одного екзешника) со всеми базами данных

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

В процессе работы определились следующие типы одинаковых баз данных:

- рабочая база;
- тренировочная база - база, где тренируются пользователи УС перед тем как сделать то же самое на рабочей базе, если операция для них новА;
- база разработчиков - база, где разработчики отлаживают код хранимых процедур и модифицируют саму базу;
- тестовая база - база-копия рабочей, где разработчики проверяют хран. проц. на реальных данных, а не синтетических тестах;

Понятно, что баз каждого типа может быть несколько на разных или одном сервере (кроме рабочей).

Система Администрирования.

Состоит из нескольких таблиц, хранящих информацию о:
- всех объектах oracle УС (таблицы, процедуры, пакеты, представления);
- всех возможных операциях над объектами oracle УС;
- всех пользователях УС;
- всех группах пользователей;
- всех объектах пользовательского интерфейса УС;

Администрируются следующие Права:

- доступ к серверу УС;
- доступ к какой-либо базе данных УС;
- доступ к операции над объектом oracle, обслуживающий какую-либо сущность УС. Например, select к

таблице или execute процедуры;
- доступ к модулю УС (екзешник, форма внутри екзешника)
- доступ к видимому элементу формы УС. Например, к колонке грида, к кнопке вставки записи;

← →
Yuvich (2002-10-23 18:05) [16]

Продолжение ...

Теперь о частностях.

Процесс авторизации.

Сначала заводится сервер в таблице СА, например Work. При этом указывается, какая роль oracle будет использоваться по умолчанию. Этой роли дается грант на CREATE SESSION и ALTER SESSION, например, WORK_CONNECT.

Потом заводится пользователь в таблице СА.

Далее указывается: на каких серверах УС он может работать. Во время сохранения этой информации в таблице СА, он заводится как пользователь oracle на данном сервере.

Далее указывается: какой Группе принадлежит данный пользователь и какую предметную роль он будет играть, зайдя на данный сервер. Например, пользователь user1 заведен на сервер Work и включен в Группу Store и ему дана предметная роль "Кладовщик главного Склада". В oracle заводится пользователь USER1 и к нему цепляется дефолтовая роль по умолчанию данного сервера WORK_CONNECT, заводится роль STORE и она тоже цепляется к пользователью user1, но не как дефолтовая.

Далее все права на объекты oracle цепляются к USER1 или STORE.

Приложения УC написаны на Delphi и ODAC.
Когда пользователь авторизуется на каком-либо сервере, система (главное окно типа MDIForm) его спрашивает: какую роль будешь играть - какую-то определенную или все роли данные пользователю (в этом месте пользователь еще никаких прав не имеет, кроме прав роли WORK_CONNECT).

Когда пользователь открывает форму (типа MDIChild) только тогда по предметной роли приложение узнает роль oracle и выполняет команду SET ROLE WORK_CONNECT, STORE в текущей сессии пользователя и он получает необходимые права для работы с формой УС. Когда форма закрывается и нет других открытых форм, выполняется команда SET ROLE WORK_CONNECT - права опять отрезаются кроме минимальных.

Если пользователь имеет несколько открытых сессий на другие сервера УС - принцип работы авторизации тот же, только имена ролей и серверов другие.

Обслуживание АС.

Так как приходится вести базу разработчиков, в которой таблицы постоянно меняются, создаются и удаляются и при этом сами разработчики тоже подчиняются СА, - были написаны скрипты и тригер синхронизации текущего состояния база данных и таблицы об объектах oracle в СА.

Смысл тригера таков: при удалении какого-либо объекта oracle, удаляется информация о нем из СА.
(условие: объект удаляется влядельцем)

Фрагмент кода тригера:

create or replace trigger befdrop_database before drop on database declare puser varchar2(20); ptable user_tables.table_name%type; begin select user into puser from dual; if dictionary_obj_type = "USER" then ... ... elsif dictionary_obj_type = "ROLE" then ... ... elsif (dictionary_obj_type = "TABLE") or (dictionary_obj_type = "VIEW") or (dictionary_obj_type = "SEQUENCE") or (dictionary_obj_type = "PROCEDURE") or (dictionary_obj_type = "FUNCTION") or (dictionary_obj_type = "PACKEGE") then ... ... /* пример удаления прав доступа Групп пользователей к удаляемой таблице */ begin /* проверка: является ли удаляемая таблица таблицей УС */ select table_name into ptable from user_tables where table_name = "OBJGRPACCESS"; /* если да, то удаляем из таблицы СА, если нет - возникает exception */ execute immediate "delete from "||puser||".objgrpaccess where objname = """||dictionary_obj_name||""""; exception when no_data_found then /* удаляемая таблица не является таблицей УС */ null; end; ... ... end if; end;

Если на некоторых серверах для одних и тех же групп надо назначить одинаковые права, то можно их просто скопировать с одного сервера на другой - СА это позволяет.

Авторизация в Оракуле Найти похожие ветки