This chapter underlines the importance of security service level agreements (SLAs) for Web services. As Web services are increasingly incorporated in the mainstream enterprises, the need for security has led to various standards. However unlike nonfunctional requirements such as performance, scalability and so forth, which are quantitative and are enforced through SLAs, security is represented only through policies. There exist quite a few frameworks for security at different levels of enactment; however, what is clearly missing is an approach to represent security SLAs and enacting them for a Web service environment. In this chapter, we primarily focus on two aspects. We first focus on the security requirements for Web services and the currently available stack of security mechanisms and frameworks for achieving security at various levels of Web service implementation. The second focus is on how these could be utilized to build security SLAs, which could be enforced on Web services. Later in the chapter we suggest a conceptual model to represent these SLA clauses and present an approach to enact them.
TopBackground
SLAs have been commonly used to specify nonfunctional requirements which ascertain the criteria for the correct operation of the system. Typical nonfunctional requirements which are covered through SLAs today include reliability, scalability, cost and so forth, most of which are measurable attributes. The need for a Web service security SLA arises from the fact that Web services are designed to be composed from candidate services, the credentials of each required to be verified for an enterprise level service orchestration. A security SLA would typically comprise of the following quality of service (QoS) attributes:
- •
Access Control: Provision of only need-to-know information/privileges.
- •
Authorization and Authentication: The prevention of data/information access by invalid users.
- •
Availability: The prevention of degradation or interruption as a consequence of failures.
- •
Confidentiality: The prevention of unauthorized disclosure of data.
- •
Integrity: The prevention of unauthorized modification of data.
There exist quite a few approaches, standards, and frameworks which address the above issues for implementing security for Web services. Security assertion markup language (SAML) is an XML standard designed by OASIS for exchanging authentication and authorization data between service and identity providers. Not only does it provided support for transport-level security (through SSL 3.0 and TLS 1.0), but it also ensured message-level security (using XML signature and XML encryption). Later, Liberty alliance extended SAML for identity management. Although SAML was used as a de-facto industry standard for exchanging authorization information, it was limited by its declarative limitations and was followed by extensible access control markup language (XACML), which provided support for a more declarative-access control-policy definition. Later in 2006, W3C defined WS-policy as a XML-based standard for definition and specification of Web services policies (on security and QoS, etc.)
In spite of all these frameworks and standards, security SLAs were never enacted in real life. In this work we discuss the need for security SLAs, some of the current work towards providing security SLA guarantees, and towards the end we suggest our approach for enactment of security SLAs.
TopSecurity Requirements For Web Services
Security SLAs would work with typical security attributes that represent the overall set of security QoS requirements of the concerned system. In case of Web services, while the core security requirements of online systems apply, they need to be aware of the specific requirements of Web services. In this section, we shall cover the basic requirements of Web services security.