Quality of Service (aka Parameterized Decisions) Use Blurb

[Bill Parducci <bparducci@gluecode.com>]

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