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

Question

Я использую IS WSO2 для авторизации с помощью XACML. Я могу получить авторизацию для статического ресурса. Но я не уверен в дизайне, когда речь идет о гранулировании.

Пример: если у меня есть метод getCarDetails (Object User), где я должен получить только те автомобили, которые назначены этому конкретному пользователю, то как это сделать с помощью XACMl?

Wso2 обеспечивает поддержку PIP, где мы можем использовать пользовательские классы, которые могут извлекать данные из базы данных. Но я не уверен, что мы должны либо сделать копию исходной базы данных на стороне PDP, либо предоставить исходную базу данных PIP для обновления с помощью живых данных.

Потому что Автомобили были бы динамическими для приложения, например. в настоящее время 10 автомобилей, назначенных пользователю Алисе. вдруг супервизор добавит еще 20 автомобилей в свой список, который будет находиться в базе данных уровня приложения. Затем, как эти другие 20 автомобилей будут автоматически назначены в политике на уровне PDP, пока она также не получит эту последнюю информацию.

Возможно изменение ошибки в понимании. Но я не уверен, как справиться с этим, так как в целом мы можем иметь много такого сложного сценария, когда мы иногда получаем данные для одного пользователя из более чем 4 или 5 таблиц, а затем как обрабатывать этот сценарий?

Answer 1

Ваш вопрос замечательный, и ответ подчеркнет основные преимущества XACML и экстернализованного авторизации в целом.

В XACML вы определяете общие глобальные правила, о том, что разрешено и что не использует то, что я бы назвал высокоуровневыми атрибутами, например. атрибуты транспортного средства (в вашем случае) или пользователь (роль, отдел, ...)

Например может быть простое правило (используя синтаксис ALFA):

policy viewCars{ 
    target clause actionId=="view" and resourceType=="car" 
    apply firstApplicable 
    rule allowSameRegion{ 
     permit 
     condition user.region==car.region 
    } 
} 

Оба региона пользователя и регион автомобиля поддерживается внутри базы данных приложения. Значения считываются с использованием PIP или Информационной точки политики (подробности here).

В вашем примере вы говорите о прямом назначении, то есть пользователь был назначен непосредственно транспортному средству. В этом случае правило станет:

policy viewCars{ 
    target clause actionId=="view" and resourceType=="car" 
    apply firstApplicable 
    rule allowAssignedVehicle{ 
     permit 
     condition user.employeeId==car.assignedUser 
    } 
} 

Это означает, что информация о назначенном пользователь должен находиться где-то в базе данных приложения, в CSV-файл, веб-службы, или другой источник информации. Это означает, что с точки зрения управления администратор будет добавлять/удалять транспортные средства из списка пользователей (или, возможно, наоборот: добавлять/удалять назначенных пользователей из списка назначенных пользователей транспортного средства).

Само правило XACML не изменится. Если супервизор добавит еще 20 машин в список сотрудников (поддерживается в базе данных уровня приложения), тогда PDP сможет использовать эту информацию через PIP, и доступ будет предоставлен или отклонен соответствующим образом.

Ключевым преимуществом XACML является то, что вы можете добавить второе правило, согласно которому диспетчер может видеть автомобили, которым он назначен (нормальное правило), а также автомобили, назначенные его подчиненным (a новое правило прокси-делегата).

Эта схема, взятая из блога аксиоматики, суммирует поток XACML:

НТН, дайте мне знать, если у вас есть дополнительные вопросы. Вы можете download ALFA here, и вы можете watch tutorials here.