Secure Service-Oriented Computing
Secure services are essentially integrated services and security technologies. Our discussion of secure services will focus mainly on secure web services.
Secure services essentially incorporate security into services technologies. For example, what credentials should an agent have to invoke a web service? What credentials should a web service have to invoke another web service? Should all web service descriptions be visible to every agent? How can access control be enforced on web service descriptions? How can security be incorporated into the service-oriented architectures? What are the security standards being proposed by W3C and OASIS? We will explore answers to these questions in this part. This chapter provides a high level overview of secure services technologies and the details will be elaborated on in the remaining chapters in this part.
The organization of this chapter is as follows. Secure services are discussed in section 2. Secure service-oriented computing is discussed in section 3. Secure SOA and web services, which are at the heart of secure web services technologies, are will be discussed in section 4. Security for service-oriented analysis and design (SSOAD) is discussed in section 5. Federated identity management, which is a key aspect of web services, is discussed in section 6. Some of our research on secure web services, which is essentially a delegation model for web services, is discussed in section 7. Security standards for web services are discussed in section 8. Section 9 is the chapter is summary. Figure 1 illustrates the topics discussed in this chapter.
Figure 1. Aspects of Secure SOE.
2. Secure Services
To best illustrate the notion of a secure service, we will use the example of a healthcare application. Suppose we want to get our credit report. We will contact a service provider that gets credit reports. First we should have the access to read the existence of such a service provider. Once we know about this service provider, we invoke this service provider. The service provider should ensure that we have the access to this particular service. Furthermore, it should ensure that the information about the credit it retrieves can be read by us. In order to do this, we also have to send some identification information to the service provider. If the service is not secure then anyone can obtain anyone's credit reports. Similarly, to obtain healthcare reports, the secure service provider should ensure that the person requesting the service has the appropriate credentials to read the healthcare records. Furthermore, the owner of the healthcare records may enforce various privacy policies in which case the service provider should only release appropriate information to the consumer. In some cases the consumer may use the service provider to purchase information. The service provider can state its privacy policies and if the consumer agrees with the policies, it can release private information about him/her.
This simple example shows several aspects. One is that the user of the service has to be attested by the service provider. The service provider has to be trusted in the sense one does not want to get service from an unreliable provider. The service provider has to ensure that the user/consumer has the proper credentials to obtain the service and that any information released is something the consumer is authorized to read. The service provider also has to ensure that private information about a person is not released to the consumer. Essentially we need confidentiality, privacy, trust and integrity features to be enforced by the web services. Figure 2 illustrates secure services.
Figure 2. Secure Services.
3. Secure Service-Oriented Computing
As stated in Chapter 2, service-oriented computing is essentially about implementing the services as software. Consider the process of ordering a book from an agency. We go to the catalog published by the agency. The agency has to ensure that we are authorized to read the information about the books; that is, the metadata. We place the order. The agency will then determine which part of the book we can read, if any. The appropriate parts of the book are then released to us (the consumer). Now, this secure service can be implemented in software as follows. The customer checks the web site of the agency and finds the book and places the order. The web site will only display the books the customer is authorized to see. The secure order management service implemented by the agency takes the order, sends a message to the warehouse service and requests the book. The warehouse service then finds that the book is in its inventory and sends a message to the order management service. The warehouse is where they would invoke the security service and then send the appropriate parts of the book to the shipping service. The shipping service then ships the book to the customer. If the book has to be displayed electronically then appropriate parts of the book may be displayed through the order management service. So there is a composition of secure services starting from the order management service, the warehouse service and the shipping service. These three services provide the customer with what he wants. All these services have to enforce appropriate security controls. In implementing the secure services, we need to enforce activation, access control, trust management and privacy control. In addition the documents that the customer gets must be authentic which means integrity has to be maintained.
As we have stated in Chapter 2, the unit of computing for service-oriented computing is a service. The challenges are to represent the services, the relationship between the services and the security levels of the services. For example, if service A is unclassified and service B is secret, then what should be the security level of the service that is imposed of A and B? Furthermore, if a consumer can invoke service A and cannot invoke service B, then should he be able to invoke the composition of A and B? The various security standards that have been developed provide solutions to some of the questions. Note that much of the work on secure services has focused on discretionary security. Multilevel security for web services has received little attention. Our focus will also be on discretionary security for web services. Figure 3 illustrates the notion of secure service-oriented computing.
Figure 3. Secure Services Computing.
4. Secure SOA and Web Services
Chapter 2 discussed the SOA paradigm and stated that our focus on SOA implementation will be through web services. Therefore, our realization of secure SOA will be through secure web services. The basic SOA is essentially about a consumer requesting a service from the University Description, Discovery and Integration, UDDI. The UDDI sends the name/address of the service. The consumer then gets this service from the service provider. With secure SOA we have to ensure that the communication between the consumer, the UDDI and the service provider is secure. Furthermore, only authorized consumers can get the required services. Furthermore, the SOAP messages that are encoded in XML have to be secure XML encryption standard provides confidentiality while XML signature standard provides integrity. Both XML encryption and XML signature are standards provided by W3C.
Security and authorization specifications for web services are based on XML. Various types of controls have been proposed including access control, rights, assertions, and protection. We describe some of them in the next section. The list of specifications includes the following:
- extensible Access Control Markup Language (XACML)
- eXtensible Rights Markup Language (XrML)
- Security Assertion Markup Language (SAML)
- Service Protection Markup Language (SPML)
- Web Services Security (WSS)
- XML Common Biometric Format (XCBF)
- XML Key Management Specification (XKMS)
OASIS is a key standards organization promoting security standards for web services. It is a not-for-profit, global consortium that drives the development, convergence, and adoption of e-business standards. Two prominent standards provided by OASIS are XACML and SAML. XACML (eXtensible Access Control Markup Language) provides fine grained control of authorized activities, the effect of characteristics of the access requestor, the protocol over which the request is made, authorization based on classes of activities, and content introspection. SAML (Security Assertions Markup Language) is an XML framework for exchanging authentication and authorization information. We discuss details of secure web services in the ensuing chapters. Figure 4 illustrates the notion of secure web services architecture.
Figure 4. Secure SOA.
5. Secure Service-Oriented Design and Analysis
We were the first to examine secure object-oriented design and analysis based on the OMT model. We developed a secure object model, secure dynamic model and secure functional model. Since then several researchers have developed secure OODA methodologies based on objects. With the SODA approach, the goal is to identity the services and the relationships between the services for an application. For example the services for the book order application will include order monument service, warehouse service and shipping service. These services have associated with them various security policies. The challenge is to capture the services and the policies in an appropriate modeling language.
There is little work on secure service-oriented design and analyses (S-SODA). In Chapter 13 we will make an attempt based on the developments with secure OODA. In particular, we will examine the SODA principles that we discussed in Chapter 4 and examine security for SODA. It should be noted as security for web services as well as SODA methodologies mature, we will see better approaches or S-SODA. Figure 5 illustrates the concepts involved in secure SODA.
Figure 5. Secure SODA.
6. Federated Identity Management
Identity management, usually also referred to as federated identity management, is closely intertwined with web services. Users as well as web services have to be authenticated before accessing resources. Single sign-on is the popular solution where one time sign-on gives a user or a services access to the various resources. Furthermore, SAML currently provides justification facilities for web services. However with regulatory requirements for e-business, one needs a stronger mechanism for authentication and this mechanism has come to be known as identity management.
Federated identity "describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains." The goal is to ensure that users of one domain take advantage of all the technologies offered by another domain in a seamless manner. Note that federation is about organizations working together to carry out a task, such as B2B operations, or solve a particular problem. While the ideas has been around for many years, it is only recently with the emerging standards for web services that we can now develop realistic federations. In such federations, access to the resources by users has to be managed without burdening the user.
Figure 6. Identity Management.
7. Access Control
Security standards for services have essentially been developed by W3C and Security SIS. Standards for Web Services 1.0 essentially consisted of a service consumer requesting a service from the service provider who then provides the service. The XML messages that are exchanged in the SOAP protocols are encrypted and signed to provide confidentiality and integrity. This goal is to encrypt the message to provide confidentiality and sign the message to ensure that the message is not tampered with. XML Key Management and XML Encryption have played a major role in providing confidentiality and integrity of the messages.
Web Services 2.0 has resulted in several additional standards including secure messaging, reliability and identity management. In addition, standards for policy management such as WS-Policy, standards for access control such as XACML and standards for security assertions such as SAML have also been developed. We will discuss these standards in Chapter 9 as well as in Chapter 13. Figure 7 illustrates access control model for web services.
Figure 7. Access Control.
8. Delegation Model
For many applications, the access control models are not sufficient. For example, in the case of composite web services, one web service, S1, may invoke another web service, S2. In such an invocation, S1's privileges will be enforced and not those of the user U who invoked S1. This means that the information that is returned to U may be something the user is not authorized to know. To avoid such security compromises, a user U may have to delegate its privileges to S1 so that U's privileges are used when S1 invokes S2. Such an invocation is governed by the delegation models that are utilized.
Another security concern for composite web services is information flow. That is, when web services are composed, it is critical that there is no information flow from a high level to a low level. Our research is focusing on various aspects of web services security including the delegation models and information flows for web service composition and will be described in Chapter 13. Figure 8 illustrates the delegation model.
Figure 8. Delegation Model.
This chapter provided an overview of secure service-oriented computing. We first discussed what is meant by secure services. Next, we discussed high-level concepts in secure service-oriented computing. Realizing service-oriented information systems through secure service-oriented architectures and web services was discussed next. Then we discussed how secure service-oriented information systems may be designed. Finally, we discussed aspects of federated identity management, delegation of web services and security standards. Details of the various concepts introduced in this chapter will be elaborated on in chapters 9, 10, 11, 12, and 13.
Security for services computing is just beginning. Furthermore, we cannot now back away from services computing. It has been strongly adopted by almost every industry including the US Government. Therefore, there are endless opportunities for investigating security for services computing. We aim to provide the direction. We cannot discuss all of the standards due to the rapid development of these standards. Therefore, we urge the reader to keep up with the developments, especially with W3C and OASIS.
From Secure Semantic Service-Oriented Systems by Bhavani Thuraisingham. New York: Auerbach Publications, 2011.