Отношения 1:n и сложные типы атрибутов в ALFA

Я пытаюсь ввести нашу модель базы данных в ALFA, чтобы проверить возможности ALFA и XACML.

Возможны ли атрибуты, подобные следующим? Как тогда будут выглядеть правила?

1:n по списку строк

namespace com.mycompany {
   namespace resources {
       namespace patient {
                attribute trustedDoctorIds{
                    category = resourceCat
                    id = "trustedDoctorIds"
                    type = list<string> //maybe it should be bag[string]
                }                
       }
   }
}

1:n по списку сложного типа

namespace com.mycompany {
   namespace resources {
       namespace patient {
                attribute trustedDoctors{
                    category = resourceCat
                    id = "trustedDoctors"
                    type = list<doctor> //maybe it should be bag[doctor]
                } 
       }
   }

   namespace subjects {
      namespace doctor {
          attribute id {
                    category = subjectCat
                    id = "id"
                    type = string
          }
          attribute lastname {
                    category = subjectCat
                    id = "lastname"
                    type = string
          }
      }
   }
}

abac xacml alfa
person OneWorld    schedule 23.05.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

У вас есть отличный вопрос.

По умолчанию все атрибуты в ALFA и XACML являются многозначными. Атрибуты представляют собой наборы значений, а не отдельные значения. Это означает, что когда вы определяете следующее,

            attribute trustedDoctorIds{
                category = resourceCat
                id = "trustedDoctorIds"
                type = string
            }

Это означает, что атрибут имеет тип строки и может быть многозначным. Вы можете выразить информацию о числе элементов в комментариях над определением атрибута, например.

/**
 * This attribute, trustedDoctorIds, contains the list of doctors a patient 
 *trusts. The list can have 0 or more values.
 */

Политика — это та, которая будет передавать, сколько значений может быть в зависимости от используемых функций.

Например, вы можете написать условие, которое гласит

stringOneAndOnly(trustedDoctorIds)==stringOneAndOnly(userId)

В этом случае вы заставляете каждый атрибут иметь одно значение и только одно значение. Если у вас есть 0 или более 1 значения, то оценка политики XACML даст Indeterminate.

В цели XACML (или ALFA), когда вы пишете:

trustedDoctorIds == "Joe"

Вы говорите: если есть хотя бы одно значение в trustDoctorIds, равное "Джо"...

В состоянии АЛЬФА, когда вы пишете

trustedDoctorIds==userId

Вы говорите: *если хотя бы одно значение в trustedDoctorIds равно хотя бы одному значению в userId

Примечание. Я всегда использую имена в единственном числе для своих атрибутов, когда это возможно. Это условность, а не жесткое ограничение. Запоминание кардинальности ваших атрибутов поможет позже при тестировании политики.

Ответы на комментарии

Какое имя во множественном числе вы стараетесь избегать по вашему соглашению?

Ну, trustDoctorId***s*** выглядит для меня скорее во множественном числе. Я бы использовал trustedDoctorId, если только вы не знаете, что атрибут обязательно всегда многозначен.

Итак, это должно быть возможно: в моем запросе я предоставляю resource.patient.trustedDoctorIds=="2,13,67" и subject.doctor.id=="6". Как тогда будет выглядеть правило в ALFA? что-л. например, «resource.patient.trustedDoctorIds.contains (subject.doctor.id) разрешение»

Правило будет выглядеть следующим образом:

stringIsIn(stringOneAndOnly(subject.doctor.id),resource.patient.trustedDoctorIds)

Убедитесь, что вы предоставляете несколько значений в своем запросе, а не одно значение, содержащее значения, разделенные запятыми. Отправьте [1,2,3], а не "1,2,3".

Дальнейшие правки

Таким образом, по [2,13,67] результатом будет отказ, как и ожидалось, а не разрешение, как с "2,13,67" и doctorId==6. Я специально выбрал этот пример, так как функция stringIsIn нежелательно привела бы к значению true, поскольку 6 включено в 67.

Не путайте stringIsIn() и stringContains().

  • stringIsIn(a, b) принимает 2 параметра a и b, где a — атомарное значение, а b — набор значений. stringIsIn(a, b) возвращает true, если значение a находится в наборе значений b.
  • stringContains(a, b) принимает 2 параметра a и b, которые являются атомарными значениями строкового типа. Он возвращает true, если строковое значение a находится внутри b.
Example:
  • stringIsIn(stringOneAndOnly(userCitizenship), stringBag("Swedish", "German")) возвращает значение true, если пользователь имеет единственное гражданство, равное шведскому или немецкому.
  • stringContains("a", "alfa") возвращает true, если вторая строка содержит первую. Таким образом, в этом примере он возвращает true.
person David Brossard    schedule 23.05.2018
comment
Какое имя во множественном числе вы стараетесь избегать по вашему соглашению? - person OneWorld; 23.05.2018
comment
Итак, это должно быть возможно: в моем запросе я предоставляю resource.patient.trustedDoctorIds==2,13,67 и subject.doctor.id==6. Как тогда будет выглядеть правило в ALFA? что-л. например, разрешение resource.patient.trustedDoctorIds.contains(subject.doctor.id) - person OneWorld; 23.05.2018
comment
Таким образом, по [2,13,67] результатом является отказ, как и ожидалось, и не разрешение, как с 2,13,67 и doctorId==6. Я специально выбрал этот пример, так как функция stringIsIn нежелательно привела бы к значению true, поскольку 6 включено в 67. - person OneWorld; 23.05.2018
comment
Я предполагаю, что мой второй пример 1: n по списку сложного типа не поддерживается - person OneWorld; 23.05.2018
comment
Спасибо за рекомендацию блога. Я знаю один и ваши уроки на YouTube, которые я уже использовал. Теперь я задаю вопросы, на которые мне еще не ответили, чтобы получить полную картину. SO лучше всего подходит для этого формата вопросов и ответов. - person OneWorld; 24.05.2018
comment
Не путайте stringIsIn и stringContains. Я добавил часть об этом в ответ. - person David Brossard; 24.05.2018
comment
Кстати, какой PDP вы используете? Это для FHIR? - person David Brossard; 24.05.2018
comment
До сих пор я оценивал AuthZForce. Это форк SunXACML, и проект выглядит вполне здоровым. AT&T также находится в моем списке (хотелось бы знать, является ли это ответвлением чего-либо еще). Обязательно рассмотрю FHIR PDP, хотя прием FHIR все еще низок. Спасибо! - person OneWorld; 24.05.2018
comment
AuthZForce — хороший вариант. Один из их создателей (@cdan) активен на SO. Если вам нужна реклама, вы знаете, где меня найти :-) - person David Brossard; 24.05.2018
comment
AT&T, я думаю, построена с нуля. Они использовали многие идеи, которые мы разработали в Axiomatics. - person David Brossard; 24.05.2018