[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition of "Service Consumer"
Since sending this message, I've had an epiphany thanks to Anders. There is a place for security, indirectly, within the service contract/agreement. I doubt there will be further epiphanies on this. -Matt Ken Laskey wrote: > RM == lowest common denominator that provides usable capability to > the intended audience. We could easily reduce the RM to something > approaching a null set by finding cases where something is not > needed. If fact, I could argue that your render farm has no need > for advertising/discovery. For most of our audience, an SOA without > security is less than worthless and we should think carefully about > whether our response is merely "you can always add it on". > > Ken > > On Apr 12, 2005, at 10:50 AM, Matthew MacKenzie wrote: > >> RM == lowest common denominator. It is not an "architecture", or >> blueprint of a solution. We cannot add something as complicated and >> diverse as security to the reference model without making some >> strong recommendations about how to architect security in an SOA. >> >> Imagine these two SOAs: a render farm, and an intelligence >> information system. The render farm is isolated from open networks >> and all cycles are devoted to processing video frames, whereas the >> intelligence system is hyper connected. This makes for extremely >> diverse security requirements. The render farm may use extensive >> physical security, and rely on logging mechanisms to determine who >> did what later on. In this case, it could be argued that the render >> farm SOA has no security. The Intelligence system, on the other >> hand, would have a multi-level security architecture governing >> everything from encryption of non-transient storage media to xml >> encryption to intensive physical security requirements. >> >> This is not our business, and all we will do in the RM is disqualify >> the RM from being used in various situations. >> >> -Matt >> >> Ken Laskey wrote: >> >>> Let's leave this as an open issue, if we may. Except for a very >>> simple, very closed system, I cannot imagine a viable SOA in a >>> real environment without security. I am willing to be educated >>> about situations where security can legitimately be skipped, but I >>> don't think it can be left out of a useful RM. >>> >>> Ken >>> >>> On Apr 11, 2005, at 3:32 PM, Matthew MacKenzie wrote: >>> >>>> I don't believe that all SOAs do or will have security. I think >>>> we should simply not mention it. This is, after all, an >>>> abstract reference model. We can produce the warmNfuzzy that >>>> having a security component adds in our own SOA designs that are >>>> identifiable with the SOA-RM. >>>> >>>> -matt >>>> >>>> On 11-Apr-05, at 12:28 PM, Duane Nickull wrote: >>>> >>>>> Ken: >>>>> >>>>> I am not 100% sure about this. I would like to research this on >>>>> a more philosophical basis. Not all SOA's use explicit >>>>> security protocols (the internet doesn't). The fundamental >>>>> philosophical question may be " does the explicit statement >>>>> conveying the absence of any security still imply a security >>>>> model"? >>>>> >>>>> The danger in saying "yes" is that it opens the door for more >>>>> "things" to be part of the RM. >>>>> >>>>> I would like to mull this over and do some research. I am sure >>>>> Matt has a good answer ;-) >>>>> >>>>> Duane >>>>> >>>>> Ken Laskey wrote: >>>>> >>>>>> Moreover, the question is whether all SOAs SHOULD have security >>>>>> and whether that needs to be captured in the RM. As noted, >>>>>> secuirty is often just tacked on and that may not be sufficient >>>>>> for *any* SOA to be successful. >>>>>> >>>>>> Ken >>>>>> >>>>>> At 02:27 PM 4/11/2005, Duane Nickull wrote: >>>>>> >>>>>>> The RM does not support security models. A reference model is >>>>>>> used to guide the design of architecture that may include >>>>>>> specific security protocols or models. Our requirement must be >>>>>>> to ensure that nothing we place in the RM makes any specific >>>>>>> security model a requirement (since not all SOA's have >>>>>>> security) and to ensure that we do not preclude a specific >>>>>>> type of security model from being used. >>>>>>> Duane >>>>>>> >>>>>>> Vikas Deolaliker wrote: >>>>>>> >>>>>>>> I think the question should be how many different types of >>>>>>>> security models >>>>>>>> will this RM support? >>>>>>>> Vikas >>>>>>>> >>>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- *********** >>>>>>> Senior Standards Strategist - Adobe Systems, Inc. - >>>>>>> http://www.adobe.com >>>>>>> Vice Chair - UN/CEFACT Bureau Plenary - >>>>>>> http://www.unece.org/cefact/ >>>>>>> Adobe Enterprise Developer Resources - >>>>>>> http://www.adobe.com/enterprise/developer/main.html >>>>>>> *********** >>>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------- >>>>>> -- ------------ >>>>>> / Ken >>>>>> Laskey >>>>>> \ >>>>>> | MITRE Corporation, M/S H305 phone: 703-883-7934 | >>>>>> | 7515 Colshire Drive fax: >>>>>> 703-883-1379 | >>>>>> \ McLean VA >>>>>> 22102-7508 / >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> -- ------------- >>>>>> >>>>>> >>>>> >>>>> -- >>>>> *********** >>>>> Senior Standards Strategist - Adobe Systems, Inc. - >>>>> http://www.adobe.com >>>>> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ >>>>> Adobe Enterprise Developer Resources - >>>>> http://www.adobe.com/enterprise/developer/main.html >>>>> *********** >>>>> >>>> >>>> >>> ---------------------------------------------------------------------- >>> -- ------------------ >>> Ken Laskey >>> MITRE Corporation, M/S H305 phone: 703-883-7934 >>> 7515 Colshire Drive fax: 703-883-1379 >>> McLean VA 22102-7508 >>> >>> >> >> > > ------------------------------------------------------------------------ > ------------------ > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-883-7934 > 7515 Colshire Drive fax: 703-883-1379 > McLean VA 22102-7508 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]