OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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 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 Responsesnot SOA specific and not needed

1.1.5 Architectural Implications of SOA Security

as appropriate



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]