Добрый вечер всем
Вопрос: существуют ли в природе "библиотеки" — управляющие ролевой безопасностью с уровнем доступа до объектов?
Возможны коммерческие реализации.
Очень надо — спасибо.
... << RSDN@Home 1.1.3 stable >>
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, NetStyler, Вы писали:
NS>Добрый вечер всем NS> NS>Вопрос: существуют ли в природе "библиотеки" — управляющие ролевой безопасностью с уровнем доступа до объектов? NS>Возможны коммерческие реализации. NS>Очень надо — спасибо.
Здравствуйте, NetStyler, Вы писали:
NS>Вопрос: существуют ли в природе "библиотеки" — управляющие ролевой безопасностью с уровнем доступа до объектов? NS>Возможны коммерческие реализации.
Возможно, подойдет Force-Field. Есть роли, классы доступа к объектам (набор правил), иерархия объектов с наследованием ролей, назначенных на более высоком уровне. Есть также наследование правил (по желанию создателя класса безопасности).
Здравствуйте, Dronopotamus, Вы писали:
D>посмотри на AzMan из Windows 2003 Security ToolKit (если ещё не видел, конечно ) D>Он + MS Authorization and Profile Application Block — помоему хватит
Так все хорошо — только мне нужна -Winda- независимая
... << RSDN@Home 1.1.3 stable >>
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, Dronopotamus, Вы писали:
D>посмотри на AzMan из Windows 2003 Security ToolKit (если ещё не видел, конечно ) D>Он + MS Authorization and Profile Application Block — помоему хватит
AzMan по своей сути весьма на FF похож (MS — паразит — так на пятки и наступает ), но там нет иерархии объектов и, соответственно, назначения ролей в контексте объекта. Все роли там назначаются либо на глобальном уровне, либо для целого приложения, либо для некоего диапазона внутри приложения. При этом, диапазон выделяется на основе функциональных модулей приложения, а не на основе данных с которым оно работает.
Например, мы разрабатываем какую-нибудь систему управления проектами. Там есть проектs, задачи в них, подзадачи в задачах. В ФФ некий юзер может быть менеджером проекта А (и всех его задач и подзадач), но не быть менеджером проекта В. С azman'ом это, если и можно сделать, то каким-то достаточно "изогнутым" способом.
Здравствуйте, NetStyler, Вы писали:
NS>Мда — штука хорошая. Но таких денег не стоит
Почему не стоит? А вот посчитай, сколько времени уйдет у твоего программиста написать такую библиотеку, и сколько ему за это время нужно будет заплатить зарплаты. Пусть, даже, идеология продукта совершенно ясна и думать над ней не нужно (хотя мы развивали идеологию ФФ 3 года, применяя его к разрабатываемым проектам). ИМХО, получится больше.
Впрочем, это все наши представления о правильном. Каково твое видение приемлимой стоимости?
Здравствуйте, Андрей Майоров, Вы писали:
АМ> Например, мы разрабатываем какую-нибудь систему управления проектами. Там есть проектs, задачи в них, подзадачи в задачах. В ФФ некий юзер может быть менеджером проекта А (и всех его задач и подзадач), но не быть менеджером проекта В. С azman'ом это, если и можно сделать, то каким-то достаточно "изогнутым" способом.
почему изогнутым? в AzMan есть возможность определить набор бизнес правил на осонове которых будет определяться принадлежность к тому или иному объекту.
Так-же, кроме AzMan — есть еще и ADAM можно хранить объкты и назначение прав для них в директории.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
АМ> Впрочем, это все наши представления о правильном. Каково твое видение приемлимой стоимости?
Приемлимая стоимость продукта <= стоимость от (скачать триал и поломать)
PS А стоимость FF имхо, вполне божеская — просто не привыкли мы к платному софту — надо тренироваться — почаще покупать лицензии на Rational/PowerDesigner за 3/5 килогрина
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Андрей Майоров, Вы писали:
TK>почему изогнутым? в AzMan есть возможность определить набор бизнес правил на осонове которых будет определяться принадлежность к тому или иному объекту.
Насколько я понял, там есть две возможности: а) указать декларативно, что некоторая операция разрешена/запрещена определенной роли/пользователю; б) написать скрипт, который будет производить проверку.
Гибкость декларативного способа ограничена размером минимальной области, в которой можно назначать роли пользователей. В AzMan'е такая минимальная область — scope (пусть будет "диапазон"). Диапазоны нужно а) явным образом создавать, б) уникально именовать, в) добавлять в них пользователей и роли. Ко всему тому, дипазоны совершенно независимы, какой-либо иерархии у них нет. Так что нам было бы довольно проблематично сделать по отдельному диапазону на каждый проект нашего гипотетического приложения.
Наличие скриптов, конечно, позволяет реализовать практически любое правило проверки, но это же требует дополнительной программерской работы. Администратор с этим уже вряд ли справится.
В нашей же схеме, роли пользователю назначаются в контексте любого объекта иерархии, после чего пользователь начинает играть эту роль во всех подчиенных объектах. Естественно, что в этом случае одна и та же схема доступа может выдавать разный результат в разных ветках иерархии.
TK>Так-же, кроме AzMan — есть еще и ADAM можно хранить объкты и назначение прав для них в директории.
Это, надо сказать, уж больно необычно (или непривычно). Ты предлагаешь хранить там и объекты, и данные, или только дерево объектов, а за данными лазить в базу?
Здравствуйте, Андрей Майоров, Вы писали:
АМ> Наличие скриптов, конечно, позволяет реализовать практически любое правило проверки, но это же требует дополнительной программерской работы. Администратор с этим уже вряд ли справится.
Администратору с этим справляться совершенно не обязательно, скрипты может писать разработчик, а администратору останется работа по распределению пользователей по ролям.
АМ> В нашей же схеме, роли пользователю назначаются в контексте любого объекта иерархии, после чего пользователь начинает играть эту роль во всех подчиенных объектах. Естественно, что в этом случае одна и та же схема доступа может выдавать разный результат в разных ветках иерархии.
TK>>Так-же, кроме AzMan — есть еще и ADAM можно хранить объкты и назначение прав для них в директории.
АМ> Это, надо сказать, уж больно необычно (или непривычно). Ты предлагаешь хранить там и объекты, и данные, или только дерево объектов, а за данными лазить в базу?
Все зависит от того, какие данные должны хратится. Если это телефоны, небольшие текстовые строки, то можно разместить их в AD, а если это это кино на пару часов, то стоит поискать другое хранилище. В любом случае — для распределения прав доступа к объектам (включая наследование прав и т.п.) adam подходит достаточно не плохо...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Администратору с этим справляться совершенно не обязательно, скрипты может писать разработчик, а администратору останется работа по распределению пользователей по ролям.
Вот в том и дело, что он не может, например, назначить пользователя на роль менеджера проекта №517. Либо менеджер проектов в глобальном смысле, либо не менеджер. А все более сложные варианты требуют написания скриптов. Так что, если мы захотим, чтобы проектами могли управлять еще некие "супервизоры", то нам придется править скрипт, вместо того, чтобы добавить одну строку в правила доступа.
АМ>> Это, надо сказать, уж больно необычно (или непривычно). Ты предлагаешь хранить там и объекты, и данные, или только дерево объектов, а за данными лазить в базу?
TK>Все зависит от того, какие данные должны хратится. Если это телефоны, небольшие текстовые строки, то можно разместить их в AD, а если это это кино на пару часов, то стоит поискать другое хранилище. В любом случае — для распределения прав доступа к объектам (включая наследование прав и т.п.) adam подходит достаточно не плохо...
Я подразумеваю, что речь идет о достаточно больших объемах данных. Не кино, конечно, но и не карточка пользователя. Нечто, что разработчики привыкли хранить в реляционных базах. Например, какие-нибудь гипертекстовые документы (вебовая тематика ). Если мы будем в АД хранить дескрипторы объектов, то столкнемся с проблемами синхронизации двух хранилищ. Ну и производительность подсядет — всегда делать две операции вместо одной.
Здравствуйте, Андрей Майоров, Вы писали:
TK>>Так-же, кроме AzMan — есть еще и ADAM можно хранить объкты и назначение прав для них в директории.
АМ> Это, надо сказать, уж больно необычно (или непривычно). Ты предлагаешь хранить там и объекты, и данные, или только дерево объектов, а за данными лазить в базу?
А чего здесь необычного? Яркий пример такой системы — Microsoft Exchange Server. Метаданные пользователей и их почтовых ящиков он хранит в Active Directory, а весь остальной контент в собственном хранилище.
Здравствуйте, Alex Axyonov, Вы писали:
AA>А чего здесь необычного? Яркий пример такой системы — Microsoft Exchange Server. Метаданные пользователей и их почтовых ящиков он хранит в Active Directory, а весь остальной контент в собственном хранилище.
Microsoft вряд ли может расцениваться, как типичная компания-разработчик. Вполне возможно, что Exchange — это единственный продукт в мире, который так делает.
Насколько я слышал, Exchange весьма и весьма требователен к ресурсам. Не является ли использование AD одной из причин этого? Да и деплоймент такого решения достаточно сложен. Не говоря уж о выкатывании обновленных версий софта. Хотя, вот может, ADAM в этом смысле удобнее самого AD. Не знаю.
Здравствуйте, Андрей Майоров, Вы писали:
АМ> Впрочем, это все наши представления о правильном. Каково твое видение приемлимой стоимости?
Меня лично не цена смущает. А таблица сведения прав на объекты.
Ну к римеру у меня в базе хронится 80т таблиц. Каждая строка в таблице объект. Права надо раздавать на кажудую. В каждой таблице по 2-3ри милиона записей. Посчитайте пожалуйста объем таблицы связки!!! Там селект будет минут 10ть выполнятся!
Если бы он для каждого объекта отдельную таблицу создавал ... а инфу об экземплярах туда писал. Тады можно было бы объем размазать. Или я что-то не так понял...
... << RSDN@Home 1.1.3 stable >>
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, Андрей Майоров, Вы писали:
АМ> Microsoft вряд ли может расцениваться, как типичная компания-разработчик. Вполне возможно, что Exchange — это единственный продукт в мире, который так делает.
Все может быть.
АМ> Насколько я слышал, Exchange весьма и весьма требователен к ресурсам. Не является ли использование AD одной из причин этого?
AD не является причиной требовательности к ресурсам. Носителем AD является контроллер домена, который может быть физически отделен от сервера Exchnage. АМ>Да и деплоймент такого решения достаточно сложен. Не говоря уж о выкатывании обновленных версий софта. Хотя, вот может, ADAM в этом смысле удобнее самого AD. Не знаю.
Деплоймент такого решения действительно сложен да и порой рискован. Без ADAM в случае некорректной работы с корпоративной базой AD существует возможность нарушить работу всей инфраструктуры предприятия. Теперь же для этого выделяется изолированное хранилище средствами ADAM.
Здравствуйте, NetStyler, Вы писали:
NS>Ну к римеру у меня в базе хронится 80т таблиц. Каждая строка в таблице объект. Права надо раздавать на кажудую. В каждой таблице по 2-3ри милиона записей. Посчитайте пожалуйста объем таблицы связки!!! Там селект будет минут 10ть выполнятся!
Да, объемы очень внушительные. Хотел бы я сказать, что все будет работать без проблем, но язык не поворачивается. В принципе, специальную таблицу для связки делать совершенно не обязательно. Можно сделать индексированную вьюху. Но вот как эта вьъюха будет работать при таких объемах — загадка сия велика есть. Надо пробовать. Есть ненулевая вероятность, что скорость будет приемлимой.
С другой стороны, там есть еще две таблицы для кэширования результатов проверки. Вот они могут разрастись до достаточно нездешних объемов.
NS>Если бы он для каждого объекта отдельную таблицу создавал ... а инфу об экземплярах туда писал. Тады можно было бы объем размазать. Или я что-то не так понял...
Может и не так, сейчас как узнаешь? Попробую вкратце перечислить основные моменты:
1. FF работает с единой иерархией объектов. Все объекты "растут" от одного корня. Очевидно, что для этого у объектов должна быть какая-то сквозная нумерация.
2. Сам по себе FF объекты не создает и не модифицирует. Его нужно "подшивать" к имеющимся таблицам проблемной области при помощи FF_Object.
3. От записей в FF_Object'е форсфилду нужно: идентификатор родительского объекта, класс доступа до объекта и владелец объекта (если он имеется).
4. FF_Object может быть либо таблицей, и тогда вам придется позаботиться о поддержке этой таблицы в актуальном состоянии, либо view, которая сводит воедино все таблицы проблемной области, на которых нужно будет осуществлять проверки.
Вот и получается, что можно создать отдельную таблицу для каждого типа объектов, но придется как-то позаботиться о том, чтобы FF мог получить нужные данные по идентификатору объекта. Как объяснить ему, в какую таблицу лезть, пока непонятно. Можно, конечно, свести все эти таблицы в единый вью FF_Object, но получим ли мы какой-нибудь выигрышь в скорости от такого финта ушами? Сомнительно.
Может быть, можно более подробно описать задачу? Хотя бы часть. Какие есть типы объектов, какую иерархию из них нужно сделать, какие проверки?
)
