Форум: "Базы";
Текущий архив: 2002.11.14;
Скачать: [xml.tar.bz2];
ВнизАвторизация в Оракуле Найти похожие ветки
← →
{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;
Если на некоторых серверах для одних и тех же групп надо назначить одинаковые права, то можно их просто скопировать с одного сервера на другой - СА это позволяет.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.11.14;
Скачать: [xml.tar.bz2];
Память: 0.53 MB
Время: 0.009 c