Issue 630: Access to AccessDecision and AuditDecision objects? (sec-rev) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: How does user application get hold of object references to AccessDecision and the AuditDecision object? Spec does not provide any means for poor application to get access Resolution: resolved, close issue Revised Text: Actions taken: July 16, 1997: received issue March 26, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jis@fpk.hp.com Date: Wed, 16 Jul 1997 18:19:43 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Belinda Fairthorne , Bob Blakley Cc: sec-rev@omg.org Subject: Access to AccessDecision and AuditDecision objects? Bob and Belinda, This is a question for you. How does an user application get hold of object references to the AccessDecision and the AuditDecision object? Figure 15-51 suggest that the application should be able to get access to these objects. But nowhere does the spec provide any means for the poor application to get access to these objects. Is this jsut an oversight that needs to be fixed or am I missing something bigtime here? Thanks. Jishnu. -- Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Fri, 18 Jul 97 15:58:06 +0100 X400-Received: by /PRMD=iclexpo/ADMD=gold 400/C=GB/ ; converted ({ 1 1 10021 7 1 0 1 }, , ) ; Relayed ; Fri, 18 Jul 97 15:57:17 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (Undefined) ; Relayed ; Fri, 18 Jul 97 15:56:22 +0100 Date: Fri, 18 Jul 97 15:56:22 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;bra0105 0000020000007510] X400-Originator: "Belinda Fairthorne" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1988 (22) Original-Encoded-Information-Types: Undefined Content-Identifier: 7510 Priority: normal From: "Belinda Fairthorne" To: jis@fpk.hp.com Cc: belinda.fairthorne@x400.icl.co.uk, blakley@vnet.ibm.com, sec-rev@omg.org References: <33CD48FF.3953@fpk.hp.com> Importance: normal Subject: RE: Access to AccessDecision and AuditDecision objects? Content-Description: General Text Jishnu, The model section of the CORBA Security spec describes use of get_policy on Current for obtaining Access and Audit Decision objects. Its normally done by the ORB/intercepters, so described in what was section 4.4.4. For application level access decision objects, it is described in 4.4.2. The description of get_policy in the interfaces section gives just the interface, withoult repeating how its used. Belinda Return-Path: Sender: jis@fpk.hp.com Date: Fri, 18 Jul 1997 14:08:38 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Belinda Fairthorne Cc: blakley@vnet.ibm.com, sec-rev@omg.org Subject: Re: Access to AccessDecision and AuditDecision objects? References: <33CD48FF.3953@fpk.hp.com> <5379.1022146877@x400.icl.co.uk> Belinda, Good to hear from you. I am dearly hoping that you would get a little more involved in the revision discussions. It is very difficult for me to second guess the original authors without their active participation to resolve issues in this not uncomplicated specification. Belinda Fairthorne wrote: > > Jishnu, > > The model section of the CORBA Security spec describes use > of > get_policy on Current for obtaining Access and Audit > Decision > objects. Its normally done by the ORB/intercepters, so > described > in what was section 4.4.4. For application level access > decision > objects, it is described in 4.4.2. > > The description of get_policy in the interfaces section > gives just > the interface, withoult repeating how its used. But the type of things that can be returned by the get_policy operation (Policy) as specified in the Interface section precludes the use of that operation from returning an AccessDecision or AuditDecision objects (which are not derived from Policy) notwithstanding what the model section says. Actually I also think that the model section is quite confusing due to the use of the same name of operation get_policy, which is always used not fully qualified, hence it is hard to tell which get_policy operation one is talking about (Current::get_policy? Object::get_policy?), and which seemingly returns different things at different places. I think it needs some cleanup work. There has been some discussion covering this exact topic in the past and my impression is that Bob may have a completely different interpretation of that section from what either you or I have. Thus he talks of a get_default_policy operation in Current etc. Specific to the problem of gaining access to the Decision objects, I think you and I agree in principle, but I point out that the IDL as specified is inconsistent with that principle. I think it may be getting close to a time when we need a short teleconference. BTW, since objects derived from Policy are associated generally with "management interfaces" I think it would be exceedingly confusing to return "decision interfaces" from certain get_policy operations (e.g. Current::get_policy) and not from others (e.g. Object::get_policy). So minimally we need to change (or specify) the IDL definition of whatever operation in Current gives access to the AccessDecision and AuditDecision functions. It seems to me that if we really want to follow the same model as that for get_policy to provide access to Decision functions we need to add the following to the IDL: (1) In SecurityLevel2 define a base interface: interface Decision { readonly attribute PolicyType policy_type; } (2) Have both AccessDecision and AuditDecision derive from this interface. (3) Add the operation: Decision get_decision_object(in PolicyType policy_type); to the SecurityLevel2::Current interface. This will provide a general mechanism for obtaining a decision object corresponding to a given policy_type, if such a decision object exists. If not you just get back the base Decision object. Anyway, this needs to be discussed at the Dublin Security RTF meeting, if not earlier in a teleconference. Thanks. Jishnu. -- Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA