[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] Follow-up to 7-5-08 Telecom
Well stated Ken. We have a slight difference in the way we view the execution context. For the purpose of the RM and RA, I see the concept of execution context as passive. So I would not assign actions to the execution context itself. I would assign actions to the elements that make up the execution context. Danny -------- Original Message -------- Subject: Re: [soa-rm-ra] Follow-up to 7-5-08 Telecom From: Ken Laskey <klaskey@mitre.org> Date: Fri, May 09, 2008 2:19 pm To: michael.poulin@uk.fid-intl.com Cc: soa-rm-ra@lists.oasis-open.org, danny.thornton@scalablearchitectures.com, dnickull@adobe.com, frankmccabe@mac.com Hi Michael, I think I'd like to rearrange the words a bit more. The RM states <RM> The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities. As discussed in previous sections of this document, the service description (and a corresponding description associated with the service consumer and its needs) contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used. The participants (providers, consumers, and any third parties as noted below) must agree and acknowledge a consistent set of agreements in order to have a successful service interaction, i.e. realizing the described real world effects. The execution context is the collection of this consistent set of agreements. </RM> So part of the execution context will likely be the security policies in effect for the interaction. Mechanisms must be available to monitor conditions and use the collected metrics as needed to evaluate policy compliance, and there should also be mechanisms for policy enforcement based on the evaluations. If there are alternative methods for compliance evaluation or enforcement, the execution would include agreements on the mechanisms to use, either decided real-time or documented from prior agreements. The policies will elaborate on the expected level of protection of confidentiality and integrity of message exchanges and on what may be required in the way of support for security between different communication technologies; the execution context will enumerate which policies are in effect. The SOA infrastructure will likely provide centralized or decentralized policy-based identification, authentication, and authorization; the execution context may specify which of these should be used for the interaction. Availability and scalability are more general requirements of the security infrastructure and are probably not included in the execution context because they are properties of the implemented system and not the interaction using the system. So after a lengthy public thought process, I'd suggest The mechanisms through which SOA security will be evaluated and enforced should: * [5 existing bullets] * be consistent with the agreements specified in the execution context for the interaction. Ken On May 8, 2008, at 6:03 AM, michael.poulin@uk.fid-intl.com wrote: Below, is my note related to security, section 5.2.7. I am not sure we need to discuss it at the next Telecom or we can discuss it via e-mail. 5.2.7 Architectural Implications of SOA Security One of the last 'big' bullet-points says: "The mechanisms that make-up the execution context in secure SOA-based message exchanges should:". I think, it is not enough for SOA Security. We have talked already that execution context may be applied (according to SOA RM) as to the message exchange as to the service execution (service body) itself. From the service consumer perspective, security of the message exchange is equally important to the security of the service execution. For example, the major fault in HTTPS is that the message becomes naked (unprotected) the next moment it reaches the destination - Web Server. Now, it is the Web Server and the rest of the receiver's system have to preserve message integrity, confidentiality, etc. If they do not do this, consumer's sensitive data may be tempered during the service executions. I would like to propose very simple change in the text: replace words "message exchanges" by the word "systems" and leave the list of security measures as is. Thus, the phrase would sound like: "The mechanisms that make-up the execution context in secure SOA-based systems should:" - Michael ------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]