Issue 3257: DynamicAttributeService issue (rad-ftf) Source: 2AB (Mr. Bob Burt, bburt@2ab.com) Nature: Uncategorized Issue Severity: 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. Resolution: Close this issue with no change. Revised Text: Actions taken: January 26, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== X-Sender: bburt@mindspring.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Jan 2000 14:30:50 -0600 To: From: Bob Burt Subject: RAD FTF comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: N3f!!Q/;e9i6V!!BQ@e9 A couple of minor issues for the RAD FTF: Issue 5: 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. > ============================================================================= > >> Issue 5: > >> > >> 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. > > > >As far as I remember the whole story, originally I proposed an additional > >interface on DAS that would allow to "register" specialized > implementations of > >DASs with the "generic" DAS. My proposal assumed that there are one "generic" > >DAS and several "specialized" DASs. When a generic DAS receives a request > from > >ADO, it passes the request to specialized DASs and each of them somehow > modifies > >(usually by adding additional attributes) the list of privilege > attributes. This > >would resolve the problem that Bob brought up. The proposal was rejected > by the > >spec authors because, I believe, it would complicate the model and because we > >were tired from defining other, more important, parts of RAD model. > > > >Bob's suggestion addresses the same problem as mine. However, it is not > clear to > >me if the complexity of identifying what DAS (and probably several DASs) > should > >be consulted in order to process a given request would be in a PEL or in > the, so > >called, generic DAS. > > > >I think, we need to have a discussion on this issue in order to resolve this > >correctly. > > This is not really a big deal, just an observation. You speak about a > generic DynamicAttributeService but I don't recall the spec detailing what > a generic service should do. The spec does not read anything about generis/spsialized DASs because the idea never got into the spec. [] beznosov1.vcf >============================================================================= >>> >> Issue 5: >> Based on your comments regarding the history of DAS, I think we should forget this, at least for now. Bob Burt X-Sender: carolbrt@mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Aug 2000 20:37:16 -0500 To: rad-ftf@omg.org From: Carol Burt Subject: [RAD-FTF Issue 3257] Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 04@!!XVJ!!B)#"!=?fd9 Issue 3257 states: 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. Discussion: Before I look more closely at a concrete proposal for changing this, I think a discussion of whether this change is "out of scope" is appropriate. This was a conscious design choice (although in hindsight, I think perhaps a poor one). Have other companies found this restriction to be problematic for deployment of RAD solutions with multiple applications? It does dictate applicaition specific deployment of RAD implementations. comments? I guess it comes down to whether or not this is a design flaw or just an implementation/deployment restriction that has to be carefully planned for. _________________________________________________________ Carol Burt 2AB, Inc. cburt@2ab.com www.2ab.com 205-621-7455 ext 103 Member, OMG Architecture Board OMG Domain Member _________________________________________________________ "Solutions for Distributed Business (SM)" From: "Chris White" To: "Carol Burt" , Subject: RE: [RAD-FTF Issue 3257] Discussion Date: Fri, 11 Aug 2000 12:40:22 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000810203002.00b3c6b0@mindspring.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: p18e9@[od96##e9];?e9 In our own work the DynamicAttributeSerice is definitely application-specific. However, since we have only 'RADified' our own application, we have not run into this problem yet. If the definition of issues that should be part of the FTF is that they caused implementers problems, then we should add in the issue we encountered where we had to be non-compliant in order to use security attributes to locate policy evaluators. -----Original Message----- From: Carol Burt [mailto:cburt@2ab.com] Sent: Thursday, August 10, 2000 9:37 PM To: rad-ftf@omg.org Subject: [RAD-FTF Issue 3257] Discussion Issue 3257 states: 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. Discussion: Before I look more closely at a concrete proposal for changing this, I think a discussion of whether this change is "out of scope" is appropriate. This was a conscious design choice (although in hindsight, I think perhaps a poor one). Have other companies found this restriction to be problematic for deployment of RAD solutions with multiple applications? It does dictate applicaition specific deployment of RAD implementations. comments? I guess it comes down to whether or not this is a design flaw or just an implementation/deployment restriction that has to be carefully planned for. _________________________________________________________ Carol Burt 2AB, Inc. cburt@2ab.com www.2ab.com 205-621-7455 ext 103 Member, OMG Architecture Board OMG Domain Member _________________________________________________________ "Solutions for Distributed Business (SM)" X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 11 Aug 2000 15:07:49 -0400 (EDT) From: Polar Humenn To: Chris White cc: Carol Burt , rad-ftf@omg.org Subject: RE: [RAD-FTF Issue 3257] Discussion In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: pTe!!VfQd9Ecf!! In our own work the DynamicAttributeSerice is definitely > application-specific. However, since we have only 'RADified' our own > application, we have not run into this problem yet. > > If the definition of issues that should be part of the FTF is that > they > caused implementers problems, then we should add in the issue we > encountered > where we had to be non-compliant in order to use security attributes > to > locate policy evaluators. > > -----Original Message----- > From: Carol Burt [mailto:cburt@2ab.com] > Sent: Thursday, August 10, 2000 9:37 PM > To: rad-ftf@omg.org > Subject: [RAD-FTF Issue 3257] Discussion > > > Issue 3257 states: 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. > > Discussion: Before I look more closely at a concrete proposal for > changing > this, I think a discussion of whether this change is "out of scope" > is > appropriate. This was a conscious design choice (although in > hindsight, I > think perhaps a poor one). Have other companies found this > restriction to > be problematic for deployment of RAD solutions with multiple > applications? It does dictate applicaition specific deployment of > RAD > implementations. comments? I guess it comes down to whether or not > this > is a design flaw or just an implementation/deployment restriction > that has > to be carefully planned for. > _________________________________________________________ > Carol Burt 2AB, Inc. > cburt@2ab.com www.2ab.com > 205-621-7455 ext 103 > Member, OMG Architecture Board OMG Domain Member > _________________________________________________________ > "Solutions for Distributed Business (SM)" > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com