[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Quality of Service (aka Parameterized Decisions) Use Blurb
Having been remiss in putting forth a structured Use Case around the concept of using XACML to provide qualified/paramterized decisions I present the following Use Blurb to initiate discussion. Most of these scenarios are variations on a common theme but i wanted to toss them out there in the spirit of driving towards a generalized solution. Please note that in all instances, this topic assumes that a PEP is itself, or is part of a logical unit that is, capable of providing more than binary access control (it will make better sense--i hope--after reading the following). I believe that in a real world scenario such an assumption is practical as it is not uncommon to see an access control system span environments which provide tiered resources. Anyway, the goal of this note is to toss out the concepts to see if they resonate with the TC (some of these are half-baked ;o) Scenario 1a: static QoS, resource identity subject: Bill action: read (get) resource: www.foo.bar * www.foo.bar is a represented by a PEP that fronts two physical devices: 'weakling' and 'herc'. * weakling is in some way inferior to herc (be it type/breadth of information available, physical performance, etc.) * policyWriter wishes to provide access (route) to herc for those Subjects that are a member of the 'paid' group/role. Scenario 1b: dynamic QoS, environmental subject: Bill action: read (get) resource: www.foo.bar * www.foo.bar is a represented by a PEP that fronts two physical devices: 'itchy' and 'scratchy'. * itchy and scratchy are identical servers that are provide the same functionality * policyWriter wishes to provide access (route) to itchy or scratchy depending on which responds first to a whoIsFree test. The dilemma in Scenarios in 1a-b is that a binary decision cannot provide sufficient information to answer the access request questions, e.g. "Can Bill access www.foo.bar?" because there may be multiple answers ("Yes, grant him access to herc," or, "Yes grant him access to weakling.") The reason that there is a many-to-one ratio of requestedResources to physicalResources is that it is impractical to require the PEP to query all possible resourceInstances for access. additionally, the Subject may have access to both systems but the *preferred*/priority is given to the "better" system unless it unavailable (which introduces another concept "fall back decisions", but that is a note on a different day since it would only make sense IF parameterized decisions were possible ;o) At first blush, providing a function to determine which device is better suited to answer the call could address 1a and 1c , but but then the list of potential devices would have to be defined outside of the policy (likely in some sort of file associated with the function) and that is architecturally a Bad Idea because it would place information directly impacting the access control decision outside of the policy. Scenario 2: temporal access subject: Bill action: read (get) resource: discoFever.mp3 * discoFever.mp3 is a streamed file * policyWriter wishes to provide access to discoFever.mp3 for only 15 seconds unless the Subject is a member of the group/role "subscriber". To resolve this scenario with a binary answer it would be necessary make repeated requests to determine if the stream is still allowed ("Is it still OK to allow it through?" "Is it still OK?"...) One could argue that the above scenarios could be handled with Obligations, however Obligations have been defined and things the PEP should attempt as part of a "Best Effort" action, but that are not tied directly to the access itself (e.g "Log event" has nothing to do with the act of granting access) and further may therefore extend well beyond the lifetime of the access event itself ("Notify admin via e-mail" may occur much later than the PEP's actions and does not affect the enforcement). As an aside, this is why I think something like "Encrypt" isn't an Obligation as much as it is an paramter: it is directly affects the the decision and is only relevant during the enformcement period. Scenario 3: static QoS, resource modification (content filtering) subject: Bill action: read resource: patientRecord.xml * patientRecord.xml is a file that contains all sorts of information about Bill. * policyWriter wishes Bill to only see a subset of patientRecord Ok, right have the bat I have to admit i am a bit wobbly on this one. In the pre-Hierarchical Resource Profile days my thinking was that this would be something like request --> decision + filter. in the case of an XML document it might be a style sheet of even an aggregated list of Permit/Deny answers that address each element specifically in the instance requested. Having gone around in circles with the HR discussions I will need to regain my bearings but I wanted to toss it out there as a mental placeholder if nothing else. (Other examples included "black lining" sensitive or inappropriate information from email, web pages, etc. dynamically...it just gets kookier from there ;o) Anyway, I think there are a couple shiny objects in the overall concept and I just need to have it hammered on a bit to see if they won't drop out. Fire away... b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]