Let me slightly modify your words.
I would not assign actions to the execution context itself. Mechanisms (possibly specified in the execution context) that carry out actions would do so in ways that are consistent with agreements collected in the execution context.
Stated elsewhere, the execution context specifies the needed details of the environment in which the interaction occurs. Given the execution context and a log of the interaction steps, I know exactly what was done and how.
Ken
On May 9, 2008, at 6:02 PM, Danny Thornton wrote:
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 <>
Date: Fri, May 09, 2008 2:19 pm
To:
Cc: ,
, ,
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, 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
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
