Resource Access Decision Avatar
  1. OMG Specification

Resource Access Decision — All Issues

  • Acronym: RAD
  • Issues Count: 10
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

The exception InputFormatError is only raises by one operation

  • Key: RAD-9
  • Legacy Issue Number: 3256
  • Status: closed  
  • Source: 2AB ( Bob Burt)
  • Summary:

    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.

  • Reported: RAD 1.0b1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 23:14 GMT

Use of names in defined exceptions

  • Key: RAD-8
  • Legacy Issue Number: 3255
  • Status: closed  
  • Source: 2AB ( Bob Burt)
  • Summary:

    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.

  • Reported: RAD 1.0b1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 23:14 GMT

Invalid IDL

  • Key: RAD-7
  • Legacy Issue Number: 3254
  • Status: closed  
  • Source: 2AB ( Bob Burt)
  • Summary:

    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.

  • Reported: RAD 1.0b1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 23:14 GMT

DynamicAttributeService issue

  • Key: RAD-10
  • Legacy Issue Number: 3257
  • Status: closed  
  • Source: 2AB ( Bob Burt)
  • Summary:

    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.

  • Reported: RAD 1.0b1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    Close this issue with no change.

  • Updated: Fri, 6 Mar 2015 23:14 GMT

Number of security policies supporteb by PolicyEvaluator arbitrarily large

  • Key: RAD-6
  • Legacy Issue Number: 3253
  • Status: closed  
  • Source: 2AB ( Bob Burt)
  • Summary:

    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.

  • Reported: RAD 1.0b1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 23:14 GMT

RAD idl problems

  • Key: RAD-5
  • Legacy Issue Number: 3211
  • Status: closed  
  • Source: Anonymous
  • Summary:

    >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.

  • Reported: RAD 1.0b1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 23:14 GMT

RAD FTF Issues document

  • Key: RAD-4
  • Legacy Issue Number: 3178
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: RAD 1.0b1 — Wed, 5 Jan 2000 05:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:14 GMT

The following operations in the EntityFactory Interface need adjustments

  • Key: RAD-3
  • Legacy Issue Number: 5435
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    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.

  • Reported: RAD 1.0b1 — Tue, 18 Jun 2002 04:00 GMT
  • Disposition: Resolved — RAD 1.0
  • Disposition Summary:

    The recommended changes are made as suggested in the summary

  • Updated: Fri, 6 Mar 2015 21:39 GMT

Resource Access Decision service

  • Key: RAD-2
  • Legacy Issue Number: 5089
  • Status: open  
  • Source: Cognition Group, Inc. ( David Forslund)
  • Summary:

    In the text of the RAD document formal/2001-04-01, there is reference to the multiple_evaluate() method
    of the PolicyEvaluator interface, but it is not defined in the IDL.

  • Reported: RAD 1.0 — Tue, 19 Feb 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resource Access Decision Security

  • Key: RAD-1
  • Legacy Issue Number: 5088
  • Status: open  
  • Source: Cognition Group, Inc. ( David Forslund)
  • Summary:

    It seems to me that RAD may need to use RAD to provide access control over certain ResourceNames (particularly for the administrative interfaces, where some folks may own portions of the ResourceName namespace. Has anyone tackled this? It seems to me that it is a useful (and perhaps vital) effort.

  • Reported: RAD 1.0 — Tue, 19 Feb 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT