Transcription

1 MODELING AND ANALYSIS OF SECURITY STANDARDS FOR WEB SERVICES AND CLOUD COMPUTING by Ola Ajaj A Dissertation Submitted to the Faculty of the College of Engineering and Computer Science in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Florida Atlantic University Boca Raton, FL December 2013

2 Copyright by Ola Ajaj 2013 ii

3

4 ACKNOWLEDGEMENTS I would like to thank my advisor, Dr. Eduardo B. Fernandez, for his guidance during these years. He has been a true mentor by supporting me during my research in. I would also like to express my gratitude to my committee members, Dr. Mohammad Ilyas, Dr. Maria Petrie, Dr. Mihaela Cardei,, and the members of the Secure Systems Research Group for all their advice and constructive comments of this dissertation. I dedicate this degree and I wish to express deep appreciation to my family and friends for their continuous support and encouragement throughout this Ph.D. s program; without which I wouldn t make it and so I am unconditionally appreciative. iv

5 ABSTRACT Author: Title: Institution: Dissertation Advisor: Degree: Ola Ajaj Modeling and Analysis of Security Standards for Web Services and Cloud Computing Florida Atlantic University Dr. Eduardo B. Fernandez Doctor of Philosophy Year: 2013 Cloud Computing is a new computing model consists of a large pool of hardware and software resources on remote datacenters that are accessed through the Internet. Cloud Computing faces significant obstacles to its acceptance, such as security, virtualization, and lack of standardization. For Cloud standards, there is a long debate about their role, and more demands for Cloud standards are put on the table. The Cloud standardization landscape is so ambiguous. To model and analyze security standards for Cloud Computing and web services, we have surveyed Cloud standards focusing more on the standards for security, and we classified them by groups of interests. Cloud Computing leverages a number of technologies such as: Web 2.0, virtualization, and Service Oriented Architecture (SOA). SOA uses web services to facilitate the creation of SOA systems by adopting different technologies despite their differences in formats and protocols. Several committees such as W3C and OASIS are developing standards for web services; their standards are rather complex and verbose. We have expressed web v

6 services security standards as patterns to make it easy for designers and users to understand their key points. We have written two patterns for two web services standards; WS-SecureConversation, and WS-Federation. This completed an earlier work we have done on web services standards. We showed relationships between web services security standards and used them to solve major Cloud security issues, such as, authorization and access control, trust, and identity management. Close to web services, we investigated Business Process Execution Language (BPEL), and we addressed security considerations in BPEL and how to enforce them. To see how Cloud vendors look at web services standards, we took Amazon Web Services (AWS) as a case-study. By reviewing AWS documentations, web services security standards are barely mentioned. We highlighted some areas where web services security standards could solve some AWS limitations, and improve AWS security process. Finally, we studied the security guidance of two major Cloud-developing organizations, CSA and NIST. Both missed the quality of attributes offered by web services security standards. We expanded their work and added benefits of adopting web services security standards in securing the Cloud. vi

8 Solution Implementation Implementation Example Resolved Known uses Consequences Related Patterns Conclusion RELATING WEB SERVICES SECURITY STANDARDS Relationships between Web Services Security Standards A pattern for WS-Policy A pattern for WS-Trust A pattern for WS-SecureConversation A pattern for WS-Federation The relationship between WS-policy and WS-Trust The relationships between WS-policy, WS-Trust and WS- SecureConversation Relationships between WS-policy, WS-Trust, WS-SecureConversation and WS-Federation ADDING SECURITY TO BPEL WORKFLOWS OF WEB SERVICES Introduction Background An example for a collaborative business process Threats to the activities Stopping or mitigating the threats Conclusions and Future Work THE NEED FOR CLOUD STANDARDS The Concept of a Standard De jure Standards De facto Standards Consortium Standards Aspects of a Good Standard The Need for Cloud Computing Standards viii

14 1. INTRODUCTION As described by NIST, Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. [Hog11]. Even though there are many advantages to adopting Cloud Computing, there are also some significant obstacles to its acceptance. One important issue is security, followed by virtualization, lack of standardization and Cloud standards adoption. Despite the large amount of active work in developing standards for the Cloud, there is currently a long debate about the role of standards in the Cloud. On one side parties who see the Cloud as a completely new approach that needs a completely new set of standards, and on the other side parties who see the Cloud as a technology built based on existing technologies that already have standards. In one part of this thesis we balanced both parties points of view, defined what is a standard from our perspective, and why do we need standards in Cloud Computing. Even though standards have not been a requirement for the vast growth of the Cloud, more and more demands for Cloud standards are put on the table. The Cloud 1

15 standardization landscape is so ambiguous because there isn t a central body or forum to control the process of standardization, despite the efforts made many people and organizations on that direction. NIST did a good job of listing the standards relevant to Cloud Computing [Nis13a], but their categorization of Cloud Computing standards is like one size fits all, it is not clear, and it is hard for users and researchers to use. To clear the picture of Cloud standards, we surveyed general Cloud standards, we focused more on the standards for security, and we classified them by groups of interests. This should make exploring Cloud standards easier for both users and researchers. Cloud Computing leverages a number of computing models and technologies; such as Service Oriented Architecture (SOA), Web 2.0, virtualization and other Internetbased technologies. This led us to the next point where we explained the relations between Cloud, SOA and web services. We can describe SOA (Service Oriented Architecture) as a loosely coupled set of software services and functions for the purpose of supporting business functions. Those software services and technologies can be assembled and reassembled according to the business requirement. It is an architectural style useful to implement business functions. SOA is mainly applied to business information systems using web services standards and technologies, and is rapidly becoming a standard approach for enterprise IT systems. SOA applies to Cloud Computing at many levels. Generally speaking, Cloud Computing derives its association to SOA by advantage of the characteristic of loosecoupling. This is true since loose-coupling is a key concern within SOA, mostly due to 2

16 the desire to be agnostic to the underlying technology, topology, lifecycle and organization on which any service is implemented in an information system. Moving forward to Cloud Computing and we can see the same objective growing from a business perspective, i.e., being able to create and control services and utilities to solve customers needs, regardless of the location and technology on which those services are implemented. Adding to this, business people are more interested of thinking what services they are offering to their customers and partners not it in the IT or SOA sense of service, but in terms of their business value to the markets. Similarly, they tend to think of the services they consume from business partners as services. To give an example, one company may provide travel services, another company provides financial services, and a third one provides HR services. Leveraging all those business services through the Internet and Cloud Computing is an evolutionary target for all those partners to expand their markets and attracts more customers. SOA was never dependent on one specific technology (including web services) for its success. However, web services standards do facilitate the creation of SOA systems and, therefore, adoption of technology despite their differences in formats and protocols. This led us to study web services and how they could contribute to the growth of SOA and Cloud. Web services intend to provide an application integration technology that can be used over the Internet in a secure, interoperable and trusted manner. Web services in the 3

17 Cloud are very closely related to SaaS, but instead of delivering complete applications over the internet, the service providers provide APIs that enable customers to use functionality over the Internet. Some examples are Google Maps, ADP payroll processing, and credit card processing services. The definition of Web APIs is: an API is typically a defined set of Hypertext Transfer Protocol request messages along with a definition of the structure of response messages, usually expressed in an Extensible Markup Language or JavaScript Object Notation format [Wik13]. How Cloud Computing and web services are related? Well, one important thing that has distinguished WS-* related technologies is that they are standards and have raised a strong community of support, and this has enabled higher qualities of service. But when you need to go beyond that, the web services standards are particularly useful for solving Cloud Computing issues, such as asynchronous messaging, and metadata exchange, security, policies, trust, and federation of identities. In one chapter of this thesis, we used web services security standards to solve major Cloud issues, such as, need for policies, authorization and access control, data protection during transmission, trust, and ID management. Several committees such as W3C and OASIS are developing web services standards. Their standards are rather complex and verbose and it is not easy for designers and users to understand their key points. By expressing web services security mechanisms and standards as patterns, we can verify if an existing product implementing a given security mechanism supports some specific standard [Fer06c]. 4

18 In this thesis we wrote two patterns for two web services standards; WS- SecureConversation, and WS-Federation. Both could be used to solve two major challenges of Cloud which are exchange numerous amount of messages and ID management. This work completed an earlier work we have done before on patterns for web services standards found here [Aja10a, Aja10b]. WS-SecureConversation defines mechanisms for establishing and sharing Security Context Token (SCTs), and deriving keys from security contexts to authenticate messages between parties [Wss07]. The WS-Federation standard defines a framework with additional federation mechanisms that extend these specifications [Wsf09]. Later on the following chapters, we will use those two web services security standards beside other WS-* standards to solve major Cloud issues. All the patterns follow the POSA [Bus06] template and are similar to the style of the security patterns written in [Sch06]. Writing patterns for web services standards for the purpose of writing patterns is not enough, we need to show how they are related to offer a complete solution that is independent, reusable, and flexible. In this thesis we draw a pattern diagram for web services security standards, and explained what degree of dependency a pattern could have with other patterns. We defined better relationships between patterns for web services security standards. In a related subject to web services, we investigated Business Process Execution Language (BPEL). As a web service composition language, BPEL can be a convenient and effective means for application integration over the Internet in typical Business-to- 5

