According to Kanneganti and Chodavarapu (2008), new security approaches for SOA include message level security, security as a service and policy-driven security.
4.5.1 Message-level security
Message-level security enables applications to protect different parts of a message differently, ensuring that those parts can be read by appropriate parties only (Kanneganti & Chodavarapu, 2008). Message-level security is very important for intermediaries because it can protect the messages sent through intermediaries. This means message-level security ensures that intermediaries do not read or intercept the transferred message.
According to Kanneganti (2008), message-level security supports the SOA
requirement of confidentiality and integrity. Figure 4.4 (below) illustrates a process whereby Calvin sends payment information to the bank via the SOA-based loan application. The request that Calvin sends from the loan application has 2
messages, one for Company A, and one for Bank A. The message meant for Bank A should not be exposed to intermediaries such as the payload service. Therefore, a confidentiality solution is needed. Figure 4.4 (below) illustrates the way
message-level security can implement different encryptions for difference messages.
63
Figure 4.4 Bank A message and Company A message in different folders
Message-level-security allows Calvin to send two messages directed to two recipients. When he sends the message, the payload service, hosted on servers located at Company A‟s head office, is able to open and read one part of the message. The other message is intended for Bank A. Therefore, payload service will not be able to read the contents of that message.
4.5.2 Security-as-a-service (SAAS)
Section 2.1.1 and section 2.1.2 of this chapter outline challenges in authenticating and authorising services in SOA. They also outline that challenges are raised because services can be used by applications or services within an organisation, third party applications, or services outside of the organisation. Security-as-a-service is a solution to this challenge.
Security-as-a-service, known as „security services‟, allows applications to
authenticate, authorise, and log messages (Kanneganti & Chodavarapu, 2008).
Furthermore, security services allow applications to encrypt and decrypt messages, and sign and verify digital signatures for enforcing message
confidentiality and integrity (Kanneganti & Chodavarapu, 2008). Kanneganti &
Chodavarapu (2008) also note that standards such as Security Assertion Markup Language (SAML) and WS-Trust can be used to implement security services.
Figure 4.5 (below) illustrates how security services can be implemented by Bank A and Company A.
64
Figure 4.5 Implementation of security-as-service by Company A and Bank A
According to Kanneganti and Chodavarapu (2008), security services can be implemented as an infrastructure service offered by an Enterprise Service Bus (ESB). In Figure 4.5, Bank A and Company A provides security services by
implementing ESBs. Implementing security services allows application developers to focus on business logic rather than security. However, applications or services might need to know the context in which they are being used. For example,
services needs to know if they are being utilised by authenticated users, and those users are authorised to perform the requested functionality. Therefore, services need information from the ESB. Since security logic is being handled and
executed by ESB, security requirements can evolve with business needs, without affecting application or service logic.
4.5.3 Policy-driven security
Security solutions are not applicable all the time because different organisations have different security requirements. Therefore, application rules and principles should be developed as security policies within an organisation. According to Kanneganti and Chodavarapu (2008), development of security policies should not affect SOA principles, such as design and loose coupling. Furthermore, Kanneganti and Chodavarapu (2008) suggest that services be usable with other service consumers regardless of the technology or of the implemented security policies.
Policies in SOA define rules and principles that affect services during design time and run-time (Stanek, 2006). Furthermore, policies enforce specific standards and behaviours at run-time. Policy-driven security is a new approach that makes SOA
65
security policies easy to develop and manage (Kanneganti & Chodavarapu, 2008).
This approach allows an organisation‟s security requirements to be separately declared from business logic. Figure 4.6 (below) illustrates how policy-driven security can be implemented in a loan application scenario outlined in Chapter 3.
Figure 4.6 Policy-Driven security by Company A
Figure 4.6 outlines how Company A can implement policy-driven security. The security policy outlined in Figure 4.6 includes security requirements and security mechanisms. Security policy is enforced when Company A‟s services communicate with external services via the Internet. Mechanisms and requirements in a security policy are defined by Company A based on organisational policies. They are defined by Company A in a security policy.
Section 4.4.1 outlines information security challenges for SOA. This section outlines solutions to these challenges. These include message-level security, security-as-a-service and policy-driven security. The solutions are as follows:
Policy-driven security is a new approach that makes SOA security policies easy to develop and manage.
Security-as-a-service, known as security services, allows applications to authenticate, authorise, and log messages.
Message-level security enables applications to protect different parts of a message differently, ensuring that those parts can be read by appropriate parties only.
66
The reason information security is so important is because there is risk. Risk management is the process of assessing the risks and implementing appropriate countermeasures to reduce the risk to an acceptable level (Stoneburner et al., 2002).