Модернизация ограничений доступа на уровне записей в классических приложениях asp

Question

Как видно из названия, меня попросили составить оценку для модернизации существующего приложения asp.

Текущий механизм безопасности контролирует доступ к различным частям приложения (ограничения на уровне страниц), но не имеет механизма для пометки отдельных записей как ограниченных. Присвоение прав пользователю (с использованием существующего, пользовательского кода управления доступом) не является проблемой, но обеспечение соблюдения прав - это другой вопрос - на каждой странице asp есть встроенный sql - использование сохраненных процедур, объектов и т. Д. Не используется

Это единственное решение для изменения каждой таблицы и запроса, или есть лучший способ? Любые указатели, предложения или молитвы будут приветствоваться.

Это классический asp, работающий на IIS6 против базы данных Oracle.

Обновление: вот пользовательский сценарий.

У нас есть пользователи, менеджеры, директора и вице-президент. Менеджеры могут видеть данные, созданные пользователями, которые отчитываются перед ними, но не пользователи, отчитывающиеся перед другими менеджерами. Пользователи не могут видеть данные, созданные менеджерами. То же самое и с режиссерами - они могут видеть вниз, но их отчеты не видят вверх.

Answer 1

Звучит как идеальное время для обеспечения безопасности на уровне строк. Oracle имеет пакет DBMS_RLS , который позволяет вам определять произвольные политики доступа, которые можно применять к одной или нескольким таблицам, ограничивающим строки, которые может видеть конкретный пользователь. Концептуально, когда пользователь выдает запрос без фильтров для защищенной таблицы, т.е.

SELECT *
  FROM my_table

Oracle автоматически и прозрачно вставляет предложение WHERE, определенное вашей политикой безопасности, которое ограничивает набор результатов. Вам не нужно вносить какие-либо изменения в SQL, выполняемый вашим приложением.

Answer 2

Если вам нужна максимальная степень детализации, возможность «предоставить» каждую строку любому из очень многих пользователей, тогда у вас есть отношение «многие ко многим», да?

Поэтому примените следующую схему:

Добавить таблицы пользователей.

Тогда для каждой ограниченной таблицы, поэтому следующее:

• Переименуйте его в tablename + "_base".

• создать таблицу «многие ко многим», которая связывает идентификатор этой таблицы с идентификатор пользователя, называемый tablename + "Allowed_user".

• создать представление с таблицей имен имя, которое присоединяет tablename_base к table_name_allowed_user, с выберите * из таблицы name_base и user_id из tablename_allowed_user. Эта точка зрения должна соответствовать Oracle Требования должны быть по своей сути обновляемым. "

Теперь самое сложное. Вам нужно добавить «и user_id = $ user_id» к каждому запросу. Найдите различные функции, которые вы используете для выполнения запросов. Оберните эти функции в те, которые получают идентификатор пользователя из сеанса, и добавьте этот предикат.

Один из приемлемых способов сделать это - прочитать строку выбора, найти все «где» (для подзапросов может быть больше одного) и заменить ее словами «где (пользователь = $ пользователь) и». Для запросов, которые не имеют где, вам нужно вставить это перед любой «группировки по» или «упорядочить по». Это хрупко, поэтому, очевидно, вы протестируете, что это работает для всех страниц (у вас есть автоматический тест для всех страниц, верно?), И добавите хаки, чтобы покрыть особые случаи.

операторы "update" не должны будут меняться; «insert» предположительно вставит оба в представление, а затем выполнит отдельную вставку в таблицу «allow_user» таблицы с идентификатором вставляющего пользователя, чтобы автоматически предоставить вставляющему пользователю доступ к вставленному им.

Если ваше количество пользователей более ограничено или вы ограничиваете типы пользователей, вы можете использовать стратегию нескольких представлений, названную для пользователя или типа; тогда вы замените имена таблиц в запросах соответствующими представлениями.