19 Business (B2B) interaction scenarios [Wsb07]. However, for BPEL to keep its promises it is necessary to provide more support for security. Vendors and companies are looking to have their requirements of authentication, integrity and confidentiality satisfied. In this thesis we addressed security considerations in BPEL and how to enforce them. Cloud Computing is a large pool of resources; that we can dynamically manage to scale up and down to match the load, where users pay per usage. The resources include hardware and systems software on remote datacenters that are accessed through the Internet. Key benefits of adopting Cloud Computing are elasticity, multi-tenancy, resource utilization and pay-per-usage. These new features provide what it needs to leverage large infrastructures through virtualization or resource management, but these large pools of resources are not necessarily located in the same country (same physical location) nor even on the same continent, which make it hard to keep track of what resources are used and where. Compliance with data-handling regulations is also difficult to fulfill. In this scenario, auditing is a challengeable task too, since those resources are susceptible to volatility and power outages. Not only these new benefits make it hard or let s say impossible to reuse traditional security, privacy and trust mechanisms in the Cloud, but also, they raise significant issues and concerns that need to be fully addressed. While Cloud adoption is expected to speed up in the coming years, companies are still cautious about the Cloud as the right delivery medium for their services. The dominant concern is security. Since Cloud Computing is a relatively new Computing 6

20 model, where there is a great deal of hesitation about how to achieve security at all levels (e.g., host, virtualization, and data) [Ros12]. The main question whether data is safe in the Cloud, and how they can offer an on-demand service while preserving industry compliance. Enterprises are right to hesitate about investing heavily into the Cloud without some guarantees about protection. The detailed nature of the Cloud is vague and open for attackers, and the virtual nature of the Cloud makes protecting on-demand environments a complex process. Other issues were regarding compliance, privacy and legal matters [Kpm10]. Security concerns are spotted in different areas such as external data storage, dependency on the open public internet, lack of user control, multi-tenancy and integration with internal security. The current form of traditional security mechanisms such as authorization, authentication, trust, privacy, and ID management are still valid for Clouds [Liw09]. We are going to look at some of those Cloud issues and try to solve them using web services security standards. In this work, we make the following contributions: 1. We present a pattern for the WS-SecureConversation (Chapter 2) that described how a web service can authenticate requester messages, how requesters can authenticate services, and how to establish mutually authenticated security contexts. 2. We present a pattern for the WS-Federation (Chapter 3) that describes how to manage and broker the trust relationships in a heterogeneous federated 7

21 environment, including support for federated identities, sharing of attributes, and management of pseudonyms. 3. We define what relationships of web services security standards (Chapter 4) exist between web services security standards. We draw a complete pattern diagram, and then we show what degree of dependency a pattern has with other patterns in details. 4. Adding Security to BPEL workflow of web services (Chapter 5). We have presented an approach that enumerates the threats to a given BPEL process. We consider UML activity diagrams for collaborative business processes and show how to list the possible threats and attacks that could happen in order to define the appropriate and suitable countermeasures to stop or mitigate them. 5. The need for Cloud Computing standards (Chapter 6) aims to solve the confusion about the need for standards in Cloud Computing, which is either urgent, nonexistent, or some wherein between. We start this chapter by trying to define what a standard is, and then we explain what makes a good standard. We end by listing the main factors of why we need standards for Cloud Computing. 6. Survey of security standards for Cloud Computing (Chapter 7). Numerous standards from different organizations are available in the Cloud market. We survey here work on security standards for Cloud Computing and we classify them in groups depending on their functionalities. We also include standards that although not developed for Cloud Computing, have an impact on the use of 8

22 clouds. The Cloud standardization landscape is so ambiguous because there isn t a central body or forum to control the process of standardization. We list the main issues of Cloud Computing standardization. We briefly present some industry efforts. 7. In chapter 8, we take Amazon Web Services (AWS) as a case-study, since Amazon is one of the major Cloud vendors. We intend to see how Cloud vendor look at web services standards, and whether they take them into consideration while offering services. While reviewing AWS documentations, we have noticed Amazon barely mentioning web services security standards as solutions to be considered. We highlight some areas where web services standards could solve some AWS limitations. We identify other spots where AWS can improve its security process by adopting or encouraging users to use web services security standards. 8. Chapter 9 aims to select two major Cloud-developing organizations, which are CSA and NIST, and examine their security guidance of securing the Cloud. We notice both missed the quality of attributes offered by web services standards. We expand their work and added one more dimension of web services security standards. Our addition adds benefits and advantages of adopting web services security standards in securing Cloud Computing. 9. Chapter 10 matches major Cloud security issues with solutions offered by web services security standards, some of which include: message exchange, transport, 9

