Реализация контроля доступа в системе

Отказ от ответственности: я работаю в Axiomatics, поставщике реализации XACML

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

Теперь, если вам нужна система авторизации, которая может обслуживать системы РСУБД и другие типы приложений (CRM, .NET, Java...), вам нужно использовать решение, которое независимо от тип приложения, которое он защищает. Это цель XACML, расширяемого языка разметки управления доступом.

XACML обеспечивает управление доступом на основе атрибутов и политик (ABAC и PBAC). Это дает вам возможность писать чрезвычайно выразительные политики авторизации и управлять ими централизованно в одном репозитории. Затем центральный механизм авторизации (называемый Policy Decision Point или PDP) будет предоставлять решения вашим различным приложениям.

Как указывает Белл, минимальный набор атрибутов, который вам понадобится, обычно включает атрибуты о пользователе (Subject), ресурсе и действии. XACML также позволяет добавлять атрибуты среды. Это означает, что вы можете написать следующий тип политики:

Врачи могут просматривать медицинские записи пациентов, которым они назначены.

• Врачи описывает пользователя/субъект
• представление описывает действие
• медицинские записи описывает целевой ресурс
• пациентов также описывает целевой ресурс. Это метаданные о ресурсе
• они назначены — интересный случай. Это атрибут, который определяет отношения между врачом и пациентом. В ABAC это реализовано как doctor.id==patient.assignedDoctorId. Это одно из ключевых преимуществ использования XACML.

Преимущества XACML включают в себя: - возможность внедрить логику авторизации, как упоминалось Беллом - возможность обновлять логику авторизации, не проходя жизненный цикл разработки/развертывания - возможность реализации мелкозернистой авторизации одинаковым образом для многих различных приложений - возможность иметь видимость и аудит логики авторизации

ХТН

Эти два понятия не являются взаимоисключающими.

Политика XACML описывает, как преобразовать набор атрибутов о предпринятом действии в решение о разрешении/запрещении. Как минимум, атрибуты будут такими: кем является пользователь (субъект), что он пытается сделать (действие) и с чем он пытается это сделать (объект). Можно добавить такую ​​информацию, как время, источник запроса и многое другое.

Атрибуты пользователя и объекта все равно придется хранить в базе данных. Если вы группируете пользователей или объекты для упрощения администрирования или упрощения определения правил управления доступом, вам придется управлять всем этим в базе данных. Затем все эти данные должны быть переданы в точку принятия решения о политике XACML, чтобы вернуть решение о разрешении/отказе.

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

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

Кстати, вы также можете хранить эти правила в базе данных. Например (вымышленный язык программирования):

жестко запрограммированный RBAC:

@xml

    role 1 editor

@/articles

ArticleController
    @GET /
    readAll () {
        if (session.notLoggedIn())
            throw 403;
        if (session.hasRole("editor"))
            return articleModel.readAll();
        else
            return articleModel.readAllByUserId(session.getUserId());
    }

не жестко запрограммированный ABAC:

@db

    role 1 editor
        policy 1 read every article
            constraints
                endpoint GET /articles
            permissions
                resource
                projections full, owner

    role 2 regular user
        policy 2 read own articles
            constraints
                endpoint GET /articles
                logged in
            permissions
                resource
                projections owner


@/articles

ArticleController
    @GET /
    readAll () {
        if (session.hasProjection(full))
            return articleModel.readAll();
        else if (session.hasProjection(owner))
            return articleModel.readAllByUserId(session.getUserId());
    }

Как вы видите, код без жесткого кода намного понятнее, чем жестко запрограммированный, из-за разделения кода.

XACML — это стандарт (который знает в 10 раз больше, чем пример выше), поэтому вам не нужно изучать новую систему контроля доступа для каждого проекта, и вам не нужно реализовывать XACML на каждом языке, потому что другие уже получилось, если повезет...