Issues for Resource Access Decision FTF discussion mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3178: RAD FTF Issues document
Issue 3211: RAD idl problems
Issue 3253: Number of security policies supporteb by PolicyEvaluator arbitrarily large
Issue 3254: Invalid IDL
Issue 3255: Use of names in defined exceptions
Issue 3256: The exception InputFormatError is only raises by one operation
Issue 3257: DynamicAttributeService issue
Issue 5435: The following operations in the EntityFactory Interface need adjustments

Issue 3178: RAD FTF Issues document (rad-ftf)

Due to very scetchy issue descriptions the document will be handled as 1 issue. The complete doc can be found in the issues archive

Sub-Issue No: 3178A
It isn't clear what the notation in these two diagrams is. They don't seem to be
officially any of the standard UML diagrams.
Clarification:
This comment is in reference to the text in the Access Decision Model, which
can be found in section 1.2.1 of the draft Adopted Specification, page 1-4.
Resolution:
Reject. No change. The diagram was not intended to be UML. It is illustrative;
the specification is fully defined in the text.
Revised Text: None.
Sub-Issue No: 3178B
Why is this discussion under the administrative model rather than the access
decision model?
Clarification:
This comment is found at the end of the following sentence: "This combinator
is responsible for taking the results of the PolicyEvaluators
evaluate() method and making a final access decision" This can be located in section 1.2.2 Administrative Model, on page 1-5 of the draft
Adopted Specification (3rd paragraph).
Resolution:
Move the sentence "This combinator is responsible for taking the results of
the PolicyEvaluators evaluate() method and making a final access
decision" from section 1.2.2 to section 1.2.1 as the last sentence in the
section.
Revised Text: see resolution description.
Sub-Issue No: 3178C
Why is NamedPolicyEvaluator not an interface that subtypes
PolicyEvaluator? Why is it done this way, i.e. by containment rather than
by subtyping? Is there a need to have the ability to provide the same
PolicyEvaluator instance a different name in different contexts?
Clarification:
Comment is referring to the struct NamedPolicyEvaluator in the
"Types associated with evaluating Access Policy." This can be found in
section 2.2.3, page 2-6 of the draft Adopted Specification.
Resolution:
Reject. No change.
Revised Text: None
Sub-Issue No: 3178E, F, and G1
Sub-Issue 3178E [FTF] Grammar
Sub-Issue 3178F [Errata] Instead of "in the invalid list" shouldn’t this be "in the
PolicyNameList"
Issue 3178G1 states: Same comment as #35 above (3178F).
Clarification:Clarification (3178E). This is in reference to the following sentence under
InvalidPolicyEvaluatorList: "first_invalid_element is first
named policy evaluator in the invalid list which caused the list to be invalid."
This can be found in section 2.2.5 Exceptions, page 2-11 of the draft Adopted
Specification.
Clarification (3178F) and references the same sentence in 3178E.
Clarification (3178G1). KB replied with the same comment as
above.
Resolution:
Proposed resolution to all: change referenced statement to read
"first_invalid_element is the first named policy evaluator in the
PolicyNameList which caused the list to be invalid."
Revised Text: see resolution description.
Sub-Issue No: 3178EE
Grammar
Clarification:
This comment refers to the following sentence found under
InvalidPolicyEvaluatorList: "This exception is raised when a policy
evaluator list, passed as a part of an operation arguments.” This can be found
in section 2.2.5 Exceptions, page 2-11.
Resolution:
Change sentence to read: "This exception is raised when a
PolicyEvaluatorList contains invalid elements".
Revised Text: see resolution description.
Sub-Issue No: 3178G2 Grammar
Clarification:
This comment is in reference to the following sentence found under
postconditions of multiple_access_allowed(): "Where an
authorization decision ==authorization decision for the requested operation on
the specified resource name by a principal with the specified security
attributes. This can be found in section 2.3, on page 2-13 of the draft Adopted
Specification.
Resolution:
Remove the offending sentence fragment.
Revised Text: see resolution description.
Sub-Issue No: 3178G3
Grammar
Clarification:
This comment is in reference to the following sentence under
get_dynamic_attributes(): "The service may add or remove
SecAttributes to this list." This can be found in section 2.4, page 2-14 of
the draft Adopted Specification.
Resolution:
Change the text to read "The service may add SecAttributes to this list, or
remove SecAttributes from this list."
Revised Text: see resolution description.
Sub-Issue No: 3178G4
Grammar
Clarification: This comment is in reference to following sentence found under
get_policy_decision_evaluators(): "A
PolicyDecisionEvaluators structure, which contains a list of
NamedPolicyEvaluator consisting of the names of the
PolicyEvaluators and their object references, and the
DecisionCombinator object reference for the resource is returned to the
client." This can be found in section 2.5, page 2-15 of the draft Adopted
Specification.
Resolution:
Remove the sentence and replace it with the following "A
PolicyDecisionEvaluators structure is returned to the client. A
PolicyDecisionEvaluators structure contains a
PolicyEvaluatorList and the DecisionCombinator."
Revised Text: see resolution description.
Sub-Issue No: 3178G5
Grammar
Clarification:
This is issue 3178G. This comment is in reference to the following sentence
found in the text directly beneath the DecisionCombinator interface idl:
"The DecisionCombinator interface is used to encapsulate the policy for
the way that decisions of multiple PolicyEvaluators is combined." This
can be found in section 2.6, page 2-15 of the draft Adopted Specification.
Resolution:
Change the sentence to read: "The DecisionCombinator interface is used
to encapsulate a policy for combining decisions of multiple consulted
PolicyEvaluators that may disagree."
Revised Text: see resolution description.
Sub-Issue No: 3178H Elsewhere it was stated that this interface is a singleton. That should be
stated here, the site of the primary specification of the interface.
Clarification:
This comment is in reference to the AccessDecision Interface text, which
can be found in section 2.3, page 2-12 of the draft Adopted Specification.
Resolution:
Add the word "singleton" before the word object in the first sentence of
section 2.3, page 2-12. "The singleton Access Decision object..."
Revised Text: see resolution description.
Sub-Issue No: 3178H2
Elsewhere it was stated that this interface is a singleton. That should be
stated here, the site of the primary specification of the interface.
Clarification:
This comment is in reference to the DynamicAttributeService Interface
text, which can be found in section 2.4, page 2-13 of the draft Adopted
Specification.
Resolution:
Reject. No change. Although only one DynamicAttributeService
reference is held at a time by a RAD, the object may be replaced by an
alternate. The specification makes this clear.
Revised Text: None
Sub-Issue No: 3178H3
Elsewhere it was stated that this interface is a singleton. That should be
stated here, the site of the primary specification of the interface.
Clarification: This comment is in reference to the PolicyEvaluatorLocator Interface
text, which can be found in section 2.5, page 2-14 of the draft Adopted
Specification.
Resolution:
Reject. No change. Although only one PolicyEvaluatorLocator
reference is held at a time by a RAD, the object may be replaced by an
alternate. The specification makes this clear.
Revised Text: None
Sub-Issue No: 3178I
Note that preconditions such as this one would not have to be repetitively
stated for many operations if the definitions of validity were explicitly
characterized as invariants. Specification of invariants is a key concept in
design by contract. From the standpoint of the computational model (i.e. from
the computational viewpoint) invariants constitute universal pre and post
conditions for all operations, although not every invariant is directly relevant to
every operation. Since this document provides validity criteria for most (it’s
missing for a few) of the types, this work (i.e. formal specification of
invariants) is mostly done. A few small adjustments would tie this all neatly
together:
7 [FTF] Explicitly label the validity rules as invariants.
7 [FTF] Add a statement to the section on pre-postcondition semantics noting
that the invariants are considered to be pre and postconditions for all
operations.
7 [FTF] Remove the pre and postconditions that thus become redundant.
(Note that this document is not consistent in repeating such validity rules as
preconditions. For example, the set_evaluators() operation of
PolicyEvaluationLocatorNameAdmin requires a ResoureName as
input, yet does not specify any preconditions.)
Clarification:
This comment is in reference to the preconditions found under
access_allowed(). You can find this in section 2.3, on page 2-13 of the
draft Adopted >Specifications.
Resolution:
Reject this issue. This was not an issue for implementors.
Revised Text: None Sub-Issue No: 3178K
Oddly phrased. Seems more appropriate for the bulk of this to be re-cast as a
postcondition
Clarification:
This comment is in reference to the following sentence found under
get_policy_decision_evaluators(): "A
PolicyDecisionEvaluators structure, which contains a list of
NamedPolicyEvaluator consisting of the names of the
PolicyEvaluators and their object references, and the
DecisionCombinator object reference for the resource is returned to the
client." This can be found in section 2.5, page 2-15 of the draft Adopted
Specification.
Resolution:
This is resolved by the proposed resolution to issue 3178G4 (same
sentence).
Revised Text: None
Sub-Issue No: 3178K2
The rules in these two sentences could (and probably should) be framed as
postconditions for get_policy_decision_evaluators.
Clarification:
This comment is in reference to the following sentence under
set_default_evaluators: "Default evaluators are overridden by the
add_evaluators() or replace_evaluators() methods. The default
evaluators will be returned by the PolicyEvaluatorLocator
get_policy_decision_evaluators() method when no
PolicyEvaluators have been explicitly assigned for a ResourceName."
This can be found in section 2.8, page 2-20 of the draft Adopted Specification.
Resolution:
Reject the request to express this as a postcondition as this was not an issue
for implementors. Change the referenced sentence to read: "Default
evaluators are overridden by the add_evaluators() or replace_evaluators() operations. The default evaluators will be returned
by the PolicyEvaluatorLocator
get_policy_decision_evaluators() operation when no
PolicyEvaluators have been explicitly assigned for a ResourceName."
This fixes incorrect terminology.
Revised Text: See resolution
Sub-Issue No: 3178K3
This rule should probably be framed as a postcondition for
get_policy_decision_evaluators.
Clarification:
This comment is in reference to the following sentence found under
set_default_combinator: "This combinator will be returned by the
PolicyEvaluatorLocator get_policy_decision_evaluators()
method for these resources. This can be found in section 2.8, page 2-20 of
the draft Adopted Specification.
Resolution:
This was not an issue for implementors. Reject request to frame as a
postcondition. Change, however, the sentence to read: "This combinator will
be returned by the PolicyEvaluatorLocator
get_policy_decision_evaluators() operation for these resources."
Revised Text: see resolution
Sub-Issue No: 3178L
It should be possible to state a postcondition here, as is done for the
access_allowed() and evaluate() operations.
Clarification:
This is in reference to the statement that there are no postconditions for
combine_decisions. This can be found in section 2.6, page 2-17 of the
draft Adopted Specification.
Resolution: Reject. No Change. The return from the operation is a Boolean. There were
no issues for implementors that no postcondition was stated.
Revised Text: None
Sub-Issue No: 3178M
Why aren’t these four operations modeled as two attributes?
Clarification:
This is in reference to AccessDecisionAdmin interface. This can be found
in section 2.8, page 2-18 of the draft Adopted Specification.
Resolution:
Not an issue. No change.
Revised Text: None
Sub-Issue No: 3178N
The declaration that the operation raises this exception appears to be defining
how the object behaves when a precondition is not met, which contradicts the
policy stated at the outset that such behavior is undefined. (Although
"ResourceName is valid" is not stated as a precondition for this operation,
this omission is inconsistent, as has already been pointed out, with other
operations that require a ResourceName in-parameter. Truly, this validity
requirement is a precondition.)
Clarification:
This is issue 3178N. This comment is in reference to
InvalidResourceName found in the
PolicyEvaluatorLocatorNameAdmin interface, section 2.10, page 2-21
of the draft Adopted Specification.
Resolution:
No change. The exception is needed.
Revised Text: None Sub-Issue No: 3178O
This way of specifying the postcondition would be more rigorous if
default_evaluators were formally defined as a role of
PolicyEvaluationList in a relationship between
PolicyEvaluatorLocator and PolicyEvaluationList. The
relationship and role could be defined via UML notation or by textual means.
This same approach could be applied to many of the postconditions that
follow.
Clarification:
This comment is in reference to the postcondition stated under
set_default_evaluators, which can be found in section 2.8, page 2-20
of the draft Adopted Specification.
Resolution:
Not an issue for implementors. No change.
Revised Text: None
Sub-Issue No: 3178P
The explanation above of set_default_evaluators() stated how the
defaults are overridden. For consistency it should be stated here how the
default DecisionCombinator is overridden.
Clarification:
This comment is in reference to set_default_combinator, which can be
found in section 2.8, page 2-20 of the draft Adopted Specification.
Resolution:
Delete the sentence that is referenced as saying how defaults are overridden.
The sentence to remove is in the first paragraph of page 2-20 and starts:
"Default evaluators may be overridden by the ..." One of the operations listed
is no longer in the spec (replace_evaluators). How evaluators and
combinators are replaced is explained elsewhere in the specification. This will
resolve the consistency issue and fix the reference.
Revised Text: See resolution Sub-Issue No: 3178Q
I believe this should be ResourceName rather than
ResourceNamePattern. Ditto for the remainder of the operations in this
interface.
Clarification:
This comment is in reference to the
PolicyEvaluatorLocatorNameAdmin interface, which can be found in
section 2.10, page 2-21 of the draft Adopted Specification.
Resolution:
Accept. Change every instance of the parameter "in
ResourceNamePattern" in operations of the interface
PolicyEvaluatorLocatorNameAdmin to "in ResourceName". Change
any supporting text in section 2.10 and the complete IDL.
Revised Text:
Sub-Issue No: 3178R
Should be singular.
Clarification:
This comment is in reference to ResourceNamePatterns found in the
following sentence under the PolicyEvaluatorLocatorPatternAdmin
interface: "The PolicyEvaluatorLocatorPatternAdmin object is used
to associate PolicyEvaluators with a ResourceNamePatterns." This is
the first sentence under the PolicyEvaluatorLocatorPatternAdmin
interface idl in section 2.11, page 2-25 of the draft Adopted Specification.
Resolution:
Change the sentence to read: "The
PolicyEvaluatorLocatorPatternAdmin object is used to associate
PolicyEvaluators with a ResourceNamePattern."
Revised Text: see resolution
Sub-Issue No: 3178S This seems to suggest that in order for a name_string to conform to this
second kind, must literally be equal to "*". However, the presentation given to
CORBAmed shows that it can contain "*" but not literally be "*". The example
in the presentation was something like "Red.*"
Clarification:
This comment is in reference to the following sentence under the second kind
of ResourceNameComponent: "The second kind of
ResourceNameComponent which can occur in a pattern is a component
wildcard pattern: -name_string is "*" ; value_string is "*"" This can be
found in section 2.11, page 2-26 of the draft Adopted Specification.
Resolution:
The specification is correct. The second kind of ResourceNameComponent
(wildcard) requires that both name and value be precisely "*". To clarify this,
change the bullets on page 2-26 to read:
- name_string exactly matches "*" and
- value_string exactly matches "*"
Revised Text: see resolution
Sub-Issue No: 3178T
Despite the helpful diagram, the pattern matching logic is hard to
comprehend. I feel it imperative that several concrete examples be provided.
Clarification:
This comment is in reference to the following paragraph found under the
PolicyEvaluatorLocatorPatternAdmin interface: "MATCHES_AS_GRE
returns "yes" if the string provided by first argument matches another string
provided by second argument, where the second string is interpreted
according to regular expression syntax specified in the definition of
ResourceNamePattern type on Page 26, otherwise "no.". Also, the "helpful
diagram" is missing in the draft adopted spec. Our feeling is that with the
diagram the algorithm is understandable.
Resolution:
1) Change the wording of the above sentence to read: "MATCHES_AS_GRE returns "yes" if the resource "name" matches the
resource name "pattern", where the "pattern" is interpreted according to the
regular expression syntax specified in the definition of
ResourceNamePattern in section 2.2.2 page 2-5.
2) Insert the diagram containing the algorithm (this is contained in the same
section of the revised submission corbamed/99-04-05 - an editing error
removed it from the draft submission) after the sentence on page 2-26 "A
resource name matches a pattern if and only if the algorithm shown in the
figure below returns MATCH."
Revised Text: see resolution
Sub-Issue No: 3178U
Unclear
Clarification:
This comment is in reference to the following sentence found under the
definition of register_resource_name_pattern: "Since a
ResourceName is a ResourceNamePattern, ResourceNames must also
be registered if these administrative interfaces are administer evaluators and
combinators." This can be found in section 2.11, page 2-26 of the draft
Adopted Specification.
Resolution:
Change the sentence to read: "Since a ResourceName is a
ResourceNamePattern, ResourceNames must also be registered if these
administrative interfaces are used to administer evaluators and combinators."
Revised Text: see resolution
Sub-Issue No: 3178V
In the postcondition this is called "policy_name" (singular), which is more
logical.
Clarification:
This comment is referring to the fact that in the IDL, "policy_name has an
"s" on the end policy_names. This can be found in section 2.12, page 2-30
of the draft Adopted Specification. Resolution:
No change. Editor can’t find the offending postcondition.
Revised Text: None
Sub-Issue No: 3178W
Should be included in the postconditions.
Clarification:
This comment is in reference to the following statement found under
set_policies: "If a single PolicyName of NO_ACCESS_POLICY is
specified, then all policy is removed for the resource. This can be found in
section 2.12, page 2-30 of the draft Adopted Specification.
Resolution:
State in the postcondition that if PolicyName == NO_ACCESS_POLICY then
no policy exists for the resource.
Revised Text: see resolution
Sub-Issue No: 3178X
Attribute, not data member.
Clarification:
This comment is in reference to the following sentence found under
Conformance Classes: "In this case pattern_admin data member of
PolicyEvaluatorLocator interface implementation must have value null."
This can be found in section 2.13, page 2-32 of the draft Adopted
Specification.
Resolution:
Change the sentence to read: "In this case the pattern_admin attribute of
the PolicyEvaluatorLocator interface implementation must be/return
null."
Revised Text: see resolution Sub-Issue No: 3178Y
This is the first time in the document that we’ve seen an example of a
ResourceName. I recommend enhancing the usage scenario in the previous
section to similarly show the anatomy of the ResourceName being used in
the example.
Clarification:
This comment is in reference to the following sentence found in Appendix C:
"create RAD resource names according to the following rules:" This can be
found on page C-2 of the draft Adopted Specifications.
Resolution:
Reject. No change. This is an example, not part of the normative part of the
spec.
Revised Text: None
Sub-Issue No: 3178Z
It might be a good idea for ResourceNameComponent to have a boolean
data item indicating whether the component is mandatory or optional.
Clarification:
This comment is in reference to the following sentence found under Appendix
C, #5: "all other elements of ResourceName data member
resource_name_component_list are optional." This can be found on
page C-2 of the draft Adopted Specifications.
Resolution:
Reject.
Revised Text: None
Disposition: Resolved
Disposition Parameter: None