23 security, reliability, trust, federation of identities. Web services security standards give better solution to the security problem so that Cloud Computing are easier to be accept in the business cases require high protection of the data and information. This thesis is organized as a collection of papers which implies some overlap and repetition of topics. It includes the following chapters: Chapter 2 presents a pattern for the WS-SecureConversation standard of web services. Chapter 3 is for a pattern for the WS-Federation standard for web services. In chapter 4, we present pattern diagram for web services standards. Chapter 5 presents adding Security to BPEL Workflows of Web Services. Chapter 6 describes the need for Cloud Computing standards. Chapter 7 surveys security standards for Cloud Computing, investigates issues for Cloud Computing standardization and proposes solutions using web services security standards. Chapter 8 takes Amazon Web Services (AWS) as a case study and evaluates its security standards, and how web services security standards can add to AWS. Chapter 9 talks about how web services security standards contribute into securing the Cloud. Finally, adopting web services standards in Cloud Computing is the goal for chapter 10. Finally, Chapter 11 is about conclusion and future work. 10

24 2. A PATTERN FOR THE WS-SECURECONVERSATION STANDARD OF WEB SERVICE In this thesis we wrote two patterns for two web services standards; WS- SecureConversation, and WS-Federation. Both could be used later to solve two major challenges of Cloud which are exchange numerous amount of messages and ID management. This work completed an earlier work we have done before on patterns for web services standards found here [Aja10a, Aja10b] Web Services Standards Over time, different languages, mechanisms, and tools have been developed on different software and hardware platforms for specifying and implementing a variety of security mechanisms, such as encryption and access control. In a web service setting, security mechanisms protect the confidentiality and integrity of the data in transit, and the data at rest. Furthermore, protection of the information must not only consider simple two way client-server interactions, but also extend to more complex interactions, as in the case of business process implemented through multiple web services. The need for providing end-to-end security through distributed and heterogeneous security mechanisms called for the development of standards for web services security, with the ultimate goal of making interoperable different implementations of the same security functions. 11

25 Web services technology is being used industry wide to implement interoperable service oriented architectures (SOAs). This technology contains a set of evolving related standards that aims to address SOA goals and challenges. Organizations looking to lower the cost of development and maintenance for their systems, while staying more flexible in terms of capabilities, consider web services standards as a possible solution. A big reason behind adopting Web services standards is their key quality attributes such as interoperability, extensibility, and modifiability [Obr07]. Many organizations are working to create open standards, but the three key organizations are: The Organization for the Advancement of Structured Information Standards (OASIS) whose job is to create the infrastructure and implementation of Web services standards. World Wide Web Consortium (W3C), in charge of (HTTP) XML, SOAP, and other standards. W3C contains many committees whose goals are to build and maintain Web standards (usually described as recommendations ). The Web Services Interoperability Organization (WS-I) provides practical guidance, best practices, and resources for developing interoperable Web services solutions. Web services standards have a significant number of technological companies including Microsoft, IBM, Oracle, BEA and others. Those companies are actively participating on creating web services standards, have fully support them, and have create software components built on interoperable standards, and integrate those components into products. Ultimately, the goal of using web services standards is to build a system by installing products developed by different companies and to allow those products to work together seamlessly. 12

26 One of the goals of Web services standards is to support interoperable machineto-machine interaction over a network. This is accomplished by using XML-based messaging technologies such as: Web Services Description Language (WSDL), the Simple Object Access Protocol (SOAP), and the Universal Description, Discovery, and Integration (UDDI). These, beside any additional new standards, are managed by various standards bodies and entities. The web services security standards originally foreseen by the IBM and Microsoft framework [Ibm02]. [Inn07] published a web services standards overview that has 60 standards classified in 12 categories. [Fer10] did a complete survey of web services security in terms of standards and industrial practice. short is: Web services standards once implemented offer a complete secure solution that in Independent: from the underlying execution technology and application platforms. Extensible: to address new requirements and/or exploit new security technologies. Reusable: Web Services built using web services standards are easy to reuse as appropriate in other services. Flexible: Can accommodate existing heterogeneous mechanisms that is, different encryption algorithms, different access control mechanisms, and so on. Composable: Support for composite applications such as business process flows. Several committees such as W3C and OASIS are developing web services standards. Their standards are rather complex and verbose and it is not easy for designers 13

