RE: [soa-rm-ra] Re: [soa-rm] status and near term activities for SOA-RAF

Michael,

Thanks for the security topic list. Sorry for the delay in responding but I was on leave most of last week and still dealing with accumulated email.

Here are my thoughts on your topics:

1. re “with references to related security standards”: In general, we have not explicitly referenced other standards unless, for example IEEE-1471, we used these in developing the RAF. The limited exception is footnotes for obvious connections, such as footnote 6 on p. 52 of the 6 July draft.

2. re “is replaced by” in section 1.1.2.1: This is an example where I believe we need to be less prescriptive. At the RAF level of abstraction, we need to say that a consequence of chaining services where those services can be in different ownership domains is that conditions of use (e.g. security policies) as captured in the service contract may vary from domain to domain and this implies some level of policy enforcement is required for each service. This may be supported by services providing security functions along with local enforcement.

3. re “A model of Identity Federation replaces a model of Federated Identity”: Explain differences and consequences of each. This should lead to conclusions of what to use but does not take a stand on the “right way”. I’ve seen a lot of discussion but not consensus.

4. I agree with many of the points you make in the 1.1.2.x sections but I also know that some of your conclusions are not universally accepted. We need to show how the SOA paradigm leads to situations where one could reach these conclusions but allow room for other solutions to be developed in the future. A significant challenge is to demonstrate unwanted consequences of some brute force approaches that don’t scale.

5. re Security Responses: Agree that we need to be clear what is standard techniques that are relevant to SOA vs. where a SOA implementation introduces something new.

Ken

---------------------------------------------------------------------------

Dr. Kenneth Laskey

MITRE Corporation, M/S H305 phone: 703-983-7934

7515 Colshire Drive fax: 703-983-1379

McLean VA 22102-7508

From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Sunday, July 22, 2012 8:43 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] Re: [soa-rm] status and near term activities for SOA-RAF

Hi All,

as we agreed in the last telecom, I offer a list of topics and a few comments for the Security Model section. I am interested in your version of this list.

Security Model

Definition of security and preamble

1.1.1 Secure Interaction Concepts

Briefly, with references to related security standards:

1.1.1.1 Confidentiality

1.1.1.2 Integrity

1.1.1.3 Authentication

1.1.1.4 Authorization

1.1.1.5 Non-repudiation

1.1.1.6 Availability

1.1.1.7 Inter-relationship of Security Concepts (diagram

1.1.2 SOA Specific Approaches to Security Concerns

service independence à service ownership boundaries à business/enterprise boundaries à security realm boundaries à security realm federation

1.1.2.1 Security Concepts in Service Conract

Centralized security management mechanism is replaced by a chain of Service Contracts.

Individual Service Contracts define (or refer to) all policies for identity and access controls as well as for confidentiality, integrity and non-repudiation policies. In SOA Ecosystem, policy enforcement for all listed security concepts is based on individual Service Contracts.

A centralized security management may still be preserved in a limited group of participants who know each other and agree to open their service-business-security boundaries based on mutual trust and shared interests.

1.1.2.2 Service Ownership Boundaries

Consequences of Service Ownership Boundaries:

· · A Service of my Service, is not my Service

· · A Consumer of my Consumer, is not my Consumer

· · A Partner of my Partner, is not my Partner

· · A Supplier of my Supplier, is not my Supplier

A model of Identity Federation replaces a model of Federated Identity. Identity Federation establishes a mechanism of trust via intermediaries shared between federated security relams above the level of consumers and services but for them.

1.1.2.3 Authentication and Ownership

Because of ownership boundaries in SOA Ecosystem, authentication is required only in the scope of service interaction. A propagation of an identity of an initial requester through the chain of interacting services is useless and wasting resources.

If a service consumer interacts with the service because being engaged by its own consumer, the service reponses to the service consumer based on their Service Contract regardless the reasons of this interaction.

1.1.2.4 Authorization and Ownership

Because of ownership boundaries in SOA Ecosystem, authorization is required only in the scope of service interaction. A consumer does not have any access rights to the service and cannot acquire them in any other way than via Service Contract. An implementation mechanism of granting agreed access rights may vary.

A propagation of access rights of an initial requester through the chain of interacting services is useless and constitutes a confidentiality violation.

1.1.2.5 Confidentiality and Ownership

Each security realm may have its own confidentiality policies for service communication and execution within individual ownership boundaries and for the individual service interaction case. Particular policies are regulated by an individual Service Contract.

1.1.2.6 Integrity and Ownership

Each security realm may have its own integrity policies for service communication within individual ownership boundaries and for and for the individual service interaction case. Particular policies are regulated by an individual Service Contract.

1.1.2.7 Non-repudiation and Ownership

Each service may establish its own policies for non-repudiation for its consumers. One service is not obliged to preserve non-repudiation policies of its own consumer or another service if this obligation is not specified in the Service Contract.

1.1.3 Security Threats for Services

Enumeration of threads with no explanations. Only types of threads specific to SOA services should be elaborated. [A Web specific threat like Denile Attack/Replay Attack or common threats like Message Alteration, Message Interception, Spoofing, Man in the middle – they are not SOA specific]. IMO, only False Repudiation has specifics for SOA because of Service Contract.

- 1.1.4 Security Responses – not SOA specific and not needed

1.1.5 Architectural Implications of SOA Security

as appropriate

soa-rm-ra message