Hi!

VadimF
То есть можно воспользоваться готовой системой безопасности Cache'.
Для диплома, безусловно, можно. Но в боевой системе все не так просто.

1. Если что-то работало в предыдущей версии Cache, то оно может не заработать в следующей
или будет работать по-другому. Cache весьма быстро развивается и меняется. Для будущих
заказчиков это показатель крутизны, а для существующих - проблема. Поскольку разработчикам
и тестерам нужно забивать в план работ довольно серъезные сроки на перенос системы на другую
версию Cache. И это нередко останавливает от попыток использовать что-то готовое крайне быстро
эволюционирующее. Выше крыши хватает мелкософта, который вынуждает всех конкурентов
тратить время не на развитие прикладных систем, а на постоянный перенос их с одной версии
винды на другую.

2. На одном сервере может крутиться несколько баз с весьма разной архитектурой безопасности.
А пользователи и привилегии в Cache назначаются на сервер в целом, а не на конкретную базу с конкретным
приложением. Одно дело, когда есть DBA, который отвечает за функционирование сервера в целом,
создание бекапов и т.д., но ему нет дела до особенностей бизнес-логики конкретного приложения,
а совсем другое, когда администратор безопасности именно конкретного приложения добавляет/удаляет
пользователей, раздает доступ на ресурсы в соответствии с бизнес-логикой приложения, но ему нет
дела до технических проблем, бекапов, производительности, наличия места на дисках, знания, что
в каких таблицах находится и т.д.

И если разные приложения разработаны разными независимыми компаниями, то в целях
избежания головной боли от совместимости лучше будет ставить их на разные физические
сервера со своей Cache. Но тут уже совсем другая лицензия нужна.

3. Вопрос, тесно связанный с предыдущим пунктом, это невозможность бэкапа информации
по пользователям, их правам доступа к данным вместе с самими данными конкретной базы.
И соответственно, востановления из бэкапа так, чтобы это не повляло на пользователей,
других приложений, которые крутятся на этом сервере.

Или, к примеру, стандартная процедура апгрейда приложения. Делается бекап боевой базы с первого
сервера, восстанавливается на физически отдельном втором тестовом сервере (где может стоять другая
версия Cache), либо если боевой сервер можно остановить, то в него втыкается винчестер, туда
копируется CACHE.DAT и этот винчестер переносится на второй сервер. Понятно, что копировать
базу по сети бессмысленно. На тестовом сервере ставится новая версия приложения, проверяется
и отрабатывается процедура перехода. Затем она воспроизводится на боевом сервере (либо просто
юзеров переключают с первого сервера на второй). Вопрос: как перенести информацию о 500
пользователях, привилегиях и правах доступа с первого сервера на второй? Попытка просто
скопировать базы CACHESYS и CACHEAUDIT привела к неработоспособности второго
сервера из-за того, что он оказался в другом Windows домене. Т.е. завязка на аутентификацю
операционной системы или Kerberos - рискованная штука. Бэкап базы трехлетней давности может
запросто не подняться, если одновременно с ним не поднять бэкап на контроллере домена.

4. Если разграничение доступа является существенной частью бизнес-логики приложения, то вероятнее всего
будут и особые требования к функционалу системы безопасности. Казалось бы, вполне примитивное
требование, что рядовой пользователь, не являясь админом, должен иметь возможность поменять пароль
сам себе. В то-же время, админ не должен знать пароли пользователей и сам их менять. Разве что задавать
начальный пароль пользователю при регистрации в системе нового пользователя, но должен поставить
галочку "Требовать от пользователя смены своего пароля при первом входе в систему".
Тем не менее, мне не удалось найти такой простой возможности "в готовой" системе безопасности Cache.

То есть, если заказчик такую функцию потребует, то останется только сказать: "Обращайтесь к Интерсистемсу,
и тогда, возможно, когда-нибудь..."