27 and users to understand their key points. By expressing web services security mechanisms and standards as patterns, we can verify if an existing product implementing a given security mechanism supports some specific standard [Fer06c] A Pattern for the WS-SecureConversation Standard of Web Services Abstract: When using web services, the involved parties need to address two main concerns: first, each party needs to determine if it can trust the credentials of the other party; and second, how to protect their data and how to provide a secure session between the parties. WS-Trust takes care of the first challenge by defining how to establish trust between interacting parties, while WS-Security is in charge of the second part by providing message integrity, confidentiality, and authentication. However, web services exchange multiple messages that increase the overhead of key establishment and decrease performance, which eventually affects business interactions. By defining a shared context among the communicating parties for the lifetime of a communications session that combines secure communications and trusted relationship, we facilitate the process of communication and increase overall performance. This shared context is implemented by the WS-SecureConversation standard, and we present here a pattern for it Introduction Web services interact with users and other web services to conduct business. Those business interactions have different degree of complexity and validity depending on their nature. Some interactions exchange a large number of messages, which adds 14

28 complexity and overhead to the message exchanges and thus increase cost. In addition, sometimes users and web services are not predefined and known to each other and a trust relationship must be established before any interaction can happen between them. Those users also might have different requirements and their own policy rules, implementing different security constraints. Addressing all these concerns in one abstract and practical solution will facilitate the interaction between web services. This is the motivation behind the WS-SecureConversation standard. The Web Services Secure Conversation Standard (WS-SecureConversation) is built on top of the WS-Security, WS-Trust, and WS-Policy standards to provide secure interaction and data exchange between web services [Ibm02]. WS-Security [Wss04] describes how to embed existing security mechanisms such as XML Encryption, XML Digital Signature, and Security Tokens into SOAP messages to provide message confidentiality, integrity, authentication, and non-repudiation. WS-Trust [Wst07] is a standard to support the establishment of trust relationships between web services. WS- Policy [Wsp07] provides specifications that describe the capabilities and constraints of the security (and other business) policies on intermediaries (for example, required security tokens, supported encryption algorithms, and privacy rules) and how to associate policies with services and end points. To perform its functions, WS-SecureConversation [Wsc09] defines mechanisms for establishing and sharing Security Context Token (SCTs), and deriving keys from security contexts to authenticate messages between parties. This shared context defines who, how, what and for how long each user is able to conduct business. The involved 15

29 parties share these SCTs throughout the lifetime of the communication channel [Wsc09], [Ibm02] Intent This pattern describes a standard to allow security context establishment and use through the lifetime of the communication session between web services. This security context is used to provide secure communication between web services by extending the mechanisms of WS-Security, WS-Trust, and WS-Policy Context Distributed applications using web services that need to collaborate with each other to perform business workflows using insecure networks, e.g. the Internet Problem Before initiating a conversation with people, we need to know with whom we are talking and what do we want to talk about. We initiate conversations with different persons, based on our roles and interests. The same is true for web services. The functions of WS-Security which include integrity, confidentiality and authentication of messages are useful for simple or one-way messages; but this solution is impractical and could cause a problem in case of the necessity of parties to exchange multiple messages [Wss04]. If there are multiple message exchanges between service provider and consumer, then the overhead of XML signature and XML encryption are significant. 16

30 Further, establishing security relationships is fundamental for the interoperation of distributed systems. Applying relevant policies is needed to make it clear for the users what is allowed or which conditions apply to the use of web services. Without applying relevant policies and trust relationships between the involved parties, web services have no means to assure security and interoperability in their integration and may lose their ability to provide service. The possible solution to the problem of establishing a secure context is constrained by the following forces: Securing Context Tokens: While communicating using context tokens, web services exchange multiple messages containing sensitive data; we need to provide message protection for this exchange. Time Restrictions: Any interactions or means of communications between web services may be restricted in time. We should be able to amend, renew, or cancel those interactions properly, as needed. Policy: A web service uses policy(ies) to define all the required conditions and constraints that should be met before using that web service. We should reference this policy for verification and proper use. Overhead: Web services exchange multiple messages that add complexity, increase the overhead of key establishment, and decrease performance; we need to keep overhead at a minimum. 17

31 Interoperability: Web services and requesters should interact seamlessly despite differences in domains and platforms Solution We define explicitly an artifact that uses a Security Context Token (SCT). The SCT defines what kinds of assertions are required to be satisfied by any interaction between the involved web services and encapsulates the claims and information sent by the requester in order to obtain the required SCT. Once initiated, this SCT can be used to conduct secure communications. All entities involved share a key that has been agreed in order to establish a communication session with their target partners. Structure Figure 1 describes the structure of this pattern. Pink classes describe a logical web service connection; blue classes describe the token management structure, while yellow classes describe security tokens and claims. 18

32 19 Figure 1: Class Diagram for the WS-SecureConversation Pattern

