Доброго времени суток!

Стою на пороге изобретения велосипеда  .

Итак. Были БД (Firebird) и web-приложение (Mono). Для аутентификации были переопределены MembershipProvider и RoleProvider, для чего в БД созданы таблицы user, role, membership. Для ограничения пользователей в навигации использован Web.sitemap и соответствующие настрйки web.config. В целом все работало.
Но! Т.к. БД сложная (и важная), то вопрос разграничения прав между пользвателями является не тривиальной задачей (ранее этот вопрос уже поднимался).
После долгих раздумий у меня появилось желание возложить задачу контроля прав на СУБД и "транслировать" его (контроль) на уровень web-приложения, т.е. отказаться от использования указанных таблиц user, role, membership, а воспользоваться предоставляемым СУБД сервисом (возможностью создавать пользователей и роли, а самое главное возможностью наделения ролей и пользователей правами).
MembershipProvider и RoleProvider для выполнения поставленной задачи я переписал.
При этом используется следующий сценарий при доступе:
1. Пользователь вводит в web-браузере имя и пароль;
2. От имени пользователя unknown выполняется хранимая процедура на сервере, которая проверяет наличие указанного пользователя;
3. Если указанный пользователь существует, то от его имени для него определяются доступные роли;
4. На основании доступных ролей и Web.sitemap для пользователя отображается соответствующие ссылки;
5. Пользователь осуществляет переход по разрешенным ссылкам используя необходимые для этого роли.
Пункты 1 - 4 реализовать мне удалось, но вот с пунктом 5 у меня возникла проблема. Дело в том, что для переходе по предоставленным ссылкам пользователь обращается к БД от своего имени с различными ролями и для этого необходимо создавать новые подключения, а значит необходимы имя пользователя и пароль имя пользователя я узнаю так:

Роль я определяю по ссылке по которой переходи пользователь. Т.о. остается вопрос как определить пароль?
Вариантов я вижу несколько:
1. Постоянно переспрашивать у пользователя его пароль (ужас - меня найдут и побьют  );
2. Хранить пароль на стороне клиента и при необходимости отправлять его на СУБД (не уверен, но, по моему, за такое тоже могут побить).

Посоветуйте как быть? И кто вообще что думает по изложенному вопросу?
Буду признателен за любой совет.

А в сессии нельзя хранить пароль?

А, уровни доступа? Ну, чем выше уровень, тем больше тебе приходиться проходить регистраций, при этом, после прохождения новой регистрации, ты можешь войти на ресур уже под новым уровнем доступа, как такой вариант? Я не советую, я спрашиваю, просто собираюсь на своем сайте нечто подобное сделать, но пока это у меня в теории.

Я не по ASP.NET, я больше по SQL  , поэтому я не знаю можно или нельзя (а так же на сколько это решение удачно).
Буду признателен если буквально в двух словах поясните приемущество данного способа.


Уровень доступа определяется ролью.


Не совсем понял.
В моем случае "переход на уровень вниз" заключается переписыванием MembershipProvider и RoleProvider, что бы запросы направлялись не к пользовательским таблицам, а к системным.


С одной стороны да (в плане полномочий), но и нет (в плане реализации).
Я хотел бы сделать так, что бы пользователь проходил аутентификацию единожды, а затем, в течении сеанса, мог бы выбирать для себя любой из разрешенных уровней доступа (ролей в нотаци СУБД).

Попробовал хранить пароль в сессии.
В целом получается, но наблюдается некоторое не приемлимое для меня поведение (например после закрытия и повторного открытия браузера, если не был явно выполнен выход из под учетной записи, доступ к закрытым данным осуществляется). Я думаю, что это не проблема и нужно бы почитать MSDN.

Gluttton, ну для сессий это нормально, они живут какое-то время (по-умолчанию вроде 20 минут), время жизни можно настроить в Web.config.