[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My action items (NEW VERSION, COMPLETE)
--bob
Bob Blakley
IBM Lead Security Architect
Voice: +1 (512) 838-8133
Fax: +1 (512) 838-0156
Post: 11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
Internet: blakley@us.ibm.com
---------------------- Forwarded by Bob Blakley/Austin/IBM on 02/25/99
04:48 PM ---------------------------
blakley@us.ibm.com on 02/23/99 04:12:20 PM
To: hrac-rfp@cs.fiu.edu
cc: (bcc: Bob Blakley/Austin/IBM)
Subject: My action items (incomplete)
All:
Here are some of my action items:
Provide the text discussion that HRAC is a subset of a reference monitor
(RM) and thus shouls propagate exceptions
to its clients who are the other part of the RM:
The RAD AccessDecision object sometimes passes exceptions to callers
indicating that it's encountered an internal
error and is not able to make an access decision. This is different from
the behavior of many operating systems, which
have a default-deny or a default-grant policy when an internal failure
occurs, but don't report the failure to their callers.
This difference arises because RAD is an access decision service, not an
access control service. In all cases, the
application which calls RAD is responsible for enforcing the policy
decision which RAD makes. Therefore, the RAD
client application is the right place to make the policy enforcement
decision about what should be done when RAD is not
able to make a policy decision.
Explain in the spec why you need evaluator names for DC:
DecisionCombinator objects encapsulate policy combination functions.
Functions consisting of a global combinator
operator are easy to implement; an example of such a policy is:
AND ((Evaluator_1 = GRANT), (Evaluator_2 = GRANT), ...)
This policy can be expressed as an application of a global combinator
("AND" in this case) to the results returned by
ALL the PolicyEvaluator objects passed to the DecisionCombinator.
The thing which makes this kind of policy easy to implement is that it's
not necessary to know anything about the
result returned by any specific PolicyEvaluator object, and hence the
PolicyEvaluator objects can all be treated
the same and can be called in any order.
The disadvantages of this kind of policy are:
* They aren't very expressive (there are lots of kinds of real-world
policies which can't be expressed
using only a global combinator)
* They are inefficient. It's always necessary to call all the
PolicyEvaluator objects passed to the
DecisionCombinator object in order to make a decision.
An important goal of the DecisionCombinator design is to support complex
policies which can be efficiently evaluated.
A policy like the following can't be expressed using only a global
combinator, but should be implementable as a
DecisionCombinator object:
(Evaluator_1 result is GRANT) OR
((Evaluator_2 result is GRANT) AND (Evaluator_3 result is (GRANT OR
DON'T CARE)))
Note that this policy can be short-circuit evaluated: if the
DecisionCombinator calls Evaluator_1 and it returns GRANT as a decision
result, then it doensn't need to call Evaluator_2 and Evaluator_3 at all.
However, In order to support evaluation of this policy, the
DecisionCombinator object needs to be able to match the PolicyEvaluator
objects passed to it as input to the formal parameters in this expression.
This is why the DecisionCombinator interface accepts as
input a structure containing both a reference to a PolicyEvaluator object
and the name of that PolicyEvaluator object; it uses the
PolicyEvaluator name to figure out which evaluators to call in which order;
it uses the PolicyEvaluator object's reference to call
the object and request a decision result, and then it uses the
PolicyEvaulator object's name again to plug the decision result into the
policy
combinator expression above.
Define semantics of the pattern
==================> start new stuff
Patterns are used by the PolicyEvaluatorLocator to assign PolicyEvaluator
objects to groups
of resources without requiring the PolicyEvaluatorLocator administrator to
enumerate all the
resources individually; the PolicyEvaluatorLocator does this by associating
lists of PolicyEvaluator
objects with Patterns, and checking whether a supplied resource name
matches any of the Patterns
with which it has associated PolicyEvaluators. This section describes how
PolicyEvaluatorLocator
objects decide whether a Pattern matches a resource name. Throughout the
section, we use the
shorthand phrase "exactly matches" to mean "is exactly the same string as".
Patterns have a specific format:
A Pattern must include a ResourceNamingAuthority.
A Pattern must include a list of ResourceNameComponent strings. Each
ResourceNameComponent consists
of a name_string and a value_string.
A resource name matches a Pattern only if
the resource name's ResourceNamingAuthority exactly matches the
Pattern's ResourceNamingAuthority AND
each component of the resource name matches some component of the
Pattern AND
no component of the resource name conflicts with any component of the
Pattern
Two kinds of ResourceNameComponents can occur in a pattern.
(1) The first kind is a component value pattern. It has the form
name_string is a string
value_string is a regular expression
A resource name component matches a component value pattern only if its
name_string exactly matches the
pattern's name_string and its value_string matches the component value
pattern's value_string regular expression.
A resource name component conflicts with a component value pattern if its
name_string exactly matches
the pattern's name_string, but its value_string does not match the
component value pattern's value_string
regular expression.
(2) The second kind of ResourceNameComponent which can occur in a pattern
is a component wildcard pattern:
name_string is "*"
value_string is "*"
Every component of a resource name matches a component wildcard pattern.
No component of a resource name conflicts with a component wildcard
pattern.
More formally,
Given
name : ResourceName
pattern : ResourceNamePattern
The following algorithm determines whether the name matches the pattern:
if (
name.resource_naming_authority is not the same string as
pattern.resource_naming_authority
)
// name and pattern have different authorities
OR
(
pattern.resource_name_component_list includes a component
&pattern_component AND
name.resource_name_component_list includes a component
&name_component AND
&name_component.name_string is the same string as
&pattern_component.name_string AND
&name_component.value_string does not match the regular expression
&pattern_component.value_string
)
// resource name component conflicts with a pattern component
OR
(
name.resource_name_component_list includes a component
&name_component AND
name_component.name_string is &name AND
pattern.resource_name_component_list does not include a component
<"*","*"> AND
pattern.resource_name_component_list does not include any component
whose .name_string the same string as &name
)
// resource name contains a component which does not match any
pattern component
then
name does not match pattern
else
name matches pattern
==================> end new stuff
Specify that we leave for implementors how a policy evaluator locator
combines evaluators if the resource name matches more than one pattern
If a name matches more than one pattern for which policy evaluators have
been registered with the PolicyEvaluatorLocator object, the
PolicyEvaluatorLocator will return the union (without duplicates) of the
evaluators on the lists of all matched patterns in response to a
get_policies request.
Specify how the problem of finding out what combinator should be used in
case a resource name matches more than one pattern
If a resource name matches more than one pattern registered with a
PolicyEvaluatorLocator object, and not all matched patterns specify the
same DecisionCombinator object, then the PolicyEvaluatorLocator object's
implementation will return one of the DecisionCombinator objects
specified by the matched patterns; which of the eligible DecisionCombinator
objects is returned is up to the implementor.
--bob
Bob Blakley
IBM Lead Security Architect
Voice: +1 (512) 838-8133
Fax: +1 (512) 838-0156
Post: 11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
Internet: blakley@us.ibm.com
----------------
Broadcast message to hrac-rfp from blakley@us.ibm.com.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.
----------------
Broadcast message to hrac-rfp from blakley@us.ibm.com.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.