by Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmeidel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg
Security requirements become more complex in the distributed system landscape of an SOA.
Part of the Industrial SOA article series
Security requirements are usually relatively easy to manage when using local restrictions in conventional closed systems. They become more complex in the distributed system landscape of an SOA. Not limited to only an application or an application domain anymore, security must work across a range of applications and business processes.
Numerous security standards have been created in order to realize these comprehensive security requirements. These include WS-SecurityPolicy, WS-Trust, XML Encryption, XKMS, XML Signature, WS-Federation, WS-SecureConversation, SAML1, SAML2, and many more. Currently, no product or open source framework can fully support all of these standards. In our experience, incompatibilities arise whenever an SOA product or deployed Web service framework needs to communicate outside of its small ecosystem.
Not surprisingly, project managers who are confronted with increasing expenses tend to start looking for viable alternatives. They then usually choose to develop inflexible solutions in-house that can quickly implement risky anti-patterns, such as transferring usernames and passwords within the functional payload. The variety of different standards makes it difficult to formulate a clear understanding of the available security standards and internal product dependencies, in light of the individual restrictions to designing a well-secured system.
Our aim is to provide IT experts and SOA architects with tips on how to handle security responsibly, using tried and true best practices as a basis.
Security plays a crucial role due to SOA's extensively networked nature, yet is not required by all of the different types of applications and architecture layers to the same degree. Defining both internal and external security requirements for the entire organization and its individual departments by conceptually developing the implementation is therefore important.
At the beginning of an SOA project, a company-wide risk assessment is carried out to gauge the likelihood of a particular kind of damage occurring and the negative effects that could result. The required effort and performance strain posed by each security solution can then be weighed against the necessary and acceptable security risks, since security is ultimately a financial consideration.
In addition to the risk assessment, the current legal landscape also has an impact on the security architecture. Now that management may be held personally responsible for failures or insufficient risk provisioning, security is becoming more of an issue for individual employees. A flexible and coordinated security architecture that meets the requirements of the security guidelines, such as ISO 27001 [REF-1] or the BSI Standard 100 [REF-2] for Germany's public sector, is therefore an important aspect of an SOA.
In information security, potential threats are categorized based on whether they compromise availability, confidentiality, or integrity. Loss of authenticity is also a factor when transferring data and document structures, which has particular significance within an SOA [REF-2]. Each characteristic is briefly defined:
The service (process, application, system) is available to the service consumer at the required time as per the agreement, without any negative impact on the business.
Defined as protection against unauthorized access to confidential information, confidentiality becomes highly important when transferring information that can't be made publicly available.
Also referred to as reliability, all message text from the provider is guaranteed to reach the consumer unchanged, and vice versa.
The user is who he or she claims to be and is not an anonymous entity.
Service-oriented business processes are generally distributed and realized across domains, which produces a certain dependency where availability is concerned.
Services in service-oriented architectures are usually made available in a network domain that is generally protected. Business services that are usually made available to a wide audience within or outside of an organization tend to be subject to common Internet attacks like denial-of-service (DoS). This type of threat is usually mitigated by network measures on the TCP/IP levels. These measures can include IP checks, measuring call frequency, and blocking whenever a threshold becomes exceeded. However, this means that the flooding of application services and relevant HTTP servlet with SOAP protocol calls therefore cannot be completely prevented.
As a typical security variant for services that are made available to a limited circle of users via the Internet, the SSL protocol is often used in conjunction with X.509 client certificates. The circle of users is thereby reduced to the holders of the certificate that was explicitly released for this purpose to decrease the potential of Internet threats.
Public SOA interfaces usually need to be available around the clock without fail. Ensuring this maximum level of availability has made equipping Web services with the pattern of loose coupling to enable stateless implementation essential. The SOA infrastructure can then be kept much simpler, with scalability and cluster capability more easily implementable.
Using a highly available ESB product as an "entry point" for service calls can help achieve a strong decoupling, and alleviate the asynchronous, queue-based, and time-delayed processing of services in the background. This approach makes maintaining continuous availability for system implementation more attainable, with the beneficial side effect of simplifying the maintenance of all of the systems connected in the SOA. The DevOps interaction [REF-4] can be taken as an example.
Confidentiality is an important aspect of information security that protects against the unauthorized disclosure of information. Encryption and rights or access management are the primary techniques for maintaining confidentiality in information technology.
Confidentiality, or protection against unauthorized access to sensitive data, is achieved through encryption. Encryption (coding) [REF-5] is defined as the transformation of a plain-text message into a secret message with the help of a "key" that is only decipherable to those who have the key in their possession. Due to the difficulty involved in passing keys around while maintaining their secrecy, the asynchronous RSA process [REF-6] that employs both a private key and a public key has dominated.
Efficient key management is required in SOA infrastructures, since message keys need to be provided for encryption (confidentiality) and signing (authenticity). Unfortunately, keys are stored haphazardly in most infrastructures and can become distributed across the entire landscape. This indiscriminate circulation can lead to repeated failures, since issued key certificates have an expiration date and administrators can lose track of where keys are stored and when to renew them. Implemented in well-structured SOA infrastructures, central key management is facilitated by services or security agents using the XML Key Management Specification (XKMS) [REF-7].
Using the SSL for SOAP protocol security is incompatible with the goal of end-to-end security, since only the path between the caller and the HTTP server is secured. Within one of the stopover points, which is often an ESB or a BPEL or BPMN engine, the message content is unencrypted and can therefore be seen or modified by unauthorized persons. SSL still remains a popular choice for external consumers and public business services due to its easy-to-use operations. Internally, however, technical message encryption is usually not performed due to deficiencies in the established guidelines.
End-to-end security is always necessary for highly sensitive data and requires not only the connection protocol but also the SOAP or REST message itself to be encrypted, as in SSL. Message (payload) encryption often causes problems within SOA infrastructures, since the content cannot be used for logic control like content-based routing. Encrypting a part of the critical and sensitive content, such as the element with only the provisioning data, has consequently become proven as a best practice.
The WS-Security standard can provide the necessary framework for partial message encryption and signing in order to prove the authenticity of the originator, although the scope and complexity of the SOAP will also increase considerably. This is why security is typically realized using the proxy pattern and the infrastructure's centrally implemented security agents. In most cases, XML security gateways provided by Corisecio, Layer 7, and Vordel are used.
Access to sensitive and encrypted content must be implemented in an interoperable SOA by a central roles and rights system, for which the eXtensible Access Control Markup Language (XACML) by OASIS defines a standard. Access control to resources, or who is permitted to do what and when, is described to authorized users in a standardized fashion.
In a typical SOA-XACML deployment scenario, permission to access a service action or request a resource via a centrally located rights service (Access Control Service) is granted. A proxy is ideally interconnected to the service as a security agent, which is denoted as a Policy Enforcement Point (PEP) in security terminology.
Before access is provided, the PEP is identified in the XACML format via the centrally configured rights service or Policy Decision Point (PDP), which determines the access attributes that are to be used according using defined XACML rules. The answer is returned to the agent (PEP) in XACML format, and the service decides how the rights attributes can be concretely implemented.
Ensuring the completeness and immutability of a message is easiest when it is sealed. A broken seal indicates that the message has been changed and requires the receiver to log and reject the message. This type of seal is technically called a Digital Signature and is produced in two steps. The first step is to use a secure hash algorithm, which is a unique value calculated from the message as an input parameter or Message Digest. The Secure Hash Algorithm (SHA1, standardized in RFC3174) has established itself for the calculation.
In the second step, the digest is encrypted with the private key and linked to the certificate and the sender's message by implementing the procedure defined in the W3C XML Signature Syntax and Processing and Encryption Specification. Fortunately, there is no programming with complex APIs when using a Web service stack, such as, for example, Metro, CXF, a high-value ESB or a policy-based security solution in ideal situations.
The term "authenticity" is defined as the property that ensures that a communication participant is the person he or she claims to be. As current SOA environments tend to lack thoroughness when verifying authenticity, we will present various ways in which a lack of authenticity can impact an SOA as well as suggest several solutions.
When faced with an applicable security requirement under time constraints, SOA developers can program security aspects into services hastily without much consideration of the technical implications. A frequently noted programming error is providing only the authentication mechanism with username and password security, as stated in the Web Service Security specification (WSS). This is not usually a problem if only the initial service call is affected.
However, services should be orchestrated for processes such as BPEL or BPMN 2 to improve flexibility, which falls into a complex call chain. Username and password security would mean that passwords, in addition to the usernames, would need to be kept in plain text or identified in another way in every service of the business process. These circumstances are unacceptable in terms of administration and security, which raises the question of how a security context can be continuously upheld through the process landscape without renewed password entry.
As a prerequisite for stable authentication, all users of the services who need to be secured should have a unique ID, whether they are people or service components. The "certificate and token-based" security process has become primarily established for transferring caller identity in the field of SOA, and also increasingly in social Web applications. This process involves a user using an SSO-secured portal or a Secure Token Service (STS) [REF-8] to log into a central authentication service that checks the user's credentials via the connected Access Manager. This can be performed through password entry, certificate, chip card, or biometric identification mechanisms.
The authentication service uses the STS to create the desired token, which can be an X.509 certificate, a Kerberos ticket, a OAuth token, or even an SAML assertion, which is then packaged in the standardized Security Assertion Markup Language (SAML) security exchange format [REF-9]. The package includes the user identity or "subject," which is then passed on for security querying and logging from the entry point until the end system.
SAML therefore standardizes the XML security structure that can then be used for exchanging security information both inside and outside of the Web Service Security specification, in the WSS SOAP header. In regards to security, the interoperability provided by SAML allows for the setting up of cross-organization security communications, which is why security with SAML and an STS should be anchored in the architecture specification from the very beginning.
In connection with the SAML, the WS-Security standard has established itself for the transferring of identities within SOAP messages. This standard describes how a standardized XML structure is packaged with identification information and transferred in an SOAP header.
A question arises if a service uses one of the described standard mechanisms, which is neutrally incorporated for the functional service implementer and deals with upstream security tasks, to implement the security guidelines. How does the functional service implementation or component receive relevant user information? This is required, for example, if the implementing component can only return or change data assigned to the user for functional reasons, such as access to a service on a database that ultimately requires the "correct" user.
As previously mentioned, the transfer of the username in the payload that is parallel to the security header is the most ineffective method yet the most common. The security context must be conveyed into the functional component implementation. Ideally, the service itself should implement the Service Lifecycle interface as a JAVA EE component [REF-10], .NET component, spring component, or as an agent.
The security context is automatically propagated in accordance with the configuration. Although this process may appear logical, this design principle is violated on a regular basis and the username is often transferred into the application in parallel, for example as a service or method argument.
The mixing of service implementations with security aspects is problematic. Security-related functional logic and technical logic should be strictly separated as per the principle of separation of concerns. The skills necessary for these logical aspects are very different from those required for service programming, which is why mixing them would lead to services that are difficult to maintain.
Therefore, a clear separation between application and security logic must be made on all levels when establishing an SOA security infrastructure. This cross-sectional aspect can then be mostly realized by implementing the facade, proxy, or wrapper design patterns, or by using policies. This allows the functional logic to be isolated when implementing a service and possibly also enclosed and configured with different security implementations, if permitted by the requirement.
Since we consider this principle to be important for security realization, the following section explores how security aspects can be implemented in isolation through a policy-based security architecture.
Policy-based management (PBM) as shown in Figure 1 is increasingly dominating as cross-sectional security management, in addition to implicit security in the application components such as security in the WS stack. This is due to the aspect-based security guidelines that are difficult to maintain in the systems that are becoming increasingly complex even in an SOA environment.
Generally, PBM denotes the whole cross-sectional IT system management as well as its configuration using policies and agents. Policies define codes of behavior and are mostly created in a central repository and stored parallel to the application or service. The rules included in the policies are then implemented at the security-relevant points, such as on Web services, BPEL, and so forth, by agents and gateways. If there is an encryption policy, which is delivered dynamically from the policy decision point (PDP) to the agent, an agent positioned in the Web service encrypts the SOAP message with the information given.
In this case, the Web service itself doesn't have to implement security or configure complex security artifacts in the Java EE deployment descriptors. If the security guidelines are changed, the Web service does not need to be adapted, redeployed, or readjusted. Typical products are the IBM Tivoli Security Operations Manager, Oracle's Web Service Manager (OWSM), and the integrated policy management in the Open Source Talend ESB Suite.
Within the PBM, the Policy Enforcement Point (PEP) is responsible for the interpretation and implementation of authorization decisions in the system or service. The eXtensible Access Control Markup Language (XACML) has established itself as the standard language for access control requests. This is also referred to within SAML, as XACML defines SAML profiles, for exchanging authorization information, which facilitates the connection of a central access management component.
The PEP is implemented through security gateways or agent concepts and within the runtime components positioned between the caller and the executor (Figure 2). They create the configured and required security features dynamically via the Policy Decision Point (PDP) of the central policy repository, and execute them before the actual service call.
In addition to authentication, authorization, and encryption, the agents and gateways can also signal SOAP messages and perform logging actions. The policies are usually described by the XML standard WS policy [REF-11] and graphically maintained in the application administrators' central governance repository, and not by the SOA developer. This component is denoted as the Policy Administration Point (PAP).
The Policy Decision Point (PDP) denotes the component that makes the authorization decisions using the provided security policies. The decision point usually receives messages from agents or a gateway (PEP) and identifies the policy to be used from a repository. The PDP also identifies and rectifies runtime conflicts in the different policies that are available. The policy decision point can therefore also be denoted as the legislative power within the access management.
After changes or extensions, the policies are distributed by a push or pull mechanism depending on the requirement. Using the push method is preferable, by which the changes can be conveyed from the administration server to the PDP. As there is no physical service deployment of the changes to a policy through PBM, a governance-supporting administration component, or Policy Administration Point (PAP), with workflow mechanisms that include time-dependent distribution and approval routines per rollout and activation is necessary.
Using the agent concept has the undesirable side effect of needing to be implanted into the call pipeline of each service during deployment. The simplified concept of security gateways is therefore often used in addition to the agent concept. Security is implemented through an upstream, centrally positioned security gateway as a proxy component, which intercepts all calls, executes the policies, and transfers to the original service. Although this concept is not quite as robust as the agent concept in terms of security, its security administration is very simple:
The RSA asymmetric cryptography system is usually used to verify and ensure authenticity, while public keys are managed in a Public Key Infrastructure (PKI). It seems reasonable to manage keys using the corresponding services within SOAs, as opposed to storing them in multiple locally distributed places in the file system or in the application servers that are operated in parallel.
It is for this exact reason that the XML Key Management Specification (XKMS) [REF-7] was defined by the World Wide Web Consortium, as this specification defines a protocol that provides the functions of a PKI for services. XKMS consists of two parts. XML Key Information Service Specification (X-KISS) defines how the key is searched for, obtained, and validated, while the XML Key Registration Service Specification (X-KRSS) specifies how the key is registered per service. As previously mentioned, keys are freely dispersed throughout the file system and become very difficult to properly administer if XKMS is not applied.
The SOA security standards covered can only be used to a limited extent in the REST [REF-12] architectural style. Applying the REST service style primarily concerns resource-based URL services that use known HTTP protocol verbs such as GET, POST, and DELETE, meaning the same security concepts are to be used for REST Web services as for standard Web applications.
Due to its broad Internet support, OAuth 2.0 [REF-13] is commonly used as a token service and for authorization for Web applications, as well as for resource-based REST services. However, the token provided must be exchangeable for interoperable communications between Web applications and back-end SOAP or REST services. The token can be easily converted or validated with a Secure Token Service (STS [REF-8], as an infrastructure element) in the architecture, and federated security can therefore be implemented across domain and technology borders.
We have described several security solutions that can improve on current methods to ensure the properties of availability, confidentiality, integrity, and authenticity. Security solutions are accompanied by increased complexity and the tendency to reduce performance. This article focuses on common issues, as we are fully aware that comprehensive security is difficult without security federation, identity management (IdM), and trust servers.
It is important to strictly isolate the security aspects in both the team and the source code. Taking security too lightly and implementing it weakly, for instance with username/password pairs which are passed on in all services, can have disastrous consequences. The complexity of a security architecture as a security aspect has been shown to be able to be isolated and managed effectively outside of the service implementation, using policy-based architecture.
[REF-3] Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg: "Rent your Car – Service-oriented," Java Magazine, 11/2008