Переключиться с пользовательского ABAC на XACML

Я собираюсь защитить свое облачное приложение Spring с помощью OAuth2 и XACML (используя AuthZForce).

Я реализовал простое решение ABAC, которое может обрабатывать следующий вариант использования, но я хочу переключиться на XACML. Является ли это возможным?

старый домен

Имею (в базе):

  • политики (например, subject.id == resource.ownerId), которые проверяются точкой enfocement для принятия решения
  • разрешения (например, DELETE_USER), которые имеют определенные политики
  • роли (например, СОТРУДНИК), обладающие некоторыми разрешениями
  • функции (например, PREMIUM), которые имеют некоторые роли и разрешения, используемые по умолчанию и используемые компанией
  • компании, у которых есть особенности
  • пользователи, которые закреплены за компанией

вариант использования

Теперь пользователь из компании может создать новую роль ROLE_X. Он может назначить некоторые разрешения для этой роли.

ОБНОВЛЕНИЕ

Поскольку этот вопрос изначально содержит два разных вопроса, я решил передать второй вопрос на аутсорсинг (AuthZForce для Spring Cloud)


person benkuly    schedule 15.06.2017    source источник


Ответы (1)


Где вы храните политики, в основном не имеет значения. Это будет зависеть от используемого вами движка, например. AuthZForce (я связался с автором, чтобы он мог вмешаться), SunXACML, WSO2 или Axiomatics.

Отказ от ответственности: я работаю в Axiomatics. Мы действительно используем базу данных для хранения политик XACML, но это не меняет требований авторизации или моделирования.

У меня есть пара комментариев к твоему исходному сообщению.

  • subject.id==resource.ownerId - это то, что мы обычно называем условием в XACML. Вы сравниваете 2 атрибута вместе, чтобы реализовать связь.
  • Вы упоминаете разрешения, например DELETE_USER. В XACML вы обычно разделяете их на атомарные атрибуты, например. действие с одной стороны и объект или ресурс с другой (USER). В то время как RBAC основан на ролях и разрешениях, ABAC основан на атрибутах. В идеале эти атрибуты обозначают один аспект (пользователь, пытающийся удалить ...)
  • ROLE все еще существует в ABAC. Это будет основой вашей политики.
  • функции и компании - это атрибуты, которые вы бы использовали.

Имея это в виду, вы можете написать следующие политики (используя нотацию ALFA):

namespace axiomatics{

    namespace user{
        attribute role{
            category = subjectCat
            id = "axiomatics.user.role"
            type = string
        }
        attribute company{
            category = subjectCat
            id = "axiomatics.user.company"
            type = string
        }
        attribute userId{
            category = subjectCat
            id = "axiomatics.user.userId"
            type = string
        }
    }

    namespace action{
        attribute actionId{
            category = actionCat
            id = "axiomatics.action.actionId"
            type = string
        }        
    }

    namespace resource{
        attribute company{
            category = resourceCat
            id = "axiomatics.resource.company"
            type = string
        }
        attribute owner{
            category = resourceCat
            id = "axiomatics.resource.owner"
            type = string
        }
    }

    policyset springapp{
        apply firstApplicable
        policy employees{
            target clause user.role == "employee"
            apply firstApplicable
            /**
             * Employees can create roles in their own company
             */
             rule createRole{
                 target clause action.actionId=="create"
                 condition user.company==resource.company
                 permit
             }
             /**
              * Employees can delete roles they own
              */
            rule allowDelete{
                target clause action.actionId == "delete"
                condition user.userId == resource.owner
                permit
            }
        }
    }
}
person David Brossard    schedule 15.06.2017
comment
спасибо за развернутый ответ. Я вижу, что мое собственное решение похоже на XACML, и оно идеально, потому что миграция не будет такой сложной. Но для меня важно хранить политики в базе данных (чтобы менять их во время выполнения). Вы знаете, какие бесплатные решения или решения с открытым исходным кодом поддерживают это? - person benkuly; 15.06.2017
comment
Я предполагаю, что все движки с открытым исходным кодом могут читать политики XACML из базы данных. Попробуйте AT&T XACML, WSO2 или AuthZForce, который вы упомянули. Это один из новейших и наиболее полных в сообществе OSS. - person David Brossard; 15.06.2017
comment
Вы знаете, как или мне следует начать новый вопрос. Проблема в том, что у всех у них нет или немного документации, поэтому я не знаю, какая из них наиболее подходит для политик баз данных. - person benkuly; 16.06.2017
comment
Здравствуйте, как один из разработчиков AuthzForce, я могу помочь, но сначала мне нужно уточнить ваши требования. Насколько я понимаю, вам нужен XACML PDP, который может загружать политики XACML из базы данных для оценки. В частности, какой формат хранения политик? Любой тип данных или конкретный продукт? Чтобы лучше понять ваш вариант использования, я приглашаю вас связаться с нами в нашем списке рассылки, упомянутом в разделе поддержки на домашней странице AuthzForce. Спасибо. - person cdan; 17.06.2017
comment
Я также рекомендую вам взглянуть на Профиль XACML RBAC, чтобы получить примеры политик на основе ролей и понять, как этого добиться с помощью XACML. AuthzForce поддерживает этот профиль. - person cdan; 17.06.2017
comment
Спасибо! Поскольку ваш ответ может иметь отношение к другим людям, мы должны обсудить его здесь :) Я обновил свой вопрос. - person benkuly; 17.06.2017
comment
Какая-то опечатка в моем первом комментарии. Я имел в виду тип базы данных, а не тип данных. - person cdan; 21.06.2017
comment
Я решил передать на аутсорсинг вопрос о базе данных, связанный с AuthZForce: stackoverflow.com/q/44697729/7226417 - person benkuly; 22.06.2017