[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")
<Quote> Is there a difference between a contract requiring security and the RM including (abstract) mechanisms needed to enforce security? I think so. </Quote> I do as well. I would also add the following to Ken's excellent list of security concepts below (sorry that I don't have time now to provide definitions - can at a later point if required): - Identity Management - Confidentiality - Message-Level Security (a la OASIS WSS) Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Tuesday, April 12, 2005 7:12 PM > To: Duane Nickull > Cc: Francis McCabe; Matthew MacKenzie; Anders W. Tell; > soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Security (Re: [soa-rm] Definition of > "Service Consumer") > > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]