А кроме такой мелочи, могут быть и более интересные вещи. У нас, к примеру иерархическая система
групп (ролей). В состав группы могут входить другие группы и пользователи, в то-же время пользователь
и группа может входить в состав нескольких групп. Кроме разрешений бывают еще и запреты. Если у группы
"А" есть разрешение на ресурс "1" и ресурс "2", а у группы "Б" есть запрет на ресурс "2" (про ресурс "1"
ничего не сказано), то пользователи, входящие только в группу "А" получат разрешение на оба ресурса,
входящие только в группу "Б" - ни на один ресурс, входящие и в группу "А" и в группу "Б" - разрешение
только на ресурс "1". Когда в системе под 500 пользователей, гибкость и удобство системы разграничения
доступа, а также пользовательский интерфейс имеют значение. Попробуйте реализовать Drag & Drop
пользователей из группы в группу на WEB - интерфейсе встроенной в Cache системы безопасности.
Вообще, перевод администрирования Cache на CSP - не самое удобное IMHO с точки зрения возможностей
пользовательского интерфейса решение. Интерфейс можно улучшить, если сделать навороченный апплет
на яве, но тогда чем он будет отличаться от старого доброго "толстого" клиента? Разве что
кроссплатформенностью.

С каждым пользователем и группой может быть ассоциирована масса информации и индивидуальных настроек
внешнего вида приложения, а не только логин или пароль. Например, рабочий телефон, e-mail, фотография
и т.д. Часть этой информации может поменять только администратор, часть - сам пользователь.

Да и создание/удаление/перемещение из группы в группу пользователя может потребовать выполнения
определенных операций. К примеру, удаление пользователя, это не DELETE FROM. Просто помечается,
что пользователь больше не может входить в систему, часть информации удаляется (например личные
почтовые ящики вместе с сообщениями), но основная идентифицирующая часть остается. Дело в том,
что ведется журнал, и может возникнуть вопрос, "кто менял этот документ три года назад" и тогда
нужно получить информацию по пользователю, даже если он пару лет назад уволился и с тех пор
доступа в систему не имеет.

Возможности перехватить операцию встроенной системы безопасности Cache по созданию/удалению/и т.д.
пользователей и выполнить какие-то собственные действия не имеется. Раньше (в Cache 5.0) было можно
перехватить логин к ODBC, выполнить собственные проверки и даже заменить имя пользователя. В частности,
это давало возможность при подключении пользователя задавать логин и пароль не тот, что указан в SQL-менеджере,
а тот, что указан в моем приложении. После проверки пароля, моя функция заменяет имя на _SYSTEM
(или любое другое) и с точки зрения Cache пользователь выглядит, как _SYSTEM и для него используются
гранты, заданные для _SYSTEM, а с точки зрения моего приложения он выглядит как мой пользователь.
То есть, можно было задействовать как встроенную систему безопасности SQL так и мою логику,
сочетая их возможности. Сейчас (Cache 5.2) возможность переопределения функции логина пропала. См. пункт 1.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73

Posted via ActualForum NNTP Server 1.4

Hi!

VadimF
В Cache' 2007.1. будет еще разграничение доступа к таблице на уровне записей.
Угу. И сильно подозреваю, что по своим возможностям не дотянет до того,
что я сделал еще 6 лет назад.

Учитывая, что логика разграничения доступа сильно зависит от специфики приложения,
а реализовать ее на триггерах - раз плюнуть. Допустим, есть у нас дерево папок. То есть
в таблице имеется поле Parent с внешним ключем родительской папки. Перенос папки
из одной родительской в другую с точки зрения сервера это UPDATE на запись
переносимой папки с изменением Parent. А вот с точки зрения юзера переносимая папка
не меняется, зато производится удаление из старой родительской и вставка в новую родительскую.
Юзер не оперирует терминами SQL - операций. Ему надо не только право на изменение
атрибутов и удаление папки, но и отдельно право на создание/удаление в ней дочерних подпапок.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73

Posted via ActualForum NNTP Server 1.4