[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Security (Re: [soa-rm] Definition of "Service Consumer")
Ken: I would also agree with this. Security as a physical thing or set of things is different from the concept of an abstract security policy. The policy itself in a RM level would usually not get into anything that is implementation specific like authentication or non-repudiation since those are very specific and concrete terms. The ISO created the OSI reference model solely to describe the external behavior of electronics systems, not their internal functions. "Integrity check, authentication, Identity Management, Confidentiality, Message-Level Security" are all very specific internal functions. The abstract external behavior is "enforce compliance with a security policy". According to the ISO, a reference model does not determine programming or operating system functions, nor does it specify an application programming interface (API) for doing anything as specific as those functions. The reasoning, as I understand it, is to allow architects the greatest amount of latitude to develop specific models that suit them best. Duane Ken Laskey wrote: > Is there a difference between a contract requiring security and the > RM including (abstract) mechanisms needed to enforce security? I > think so. I certainly do not want us to get into the details of > security policies or implementations but we need to consider what are > the abstract concepts related to security. From past efforts, I can > remember four: > - authentication (the service provider can unambiguously identify the > service requester) > - authorization (the service provider can unambiguously determine > that the service requester has the right to use the service) > - integrity (the service provider, possibly through the communication > mechanism, can be unambiguously assured that the request has not been > modified from what was sent by the service requester (except possibly > as otherwise authorized)) > - nonrepudiation (neither the service requester nor the service > provider can later claim they were not part of the request and response) > > Note, I described this in the context of request/response but I > believe it can be generalized to other MEPs. > > Is this abstract enough to at least consider? > > Ken > > On Apr 12, 2005, at 1:44 PM, Duane Nickull wrote: > >> Would this inference be accurate: >> >> A security policy, in addition to other service policies, is part of >> a service contract. A security policy is a declaration of a set of >> requirements that must be met in order to consume a service. A >> declaration that indicates no requirements must be met is still >> conceptually considered a security policy. >> >> Duane >> >> >> >> Francis McCabe wrote: >> >>> This is how I see it also. The contract represents the syntactic, >>> semantic and pragmatic constraints on the use of a service. That >>> covers security, and I hope QoS management, etc. >>> Frank >>> >>> On Apr 12, 2005, at 8:08 AM, Matthew MacKenzie wrote: >>> >>>> Security could be fit into the RM indirectly via "Contract" (or a >>>> less controversial word, such as "Agreement"). You talking about >>>> refusing service tweaked this in my brain... >>>> >>>> "Service use agreement may mandate security requirements to be >>>> met, and if they are not, service may be refused." >>>> >>>> -matt >>>> >>>> >>>> Anders W. Tell wrote: >>>> >>>>> Hi, >>>>> >>>>> This is getting interesting so Ill just join in >>>>> >>>>> There seem to be good reasons why security or maybe more >>>>> appropriate security related functions could be part of a >>>>> (abstract) RM. Functions such as (add,verify)integrity, >>>>> (add,verify)confidentiality, (add,verify)authentication etc. >>>>> >>>>> If one wants to later relate a RM to economical and legel >>>>> aspects such as those found in service level agreements then >>>>> such abstract function seems relevant. >>>>> >>>>> The rigth to refuce service access may be a function of >>>>> authenticationverification of issuer, sender ,indended receive, >>>>> addressee. >>>>> >>>>> So Ill think Ken is right that it maybe a good point keeping it >>>>> on the agenda and removed later if deemed to concrete. >>>>> >>>>> /Anders >>>>> >>>>> 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 > > -- *********** 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 ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]