Доброго тебе времени суток, All.

У меня возникла проблема - недостаточная гибкость системы безопасности в текущем проекте. Проект написан на mod_perl + Oracle:DBI + apache.
В общем, ситуация следующая:
Существует клиентский web-interface, у него есть некий функционал, вызывающийся через GET: ".....&command=COMMAND&...." либо PUT: "document.MainForm.command.value='COMMAND'; клиент получает данную команду и далее выполняет ее. Далее.
Перед выполнением команды, он считывает характеристики пользователя, его user_id, тип, статус, его текущий хэш, и т.д.
На данный момент в программе все прошито статикой, т.е. что-то типа:

Ну и т.д. Соответственно, чем больше типов пользователей, тем больше if я должен сравнивать и проверять. И самое главное, что они расположены не только при проверке выполнения команды, но и внутри команды. Т.к. многие типы пользователей или даже отдельные пользователи могут выполнять одну и туже команду но с разными правами ее выполнения. Некоторым просто не доступен ее полный функционал.
На данный момент существуют:
1. словарь типов и статусов пользователей.
2. словарь с какими типами пользователей может работать текущий тип пользователя. В том числе, может-ли он менять им статус.
3. grant_type: Типы грантов на запуск какой-то отдельной команды.
4. user_grants_ex: user_id для которого данная команда (из grant_type) запрещена, несмотря на его тип.

Все это используется на данный момент. Какие есть идеи:
1. В grant_type поместить все существующие команды, и строки их исполнения.
2. Создать, полностью определяемые суперюзером группы, в которые входят те или иные команды. Одна команда, может входить в разные группы.
3. Добавить таблицу в которой данному типу пользователя будут принадлежать такие-то группы.

Какие есть pros & cons.
PROS:
1. Динамический интерфейс. Даже меню. Т.е. sql запросом получаем весь список команд доступных пользователю. Держим его в хэшэ и постоянно с ним сверяемся.
CONS:
1. Лазить в базу за такими вещами как комманды исполняемые юзеров...
Не будет ли это слишком накладно? Особенно если учесть что база OLTP.
Пусть и права у web юзера на ресурсы сбазы минимальные, но все-же... Тем более что юзеров много.

Так, текущую ситуацию я вроде обрисовал. Если будут доп. вопросы, отвечу с удовольствием.

Теперь мой вопрос, моя цель - построить *гибкую, легко программируемую, быструю* систему аутентификации пользователя.
Как вообще делаются подобные системы?
Как вы должно быть понимаете, я старался исходить из реализации подсистемы авторизации UNIX. Т.е. группы, права на доступ. Кстати, по умолчанию все права на запуск команд есть только у суперюзера.
Но, думаю здесь этот подход не совсем верен.

С уважением,
Сергей

Честно говоря не знаю.
Думаю как раз о проектировании системы аутентификации.

С уважением,
Сергей

2 Cat2:
Да, у меня база тоже определяет профиль залогиннившегося юзера.
Его тип, статус, хэш, язык интрефейса, код валюты по умолчанию, новости для него, и т.д.
Вопрос именно в application servere. Как сделать его не гибким.
Хотя, возможно для этого придется поменять что-то в базе.
Кстати, какие у тебя таблицы и какую ты схему реализовал, хотя-бы в общих чертах, не расскажешь?

С уважением,
Сергей

2 it depends: Возможно. Во всяком случае не хочется изобретать велосипед.
Сейчас буду разбираться с исходниками.

Спасибо!

Сергей