33 Participant represents an entity (e.g., human, computer, message, an endpoint, interaction, resource) that is in charge of managing SCTs. It can have the role of: Initiator, the one creates a SCT or asks a STS to create one for her, or Requester, who asks for a SCT to conduct business and use web services. A Claim is a statement about a client, service or other resource (e.g. name, identity, key, group, privilege, capability, etc.). Claims are assertions such as I am Adnan, I am an authenticated user and I am authorized to print. A Security Token is a collection of claims (such as X.509 certificate, Kerberos ticket, and username).it is responsible for adding signatures to tokens. Security Token also is a generalization of: Signed Security Token, that is cryptographically endorsed by a specific authority (e.g. an X.509 certificate or a Kerberos ticket), and Proof-of-Possession (PoP) Token which contains a secret data parameter that can be used to prove authorized use of an associated security token. Usually, the proof-of-possession information is encrypted with a key known only to the recipient of the POP token. A Security Context Token is a representation of a security context, which in turns refers to an established authentication state with negotiated keys that may have additional security-related properties. Requestors can use SCTs to sign and/or encrypt a series of SOAP messages, known as a conversation, between a message sender and the target web service. Security Token Service (STS) is a web service that issues SCTs by itself, or relies on another STS to do so using its own trust statement. It produces assertions based 20

34 on evidence that it trusts, provides challenge for requesters to ensure message freshness (the message has not been replayed and is currently active), verifies authorized use of a security token and establishes, extends trust among a domain of services. Each STS has a Trust Engine that evaluates the security-related aspects of a message using security mechanisms and implies a policy to verify the requester s assertions. The Trust Engine is responsible for verifying security tokens and verifying claims against policies. A Policy is a collection of policy assertions that have their own name, references, and ID. Dynamics We describe the dynamic aspects of the WS-SecureConversation using sequence diagrams for the use cases Establish a SCT to create a context and Amend a SCT Establish a SCT to create a context (Figure 2): Summary: STS creates a SCT using the claims provided by the initiator. Actors: Initiator, requester. Precondition: The STS has the required policy to verify the requester claims and the requester provides parameters in form of claims and RequestType signed by a signature. 21

35 Figure 2: Sequence Diagram for establishing a SCT to create a context Description: a. The requester asks for a SCT to use a web service. b. The initiator requests a SCT by sending the required parameters of claims signed by a Signature to the STS in forms of security tokens. c. The STS uses WS-Trust mechanisms of Trust Engine and WS-Policy to check the initiator s claims. d. Once approved, the STS creates a new SCT in the form of an URI and sends it back to the initiator, who in turns sends it back to the requester. Post condition: The initiator has a SCT that can be used to communicate with other web services. 22

36 Amend a SCT (Figure 3): Summary: A STS will amend an existing SCT to carry additional claims upon the initiator s request. Actors: Initiator. Precondition: The initiator owns a SCT. Figure 3: Sequence Diagram amending an existing SCT Description: a. The initiator asks to change a SCT she owned to carry additional SCTs. b. The STS asks for the key associated with the SCT as a proof of possession. 23

37 c. The initiator replies back with a signature. d. Once approved, the STS adds those additional SCTs to the SCT to form a new SCT and sends it back to the initiator. Postcondition: The initiator has an amended SCT that can be used to communicate with other web services Implementation When it comes to encrypt a message, SCTs use a symmetric key rather than an asymmetric key, which makes them faster and more efficient. A STC allows a context to be named by a URI, also for reference purposes. The participating web services determine a shared secret to use as the basis of key generation. In other words, shared secrets are in form of derived keys. The derived keys are expressed as security tokens. following: In order to assure effective implementation, we need to take in consideration the Using a service requires a signature to prove knowledge of a security token or set of security tokens. Three possible scenarios are presented to establish a SCT; by one of the communicating parties, by a negotiation/exchange process between the participants, or by a separate STS. Although the messages exchanged between the involved entities are protected by WS-Security; still three possible issues related to security tokens are handled: security token format incompatibility, security token 24