>You have probably already caught these problems. Just in case you haven't I
>am sending a modified copy. Mainly problems with missing or extra forward
>declarations.
>
>You can probably ignore the 'include "cds_patches.idl". We are not using a
>2.3 orb so we had to define some types that were needed by the 2.3
>security.idl.

The number of security policies supported by a PolicyEvaluator could be
arbitrarily large. Because of this the operation "list_policies" in the
PolicyEvaluatorAdmin interface might be changed to:

	PolicyNameIter  list_policies(in num_ret, in max_iter, out
PolicyNameList policy_names);

where max_iter is maximum number of entries held by the iterator, num_ret
is the maximum number of entries returned in the "out PolicyNameList list"
argument, and "policy_names" is sequence of PolicyNames having at most
"num_ret" entries.  If the list of policy names has less than "num_ret"
entries, the iterator will be nil.

The iterator interface would look like:

interface PolicyNameIter {
	long	how_many();

	boolean next_n(in long val, out PolicyNameList policy_names);

	void destroy();
};

Note this technique could be carried to the extreme for all those
operations that return a PolicyEvaluatorList. However, it seems less likely
that one would has assigned large numbers of evaluator in the same way one
might have large numbers of security policies.  

In multiple places in the IDL (struct AccessDefinition,
AccessDecision::access_allowed) the following is used:
	
	Operation operation;

