0

Я в настоящее время пытаюсь разработать Authorization модель, которая имеет следующие компоненты:Модель авторизации: контекст роли?

привилегии - действие, которое может быть либо разрешено или запрещены к пользователю/группе

Роли - это совокупность привилегий; Роли могут быть связаны с пользователем или группой

Объекты безопасности - объект, к которому безопасность применяется

Владельцы объектов - владелец объекта безопасности

Статусы - это атрибут, который представляет собой состояние объект безопасности

Пользователи - стандартный потребитель услуги; может быть отказано или предоставлен доступ к вещам

Группы - это набор пользователей, имеющих общую общую информацию; роли могут быть назначены группам; привилегии могут быть назначены группам

Мои вопросы таковы: существует ли способ правильно смоделировать контекст роли с текущими компонентами, которые я представил выше?

Например, предположим, что у меня есть текущее утверждение авторизации:

Tim can see Mary's profile information because Tim is Mary's friend. 

Я препарировать это утверждение в модели компонентов:

User: Tim 
Security Object: profile information 
Object Owner: Mary 
Privilege: view 
Role: friend 
Group: N/A? 
Status: N/A 

Одно дело, что это рассечение не атрибут является то, что Tim является другом of Mary

Есть ли компонент, который я могу добавить к этой модели, что wi ll захватить этот контекст («от Мэри»), или есть способ, которым я могу повторно представить заявление о привилегиях, используя мои ранее существовавшие компоненты модели auth? Какова наилучшая практика?

ответ

2

На самом деле, вы не должны пытаться внедрить новую модель авторизации. Уже существует хорошая модель, называемая управлением доступом на основе атрибутов (или ABAC - см. Тег SO и ).

ДКС является модель авторизации, что:

  • определяется NIST, Национальный институт стандартов и технологий, та же самая организация, которая определяет RBAC (ролевое управление доступом)
  • использует атрибуты определить логику управления доступом. Атрибуты
    • представляют собой пару с ключом, например. role == manager
    • может быть многозначным, например. гражданство = канадский, шведский
    • может описывать что угодно, например. запрашивающий пользователь, целевой объект, действие, отношения, время, местоположение ...
  • использует политики для определения логики управления доступом.Эти политики
    • написаны в XACML ()
    • Использование атрибутов для определения сферы контроля и управления доступом
  • дает экстернализованной разрешение: по существу, логика авторизации отделена от бизнес-логики. Это здорово, потому что вы можете разрабатывать свои приложения независимо от вашей безопасности.

Давайте возьмем ваш пример:

Тим может видеть информацию о профиле Марии, потому что Тим друг Мэри. Поэтому

Требование авторизации будет:

A user can view another user's profile if both users are friends. 

В ДКС, вы должны определить свои атрибуты. Вы делаете это в своем вопросе, который велик, хотя ваш анализ является предвзятым. Давайте возьмем его снова. Атрибуты, которые я вижу, являются:

  • идентификатор действия (вид)
  • типа ресурса (профиль пользователя)
  • списка друга (список друзей Тима)
  • владелец профиля (Mary)

с помощью этих атрибутов, я могу переписать ваше требование в разбитом виде:

A user can do the action actionId==view on a resource of type==user profile if profile.owner is in the user's friend list. 

Вы можете использовать ALFA () для реализации политики в ALFA, а затем XACML.

namespace com.axiomatics{ 
    /** 
    * A user can view another user's profile... 
    */ 
    policy viewProfile{ 
     target clause actionId=="view" and resourceType=="user profile" 
     apply firstApplicable 
     /** 
     * Allow if both users are friends. 
     */ 
     rule allowIfFriends{ 
      condition stringIsIn(stringOneAndOnly(subjectId), friendList) 
      permit 
     } 
    } 
} 

XACML результат (в формате XML) является:

<?xml version="1.0" encoding="UTF-8"?> 
<!--This file was generated by the ALFA Plugin for Eclipse from Axiomatics AB (http://www.axiomatics.com). 
Any modification to this file will be lost upon recompilation of the source ALFA file--> 
<xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" 
    PolicyId="http://axiomatics.com/alfa/identifier/com.axiomatics.viewProfile" 
    RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" 
    Version="1.0"> 
    <xacml3:Description>A user can view another user's profile...</xacml3:Description> 
    <xacml3:PolicyDefaults> 
     <xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</xacml3:XPathVersion> 
    </xacml3:PolicyDefaults> 
    <xacml3:Target> 
     <xacml3:AnyOf> 
      <xacml3:AllOf> 
       <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> 
        <xacml3:AttributeValue 
         DataType="http://www.w3.org/2001/XMLSchema#string">view</xacml3:AttributeValue> 
        <xacml3:AttributeDesignator 
         AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" 
         DataType="http://www.w3.org/2001/XMLSchema#string" 
         Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" 
         MustBePresent="false" 
        /> 
       </xacml3:Match> 
       <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> 
        <xacml3:AttributeValue 
         DataType="http://www.w3.org/2001/XMLSchema#string">user profile</xacml3:AttributeValue> 
        <xacml3:AttributeDesignator 
         AttributeId="resourceType" 
         DataType="http://www.w3.org/2001/XMLSchema#string" 
         Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 
         MustBePresent="false" 
        /> 
       </xacml3:Match> 
      </xacml3:AllOf> 
     </xacml3:AnyOf> 
    </xacml3:Target> 
    <xacml3:Rule 
      Effect="Permit" 
      RuleId="http://axiomatics.com/alfa/identifier/com.axiomatics.viewProfile.allowIfFriends"> 
     <xacml3:Description>Allow if both users are friends.</xacml3:Description> 
     <xacml3:Target /> 
     <xacml3:Condition> 
      <xacml3:Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in" > 
       <xacml3:Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only" > 
        <xacml3:AttributeDesignator 
         AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" 
         DataType="http://www.w3.org/2001/XMLSchema#string" 
         Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" 
         MustBePresent="false" 
        /> 
       </xacml3:Apply> 
       <xacml3:AttributeDesignator 
        AttributeId="friendList" 
        DataType="http://www.w3.org/2001/XMLSchema#string" 
        Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" 
        MustBePresent="false" 
       /> 
      </xacml3:Apply> 
     </xacml3:Condition> 
    </xacml3:Rule> 
</xacml3:Policy> 
+1

это интересный подход, который я не учел. Спасибо, что поделились этим со мной. В связи с этой моделью я нашел статью о другой модели, которая также может удовлетворить мои требования. Это называется ReBAC (Управление доступом на основе отношений) http://pages.cpsc.ucalgary.ca/~pwlfong/Pub/codaspy2011.pdf Теперь это просто вопрос для моих целей, если ABAC или ReBAC будут работать лучше для моего приложения. Еще раз спасибо. – Mackers

Смежные вопросы