[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 28 AprIl 2022 TC meeting
Time: 5:30 PM EDT Tel: 267-807-9601 Minutes for 28 April 2022 TC Meeting I. Roll Call & Minutes Voting members Steven Legg Hal Lockhart (Co-Chair) Bill Parducci (Co-Chair) Voting Members: 3 of 3 (100%) (used for quorum calculation) Bill: we have quorum Approve Minutes of 3 March 2022 TC Meeting Approved Unanimously II. Administrivia XACML v3.0 Dynamic Attribute Authority Noted that TC Admin has published Committee Specification CS01 https://docs.oasis-open.org/xacml/xacml-3.0-dyn-attr/v1.0/cs01/xacml-3.0-dyn-attr-v1.0-cs01.html III. Issues Separation of Duty Constraints Profile Steven: I'd like to discuss pursuing a new Profile regarding Separation of Duty Constraints. I have two main concerns with the NIST RBAC standard (https://www.oit.va.gov/Services/TRM/StandardPage.aspx?tid=9530) Firstly, the SoD constraints are enforced through role assignments. The goal is to support SoD constraints in XACML, but we don't want to have to restrict ourselves to only using RBAC to give permissions to users. Secondly, the more secure Dynamic SoD requires roles to be requested and assigned within sessions. For this to work the "session" has to encompass all the potentially conflicting actions on a resource, which may extend over days or weeks, so this isn't what we normally consider to be a session. XACML is stateless and there isn't an inherent concept of a session of any sort, let alone one that persists for weeks. For SoD in XACML I propose we go back to first principles. We aren't actually interested in preventing a user having conflicting roles. Roles are a proxy for conflicting actions. What we are really interested in doing is preventing a user from performing conflicting actions. We can achieve this using Obligations and the entities profile. We can define an Obligation that requires a PEP to save a description of a permitted action performed on a resource by a user and to provide that description in every subsequent authorization request involving that resource and user. We can represent the description as an entity. At a minimum this entity would have the identifier of the resource, the identifier of the user and the identifier of the action, but other useful details can be added as additional attributes. The XACML policies would be written to test for conflicts with previously recorded actions and to emit Obligations to record new successful actions. A PEP is chosen to save the history of actions on a resource because it is generally closest to the already persistent resource. In practice we could have an intermediary between the PEP and PDP that takes care of satisfying the Obligations by persisting and appending the history so that the PEPs don't need to. Another Obligation would be defined to indicate when a sequence of potentially conflicting actions has been completed so that the history of actions can be discarded. To cover the possibility that the sequence is never completed we can define time limits in the action history entities. [General discussion] Steven: I will not be able to have a Draft by the next meeting but will begin working through this in the coming weeks. meeting adjourned. Next meeting scheduled for 23 June, 2022.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]