This is invalid IDL despite the fact that many IDL compilers accept this
today.

Some of the exceptions defined could use names that are less like to
conflict with standard language objects and thus would not have to be fully
qualified.  For example, InternalError conflicts with
java.lang.InternalError.  Perhaps RadInternalError might be nicer.
ComponentError might be another candidate for RadComponentError.

The exception InputFormatError is only raises by one operation,
set_evaluators_by_pattern.  I don't understand why this would not raise the
same exceptions as add_evaluators_by_pattern or
delete_evaluators_by_pattern.  They all have the same input parameters.

The DynamicAttributeService was designed to allow modification of
SecAttributes prior to locating and using PolicyEvaluators.  These
modifications are application are most likely specific in nature.
Unfortunately the entire service can only have one DynamicAttributeService,
therefore, instance of RAD service have to be partitioned for different
applications.  It might have been better to have associations with
ResouceNames such as was done with PolicyEvaluators.  Another alternative
might have been to associate a DynamicAttributeService with a combinator,
since different resource names can use different combinators this implies
they also could then have different DynamicAttributeServices.  This is
probably not an important issue, but it can dictate how applications must
deploy instances of the service.

The following operations in the EntityFactory Interface need adjustment to correctly generate geometries:


For EntityFactory::index_bodies():
LongSeq index_bodies(in LongSeqSeq oriented_shells);


The oriented_shells data must be in the form: LongSeqSeq as showns above.


LongSeq index_faces(in LongSeqSeq oriented_eloops, in LongSeqSeq vertex_loops,
in LongSeq surfaces);


The vertex_loops data must be in the form: LongSeqSeq as shown above.


Also, the name used for the first argument to index_oriented_shells() is misleading:
LongSeq index_oriented_shells(in LongSeq ofaces, in BooleanSeq sense);


ofaces should be shells.