Есть мысль ... я ее думаю
Короче есть необходимость получить доступ к некоторому ограниченному
пространству БД до идентификации пользователя ....
Зачем:
В этом пространстве будет храниться информация, необходимая в том числе и для идентификации (ну например: дерево разделителя учета, (т.е. возможность выбора в окне логина, некоторых специфических реквизитов и т.д.)
Есть мысль все это запихнуть в отдельную схему, создать юзера (например COMMON) с минимальными правами на эту схему и фиксированным паролем-сохраненным либо в теле программы либо в конфиг файле (возможно в шифрованном виде) и после запуска приложения логиниться этим пользователем и получать необходимые данные ... потом уже выдавать окно логин и далее все как обычно ....
Теперь вопрос: верно ли это концептуально или все же это потенциальный "геморой" в плане защиты ?

Какие я вижу альтернативы: хранить эти данные либо в регистрах, либо в конфиг файле (но при этом как мне кажеться теряется масштабируемость, т.е.
при репликации данных необходимо будет еще реплицировать конфиг и/или на каждом клиенте делать дополнительные телодвижения ...

Ваше мнение ?

Old NickА систему хочешь в 2 или 3 уровня?

Система планируется достаточно сложная,
т.е. будут регионалные центры (РЦ) - в которых будут свои серваки
(реплицируемые) с вервером в ЦРЦ
в этих офисах будут Толстые клиенты (WinForms) с хорошей функуиональностью, кроме этого в этих-же РЦ будут службы webservice и доступ к базе по тонкому клиенту с объектов (WebForms) - с ограниченным функционалом ....

Old NickПочитай здесь как такое реализовать

Меня пока не интересует ядро безопасности (хотя это тоже важно) ...
попробую конкретней

допустим есть таблица

так вот, что бы залогинить пользователя , я должен в окне логина выдать,
список предприятий(подразделений) с которым собирается! работать пользователь и на основании этих "предварительных" данных уже будет проверятся уровень(и разрез) доступа а возможно и клиентский интерфейс, понятно что это список можно хранить где угодно ... но тогда почему не в базе ... ?
Т.е. для примера как сделано в 1С, т.е. сначала берется список баз (из реестра) и потом пользователь выбираетс из него и логинится, но если кто с этим сталкивался то помнит, что на каждом клиенте(и под каждым экаунтом виндов) надо прописать этот путь к базам заново ... вот этого я и хочу избежать ...

Old NickПоясняю. Система доступа разграничивает доступ к объектам базы данных. В моей реализации любой объект лежит в какой-нибудь папке (это тоже объект с набором прав доступа). Пользователь - это тоже объект, у которого есть набор прав на какие-то объекты и методы (формы). Отсюда и определяется интерфейс. Если к папке нет доступа, то этой папки не будет в эксплорере. Если на объект есть доступ только для просмотра, то редактировать его не сможешь.
Объект - пользователь находится по логину. Логином является пользователь SQL Server. Посмотри как это реализовано у меня. Скачай - это бесплатно. Остальное за деньги :-)

Я очень уважаю проделанный вами объем работы ... но есть несколько но
1. Корпоративный стандарт на СУБД (в моем случае Oracle)
2. Реляционная парадигма (ИМХО) еще не исчерпала себя и хранить объектные
сущности в СУБД мне кажется несколько избыточным (для этого достаточно BusinessLayer)
3. Хоть вами и представлен достаточно большой набор возможностей, опять же ИМХО у меня есть некоторые сомнение что он покроет все мнжество задач с необходимой оптимальностью (хотя я тут могу ошибатся)

Ну и маленькая "шпилька" - к чему я затеял весь разговор...
решите опираясь на свою систему следующую задачу доступа ....

Есть юзер A
Есть таблица Б (стуктуры приведенной в редыдущих постах) и следующим содержанием

Если юзер А коннектится с уровнем Холдин_А, то ему доступны все данные нижележащих ветвей, а если с уровнем Подразделение_1, то только данные этого подразделения, при этом на уровне Холдинга интерфейс пользователя отличен от интерфейса на уровне Подразделения (но пользователь один и тот же) - а дальше уже вступает в игру роли, группы и интерфейсы доступа по данному пользователю .....

Кстати приводимые вами ссылки не единственный способ организации ядря доступа ;)
но вы все равно молодец :), перейдите на Oracle + .NET и к вам потянутся люди ;)