[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 3 September 2015 TC Meeting - UPDATED
Time: 4:30 PM EST (-0400 GMT) Tel: 1-712-775-7031 Access Code: 620-103-760 Minutes for 3 September 2015 TC Meeting - UPDATED w revised comments from Bill and Martin on the XACML profiles I. Roll Call & Minutes Mohammad Jafari Steven Legg Rich Levinson Bill Parducci Co-Chair Martin Smith John Tolbert Achieved quorum yes Voting Members: 6 of 10 (60%) (used for quorum calculation) bill: we have quorum Approve Minutes 20 August 2015 (updated version): https://lists.oasis-open.org/archives/xacml/201508/msg00011.html bill: any objections to unanimous consent to approve minutes: none heard minutes approved II. Administrivia XACML v3.0 Related and Nested Entities Profile Version 1.0 (administrative changes) public review has been announced: https://lists.oasis-open.org/archives/xacml/201508/msg00008.html advisement of announcement: https://lists.oasis-open.org/archives/xacml/201508/msg00009.html bill: 30 day review; will close day of next mtg III. Issues Ideas for new XACML profiles: steven: https://lists.oasis-open.org/archives/xacml/201509/msg00000.html comments on proposed profiles: martin: https://lists.oasis-open.org/archives/xacml/201509/msg00001.html steven: items proposed he has proposed solns, and interested in dicussion 1. dynamic attr authority: role enablement it was prev proposed but removed before rbac profile submitted is this role enabled for access subject can result in many requests to find out about roles, so initial idea inefficient for something better, want to get roles that are actually enabled by the context of the current request, based on attrs would supply list of roles required, send to authority, and let role enablement authority determine which roles on the list are enabled. also want to deny roles, not the whole request inclusion and exclusion obligations boils down to send request context to dynamic attr authority, similar to advice and obligations authority existing rules like commit,deny, policy set conditions are mostly irrelevant. simpler "rule engine" for subsets of policy processing. rich: could use missing attrs capability to request role attrs steven: sounds like interesting alternative 1a. using xacml policy for notification svc similar to workflow, based on attrs, kick off workflow; can be used for other than access control martin: Why not use one of the several COTS business rules engines like Fair-Isaac's Blaze Advisor for processing business rules (vs. access-control decisions)? There are perhaps a dozen of these products; some of these use proprietary rules languages. There is also a JBoss Community open-source project called Drools that includes a rules engine and other tools. I agree that making resource access decisions is not fundamentally different from processing general business rules. steven: starting w xacml went down path of adapting to other use cases. bill: re-reading charter: using XACML to generate a non Permit|Deny decision appears to be WITHIN THE SCOPE of the charter because it is logically within the realm of access control. Just mention this because there were concerns in the past when expanded the scope of processing. We should explore in more detail. 2. redaction: specify parts of docs thru metadata tags on doc what to incl and not incl in returned results. policy would effectively tell pep what needs to be redacted bill: prev work was based email leaving premises based on labels, strings in doc that was being requested to leave premises 3. separation of duty: 2 forms based on rbac: static: if roles assigned to user conflict w roles assigned then reject dynamic: user has notional roles, subject to activate @ runtime, and potentially have conflicting roles, but if not activated then ok to activate roles: within session: user can't activate role in a session, must be done prior if active in separate sessions then things won't work; also avoid user activate/deactivate then act/de confliting role, also not allowed also need to avoid above scenario in 2 separate sessions. analysing concept of session: need to remember what roles are activated during a session. martin: Could it make sense to focus DSD controls on the scope of a business transaction rather than on a user login session? The controls could assure that the entire transaction was not completed or approved by only one person. steven: needs to remember logins martin: transaction boundaries, as opposed to login boundaries steven: issue is need to recall transaction, or more specifically on the resource you are trying to protect. i.e. don't want to hold conflicting roles when applying actions to a particular resource. steven: need to record history of actions performed on resource, simply write xacml policy that the current action doesn't conflict w past actions. entity profile would provide constraints for separation of duty info might be in audit log; important thing is when operation is requested for a resource, that the history be available to evaluate constraint on resource entity profile. attribute describes history entity as a resource; main reqt is for the pep to store the history show to use obligations to enforce the constraints steven: summary: 3 proposals: need the 1st one, others are if there is additional interest; martin: In just the last couple of months I have heard several people express interest in using ABAC to enforce DSD. I think that might be the highest-priority enhancement.among the three suggested. bill: will continue discussion on list; interesting concepts and worth following up, and others not at today's mtg may also want to provide input Trust Elevation John: posted the latest draft satisfy trust elevation use cases. https://lists.oasis-open.org/archives/xacml/201508/msg00006.html bill: called for discussion - no comments made bill: no other items requested to discuss meeting adjourned 5:17 PM EDT --
Thanks, Rich
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]