Security Model Details

This is the second installment of yesterday’s post introducing a Formal SOA Security Model. Let’s drill further down into each of the dimensions of the model.

Security Aspects

Authentication

Authentication is the cornerstone of every security model and implementation. In most cases it involves establishing principal’s identity with a specified level of confidence. From security point of view, principal is any entity, such as human, process, component or external system, which is requesting access to secured resources. Identity by definition is unique, as in Highlander: there can be only one! However sometimes it is not necessary to narrow down the set of possible principles to a single one and it might be enough to narrow it down to a certain class, such as Platinum Members or Employees.

Authorization

Authorization usually happens after and in the context of authentication. It involves determining, by evaluating applicable access control information, whether a subject is allowed to have the specified types of access to a particular resource. Once a subject is authenticated, it may be authorized to perform different types of access.

Integrity

Integrity is the property that data has not been modified. In the context of a single message it means that the content is exactly the same as was sent by the originator, this is typically achived through digital signatures. In the context of message exchange it also means that all the messages were received exactly once in the same order as they were sent, which would require a assurances of relible messaging in addition to signatures.

Confidentiality

Confidentiality is the property that data is not made available to unauthorized individuals, entities, or processes. Typically confidentiality is achieved through encryption, however there are other options including steganography and winnowing.

Accountability

Accountability is the ability to associate historical actions and events with principals. It is the only aspect that happens after the event took place. Various applications requre different degrees of accountability including: simple recording of events that can be used for billing or data mining, auditing that would allow to prove that certain events took place to an internal party, and nonrepudiation when a transaction and its origin can be proven to an independent third party.

Identity Management

Identity Management deals with provisioning, reconciliation and federation of principal’s identities and security attributes across multiple security domains. It is also closely related with trust.

Security Policies

In this context a Policy is a set of externalized business rules that govern behavior of a computer system. Policies can define all other security aspects and can be attached to all SOA participants, including clients, services, and infrastructure. Policies are used to describe a broad range of service requirements and capabilities.

Security Facets

Transport Security

Transport-level security addresses protection of information while in transit between two interacting parties. It is the easiest to achieve: the industry has a set of existing and widely accepted transport-layer security mechanisms, such as SSL (Secure Sockets Layer), TLS (Transport Layer Security).

Message Security

Message-level security addresses protection of individual requests as they are routed between service consumers, intermediaries, and providers. Message-level security for SOAP based communication is defined in the emerging WS-Security standard.

Application Security

Application-level security includes all security mechanisms that are coupled directly with the application logic. It is the most versatile security facet that is needed to handle application-specific security constraints, such as “a director can approve purchase orders up to $50,000 and higher amounts require a VP approval.”
A key difference between application security versus transport and message level security is that the latter can be provided by the infrastructure transparently to the application, while the former has to be coded into it. However infrastructure can provide means, such as easy access to the security context and policies, to facilitate implementation of application-level security.

Asset (Data) Security

Asset-level security refers to protecting any assets used by and encapsulated in the service. The most common asset that requires protection is application data, but other types of assets such as devices and capabilities should also be taken into consideration when building a comprehensive security solution.

Knowledge Security

Knowledge security refers to protecting information describing your services, applications and other sensitive assets. The types of information that require protection include: service WSDLs and schemas, end points, binding and protocol specifications, service descriptions and taxonomies, policy repositories, etc.

Control Security

Control security includes all security mechanisms that are in place to protect the governance solution itself. These include protection against tampering with the governance data, bypassing workflows, attacks on the governance infrastructure and exploitation of service management capabilities.

Support Levels

	Provides: solution provides this functionality, transparently or with minimal support from service consumers and providers.
	Supports: solution facilitates the implementation of this functionality by service consumers and providers.
	Allows: solution does not prevent or hinder the implementation of this functionality by service consumers and providers.
	Does not address: this functionality is outside of the scope of the solution.