Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Разграничение прав доступа / 5 сообщений из 5, страница 1 из 1
23.10.2007, 13:45
    #34887808
Black
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Разграничение прав доступа
Добрый день!

Программа разрабатывается под web, будет работать от имени основного пользователя, который имеет доступ ко всем таблицам проекта, а все остальные "пользователи" будут виртуальными => как, предположим, на любом форуме... мы же не регистрируем их в Б.Д, а просто заносим в таблицу, например, members.

Программа, имеет десятки классов, к методам которых предоставляется доступ на основе привелегий к таблицам Б.Д.

Например, есть класс proprietor, в его подчинение ( на уровне программы ) таблицы:
proprietor
proprietor_xxx
proprietor_stats

Если пользователь имеет привелегию select к таблице proprietor, соответственно ему будет позволено пользоваться методом proprietor.view, если имеет привелегию update, то proprietor.edit, и т.п.

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

Привелегии будут даваться на основе ролей, роль в свою очередь может наследовать привелегии другой роли.
Предполагаю, что структура таблицы для ролей будет следующая:
Имя таблицы members_roles
ROLE_NAME TABLE_NAME COLUMN_NAME PRIV
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
	CREATE TABLE "MEMBERS_ROLES" 
	(
		"ROLE_NAME" VARCHAR2( 100 ) NOT NULL, 
		"TABLE_NAME" VARCHAR2( 100 ), 
		"COLUMN_NAME" VARCHAR2( 100 ), 
		"PRIV" VARCHAR2( 10 )
	)  
	TABLESPACE "USERS";

И таблица предоставленных пользователю ролей.
Имя таблицы members_priv
MEMBER_ID ROLE_NAME
Код: plaintext
1.
2.
3.
4.
5.
6.
	CREATE TABLE "MEMBERS_PRIV" 
	(
		"MEMBER_ID" NUMBER( 11 ) NOT NULL, 
		"MEMEBER_ROLE_NAME" VARCHAR2( 100 ) NOT NULL
	)  
	TABLESPACE "USERS";

Создаем роль default_role, которая будем иметь привелегию select к всей таблицы proprietor, proprietor_xxx
Код: plaintext
1.
2.
INSERT INTO members_roles VALUES ('default_role', 'proprietor', NULL, 'select');
INSERT INTO members_roles VALUES ('default_role', 'proprietor_xxx', NULL, 'select');

Если мы хотим предоставить пользователю привелегии роли default_role, нам необходимо в таблицу members_priv сделать insert с значениями ID пользователя, имя роли.
Код: plaintext
1.
INSERT INTO members_priv VALUES ( 1 , 'default_role');
Тут думаю все предельно просто ...

Вопрос для меня в следующем, как правильно спроектировать наследование ролей.

Предположим есть вторая роль second_role, она имеет привелегию update к таблице proprietor_stats.
Код: plaintext
1.
INSERT INTO members_roles VALUES ('second_role', 'proprietor_stats', NULL, 'update');

Теперь попробуем наследовать ролью default_role привелегии роли second_role , для этого создаим третью таблицу members_roles_inheritance
ROLE INHERITANCE_ROLE
Код: plaintext
1.
2.
3.
4.
5.
6.
	CREATE TABLE "MEMBERS_ROLES_INHERITANCE" 
	(
		"ROLE" VARCHAR2( 100 ) NOT NULL, 
		"INHERITANCE_ROLE" VARCHAR2( 100 ) NOT NULL
	)  
	TABLESPACE "USERS"; 
Код: plaintext
INSERT INTO members_roles_inheritance VALUES ('default_role', 'second_role');

Думаю структура на первый взнляд логична ...

Теперь усложним, предположим роль second_role наследует привелегии роли third_role
Код: plaintext
1.
2.
3.
4.
-- Даем роли привелегии 
INSERT INTO members_roles VALUES ('third_role', 'proprietor', NULL, 'delete');
-- Наследуем 
INSERT INTO members_roles_inheritance VALUES ('second_role', 'third_role');

Получается, что теперь роль default_role имеет привелегии ролей second_role, third_role.

Как Вы думаете, насколько данная структура имеет право на жизнь?

Для меня очень серьезным вопросом остается, как мне потом получить все привелегии для пользователя, если роль наследует роль, та роль в свою очередь наследует еще роль как было показано выше?!

Заранее благодарен за помощь и любые комментарии!
...
Рейтинг: 0 / 0
25.10.2007, 11:02
    #34893534
Shtock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Разграничение прав доступа
Мы убрали наследование прав внутри ролей. Так прикладные админы больше путались. И еще у нас был принцип-1 пользователь-1 роль,потому как довольно часто наблюдаются перемешивания полномочий внутри "многоролевого" пользователя.
...
Рейтинг: 0 / 0
25.10.2007, 11:09
    #34893569
Mainframe_старый
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Разграничение прав доступа
Нормально наследование работает, наоборот куча проблем решается - есть роль редактор всех документов некоторого типа. Она наследуется от роли редактор отдельного документа . Т.е. все кто имеют роль редактор документов типа А, сразу становятся редакторами всех документов типа А. Но можно дать пользователю редактирования отдельных документов. При этом при наследовании мы указываем связи по какому параметру наследование идет - в данном случае по типам.
...
Рейтинг: 0 / 0
25.10.2007, 11:34
    #34893666
Black
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Разграничение прав доступа
ShtockМы убрали наследование прав внутри ролей. Так прикладные админы больше путались. И еще у нас был принцип-1 пользователь-1 роль,потому как довольно часто наблюдаются перемешивания полномочий внутри "многоролевого" пользователя.
Как уже сказал Mainframe_старый , данная структура решает очень много проблем, легче управлять пользователями "одним кликом", а для каждого пользователя своя роль, это слишком накладно, а если их 300, 500 ...

То, что я пытаюсь реализовать, основано на разграничение доступа в Oracle, все П.О. я пишу использую данную Б.Д., но сейчас как уже говорил, появилась необходимость написать программу под WEB, и мне не хочется создавать десятки пользователей, которые будут иметь доступ извне.
...
Рейтинг: 0 / 0
25.10.2007, 14:13
    #34894426
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Разграничение прав доступа
BlackТо, что я пытаюсь реализовать, основано на разграничение доступа в Oracle, все П.О. я пишу использую данную Б.Д., но сейчас как уже говорил, появилась необходимость написать программу под WEB, и мне не хочется создавать десятки пользователей, которые будут иметь доступ извне.
Во-первых, десятки пользователей лучше создать без всякого описанного здесь геморроя. Для тысяч - можно поискать другое решение, например, использовать OID.

Во-вторых, даже для тысяч пользователей следует создать серверные роли. Скажем, для упомянутого Вами форума это будут роли "гость", "пользователь", "модератор", "администратор". Каждой такой роли - соотнести серверный account; соответственно, "десятки пользователей" будут логинится под эккаунтом своей роли. В принципе также можно воспользоваться механизмом application role, но имхо это неоправданный геморрой.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Разграничение прав доступа / 5 сообщений из 5, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]