38 trust and namespace differences. The WS-Trust pattern can address these issues by: Defining a request/response protocol (in which the client sends RequestSecurityToken and receives RequestSecurityTokenResponse and introducing a Security Token Service (STS). This pattern could be used to guide the development of a product. Users can use this pattern to ask for certain security mechanisms that fit their business goals. Developers and product vendors should be aware that no complete security solution for web services is guaranteed through WS-SecureConversation by itself. WS-Secure Conversation should be used in conjunction with other web services standards such as WS-Security, WS-Trust, and WS-Policy for an optimal solution [Wst07]. Implementing various security mechanisms through those standards will lead to an optimal solution. Implementations of those WS standards are beyond the goals of this pattern and were covered in [Has09], [Aja10a], and [Aja10b] Example Resolved Ajiad now has the ability to automate the business relationships with its partners by assuming that all partners are registered and by issuing customers unique IDs. In this case, Ajiad provides an intermediate link between the customers and its partners and plays the role of negotiator as well as third-party player who is looking to satisfy both sides. Ajiad now can offer a SCT Service for its business partners, who may find useful ways to take advantage of credit processing and other of its services, Ajiad now has new business opportunities. 25

39 Known uses WS-SecureConversation is used in the Microsoft Web Services Enhancement 2.0 toolkit [Gud04]. WS-SecureConversation support in Apache s CXF builds upon the WS- SecurityPolicy implementation to handle the SecureConversationToken policy assertions [Ap13]. Java applications support in IBM products includes support for WS- SecureConversation [Sos10]. SAP is using the security context primarily to allow WS- ReliableMessaging to reuse a security context, so that the server can contact the client [Sap13] Consequences The WS-SecureConversation pattern presents the following advantages: Policy providers now can use mechanisms provided by other web services specifications such as WS-Security, XML Digital Signature [Xds08], and WS-Metadata Exchange [Wme09] to protect the messages needed to create a secure context. Time restriction: We can specify time constraints in the parameters of SCTs, which can specify how long that token is active. Upon expiration, the SCT s holder may amend, renew, or cancel it. 26

40 Policy: We can implement WS-Policy to support trusted partners by expressing and exchanging their statements of trust expressed as a trust policy. Overhead: For the communication channels that require end-toend security and have frequent message exchanges, the WS-SecureConversation may reduce the overhead. Using either encryption or signing is better than using both, since combining both produces significantly lower performance [Liu05]. Interoperability: STS satisfies the capabilities and constraints of the security (and other business) policies on intermediaries which at the end increase the interoperability between web services. By implementing STS, the WS-SecureConversation framework will be more comprehensive and can carry out secure conversations between parties in different trust domains. e WS-SecureConversation pattern presents the following liabilities: The WS-SecureConversation standard is a lengthy document with a lot of details that were left out to avoid making the pattern too complex. Somebody interested in addressing more details can check the WS- SecureConversation Standard web page. No complete security solution for web services is guaranteed through WS-SecureConversation by itself. WS Secure Conversation should be used in conjunction with other web services standards such as WS-Security, WS- Trust, and WS-Policy for an optimal solution. 27

41 Related Patterns A Pattern for WS-Security [Has09] defines how to secure SOAP messages applying XML security standards such as XML Encryption and XML Signature. A pattern for the WS-Policy standard [Aja10b] describes how to express requirements that are needed or supported by a web service. For instance, it can indicate that a specific signature algorithm must be used when signing a document. A pattern for the WS-Trust standard of web services [Aja10a] provides a framework for requesting and issuing security tokens, and to broker trust relationships. It uses WS-Security to transfer the required security tokens, using XML Signature and Encryption to provide confidentiality. This standard may use WS-Policy to specify which security tokens are required at the target Conclusion We presented a pattern for the WS-SecureConversation that describes how a web service can authenticate requester messages, how requesters can authenticate services, and how to establish mutually authenticated security contexts. Message authentication is useful for simple or one-way messages; parties intending to exchange multiple messages can create a secure session. A security context 28

42 is shared among the communicating parties for the lifetime of a communications session. These security context-token-issuance services build on WS-Security, WS-Trust and WS- Policy to transfer the requisite security tokens in a manner that ensures the integrity and confidentiality of those tokens. 29

43 3. A PATTERN FOR THE WS-FEDERATION STANDARD FOR WEB SERVICES Abstract: The growth in business-to-business commerce, increased mobility and the importance of persistent interactions between involved parties are some of the current industry challenges. To meet these challenges, companies are extending internal systems to external users of different categories (employees, customers and partners). A variety of users who need to interact with a variety of autonomous systems requires a careful handling of identities. Building secured and trust-based relationships among users might require sharing their identity information. Trust relationships should allow identity and policy data to be exchanged between parties independent of platform, application or infrastructure, and avoid redundant work. A Federation describes the technology and mechanisms necessary to systemize this interconnection, and to allow different domains to use identities from different domains. We present here a pattern for the WS-Federation standard. The WS-Federation standard is built on top of the WS-Security, WS-Trust, and WS-Policy standards to define a framework with additional federation mechanisms that extend these specifications. 30

44 3.1. Introduction Web services are a distributed application architecture based on industry standards such as SOAP, XML, WSDL and UDDI. The idea behind implementing web services is to deliver complete and interoperable business solutions for the enterprise. Organizations need a consistent and secure way of expressing what type of credentials and requests they accept, the policies by which they conduct business, and what services are presented to their customers and partners. Despite the high degree of interoperability between involved parties, and the fact that each individual continues to manage his own user s identities, users still have the choice of sharing and accepting credentials and identities from members from outside their domain. For that reason, the WS-Federation standard defines mechanisms to allow different security domains (realms) to federate their identities, such that authorized access to resources managed in one domain can be provided to principals whose identities are managed in other domains. Those federation mechanisms enable the decision of federating IDs to be based on the declaration (or brokering) of identity, attribute, authentication and authorization assertions between domains. Addressing all these concerns in one abstract solution will facilitate the interaction between web services. Figure 4 shows a pattern diagram describing the relationships between the patterns for some web services standards. The diagram shows dependencies between the patterns; for example, WS-Security uses policies defined by WS-Policy. Our group has written all these patterns [Fer12a]; this being the last in the group. 31

WEB SERVICES SECURITY February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in part without

Web Service Security Vulnerabilities and Threats in the Context of WS-Security Jesper Holgersson Eva Söderström University of Skoevde, Sweden SIIT 2005, ITU, Geneva, September 2005 Outline of presentation

An Oracle White Paper Dec 2013 Oracle Access Management Security Token Service Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only,

Secure Identity in Cloud Computing Michelle Carter The Aerospace Corporation March 20, 2013 The Aerospace Corporation 2013 All trademarks, service marks, and trade names are the property of their respective

Introduction to Service-Oriented Architecture for Business Analysts This course will provide each participant with a high-level comprehensive overview of the Service- Oriented Architecture (SOA), emphasizing

CLOUD COMPUTING AND PUBLIC SAFETY SERVICES This paper examines the emergence of Service Oriented Architectures, their implementation in Cloud computing services and the likely impact on Public Safety systems

White Paper Delivering Web Services Security: September 2003 Copyright 2003 Entrust. All rights reserved. Entrust is a registered trademark of Entrust, Inc. in the United States and certain other countries.

What You Need to Know About Transitioning to SOA written by: David A. Kelly, ebizq Analyst What You Need to Know About Transitioning to SOA Organizations are increasingly turning to service-oriented architectures

Service Virtualization: Managing Change in a Service-Oriented Architecture Abstract Load balancers, name servers (for example, Domain Name System [DNS]), and stock brokerage services are examples of virtual

SOA REFERENCE ARCHITECTURE August 15, 2007 Prepared by Robert Woolley, Chief Technologist and Strategic Planner INTRODUCTION This document is a derivative work of current documentation and presentations

Cloud computing: the state of the art and challenges Jānis Kampars Riga Technical University Presentation structure Enabling technologies Cloud computing defined Dealing with load in cloud computing Service

This document is a statement of the principles that will guide the technical development of the Kuali Student system. It will serve as a reference throughout the full lifecycle of the project. While these

Profile-Based Access Control in Cloud Computing Environments with applications in Health Care Systems By Umair Mukhtar Ahmed Naushahi A thesis submitted to the Department of Computer Science In conformity

This project was supported by Grant No. 2009-DB-BX-K105 awarded by the Bureau of Justice, Office of Justice Programs in collaboration with the U.S. Department of Justice s Global Justice Information Sharing

Web Services Advanced Topics Where things are now and where they are going Version 9 Web Services Advanced Topics WSAdvanced-2 Enterprise Web Services Industry trends and organizations Security and Reliability

Combining SAWSDL, OWL DL and UDDI for Semantically Enhanced Web Service Discovery Dimitrios Kourtesis, Iraklis Paraskakis SEERC South East European Research Centre, Greece Research centre of the University

Service Oriented Architecture for Law Firms: SOA is inevitable, are you ready? David Pilling Director of Applications and Development "Things should be made as simple as possible, but no simpler. -- Albert

A Semantic Approach for Access Control in Web Services M. I. Yagüe, J. Mª Troya Computer Science Department, University of Málaga, Málaga, Spain {yague, troya}@lcc.uma.es Abstract One of the most important

and s Branch Glossary of Key Terms The terms and definitions listed in this glossary are used throughout the s Package to define key terms in the context of. Access Control Access The processes by which

Guiding SOA Evolution through Governance From SOA 101 to Virtualization to Cloud Computing 3-day seminar The evolution of how companies employ SOA can be broken down into three phases: the initial phase

1 CHAPTER 1 INTRODUCTION 1.1 Introduction Cloud computing as a new paradigm of information technology that offers tremendous advantages in economic aspects such as reduced time to market, flexible computing

Service Oriented Networks Security David Brossard, M.Eng, SCEA Senior Security Researcher, BT Innovate Globecom 2008 While empowering new business models, SON leads to a proliferation of application networks

Integration of Hotel Property Management Systems (HPMS) with Global Internet Reservation Systems If company want to be competitive on global market nowadays, it have to be persistent on Internet. If we

Marty Stogsdill, Oracle SNIA Legal Notice The material contained in this tutorial is copyrighted by the SNIA unless otherwise noted. Member companies and individual members may use this material in presentations