Web Services Security Standards

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 3, Issue 6, June 2013)

145

Web Services Security Standards

Gaurang Deshmukh

1

, Swapnil Powar

2

, Dr. B. B. Meshram

3

MTech-NIMS(COMP) VJTI Mumbai MTech-NIMS(COMP) VJTI Mumbai HOD Computer Science, VJTI Mumbai

Abstract--Web Services are the way of machine to machine communication over the network to perform specific operation e.g. transaction, information exchange, sale service etc. So web service is having protocols and standards that are used to exchange data between applications or systems. Web Services use SOAP protocol to exchange data between systems. Web services work on standards mainly WSDL, XML and UDDI. Security of standards and protocols is essential. Web Services are widely involved in cloud computing and distributed system now days. So leveraging interoperable standards to achieve security in cloud and distributed system is challenge. Here we highlight the existing web services security standards and their role in cloud computing.

KeyWords-- Web Service, SAML, XACML, WS-Trust, WS-Policy, WS-PolicyAttachment, WE-Secure Conversation, WS-SecurityPolicy, IaaS, SaaS, PaaS

I. INTRODUCTION

Xml and Web Services are widely used in Cloud computing and Distributed System. Web Services are used to achieve machine to machine communication to perform certain operation. Two different machines can communicate using interoperable mechanism provided by Web Services. Web service communication performed by message exchange so there is also need of security in web services. It requires authorization, authentication, and digital signature, encryption and non-repudiation of information. Organization for the Advancement of Structured Information Standards (Oasis) established the Web Services (WS)-Security standards. Here we describe interoperability nature of web services by presenting Web Services Security Standards and their role in cloud computing environment.

II. WEB SERVICE SECURITY STANDARDS

Using web services security standards we not only achieve Confidentiality and Integrity of data but also we can address challenges related to exchanging security tokens like Username and Password using X.509 and SAML. In eneral Web service security message contains SAML token (UserID, Password), Encrypted data or document which is signed by digital signature.

Though WS Security standards are straight forwards but it’s important to understand them and leverage with other security standards to make integration flexible and interoperable.

A.Security Assertion Mark-up Language(SAML):-

SAML is directly referenced entity in WS-Security. It is used as an authentication token along with other client information. SAML mainly used when client want to exchange attribute which more important than user

information.When an application in a Federated Identity

Management infrastructure invokes the Web service it uses SAML to exchange Username Password like tokens.

The SAML token profile defines how to include SAML assertions within security headers and how to reference these assertions from within the SOAP message. A binding between a SAML token and the SOAP message can be created by signing the message with a key specified within the SAML assertion.

B.Extensible Access Control Markup Language

(XACML):-XACML uses XML schema. (XACML):-XACML used for authorization. XACML authorization include xml request

and xml response messages. XACML Policy

Enforcement Point(PEP) limits the access to various resources. A policy enforcement point again relies on a policy decision point (PDP) for deciding the outcome of a request, based on the policies applicable to the request. XACML’s SAML profile defines how to protect, transport, and exchange XACML messages. Using the XACML’s SAML profile in WS-Security, Web service providers can implement authorization by leveraging an XACML compliant PEP.

C.

WS-Trust:-WS-Trust allows exchange of security tokens across various trust domains. Organization uses this internally or with other organization to help, validate, issue and renew

the tokens and to translate the token formats. Security

(2)

International Journal of Emerging Technology and Advanced Engineering

146

Consider the following cloud computing example. An organization hosts a Web application internally, but the application needs to access Web services hosted by a third party in a cloud. The Web application or Web service consumer can exchange an internal security token with a WSTrust- compliant Security Token Service (STS) to obtain a token that the cloud provider trusts. The security of the Web services defined in WS-Trust can require the incoming message to meet certain security requirements, specified as a policy described in WS-Policy or WS-WS-PolicyAttachment.

D.WS-Policy and WS-PolicyAttachment

In SOAP message security every web service can request different security tokens. Different parts of message may be encrypted with different encryption algorithm or signed by different digital signature. WS-Policy describe such requirements and capable of providing framework and model for policies.WS-PolicyAttachment describes how to attach such policies to a subject (e.g. Web service endpoint, message, resource, or operation), either as part of the Web Services Description Language (in the metadata) or by attaching a reference to the policy described outside of the metadata.

E.WS-SecurityPolicy

While WS-Policy describes the constraints and requirements in an interoperable manner, WSSecurity Policy’s main aim is to describe the assertions to secure the Web services. WS-SecurityPolicy is mainly designed to describe security characteristics of Trust, WS-SecureConversation and WS-Security SOAP Message Security.

F.WS-SecureConversation

WS-Security mechanism defines way for exchanging security token to encrypt or digitally sign message in interoperable manner. Some application requires multiple security tokens exchange in this case WS-Security is not efficient. Here WS_SecureConversation can help. It defines security context within which messages can be exchanged.

WS-SecureConversation also describes a mechanism for deriving session-key information. It has a specific binding described for WS-Trust so that when requesting a token, the WSTrust consumer can request a Security Context Token, and the STS (WS-Trust) will respond with one.

Fig1. Services interacting in a cloud. This exemplifies interactions between a Web service provider and a service consumer in the infrastructure as a service (Iaas), software as a service (SaaS), or platform as a service (PaaS) models along with the corporate environment

III. WEB SERVICES AND CLOUD COMPUTING

Cloud computing is the fastest growing technology now days. Cloud service provider provides Infrastructure as a Service, Software as a Service or Platform as a Service. All this services expose the Web Services or consume services from another platform or infrastructure. Various combination of service providers vary based on organization and number of cloud providers.

(3)

International Journal of Emerging Technology and Advanced Engineering

147

When security must be implemented across various cloud providers, or when services are hosted or offered by a third party, interoperability becomes very important. This leads to the next question of how we can apply the various Web services security standards to effectively protect the services.

IV. WEB SERVICES SECURITY ARCHITECTURE

[image:3.595.51.291.292.707.2]

Web services security can be architected to accommodate various security tokens, enforce access control, and maintain transaction confidentiality and integrity. The Web services security architecture in

Figure 2. Security standards and their interactions. Various security standards interact with a Web service to define and

[image:3.595.55.273.293.469.2]

validate security tokens

Figure 3. Standards for the Web service consumer. The WS-Trust security token interacts with the Web service consumer to translate the client application token into what the service provider requires.

Figure 2 leverages the interoperable standards to

 define what security tokens to accept and what parts

to sign or encrypt using Policy or WS-PolicyAttachment

 validate the token and obtain a SAML token along

with XACML information—the Web service interacts with the STS (WS-Trust) to accomplish this

 define the security for the STS using WS-Policy (or

WS-PolicyAttachment or WS-SecurityPolicy)

 increase performance using

WS-SecureConversation for frequent message

interactions; and

 describe security for WS-SecureConversation using

WS-Policy, WS-PolicyAttachment, or

WS-SecurityPolicy.

The design of the consumer application, on the other hand, should have the flexibility to translate any client application token into the token the service provider requires. It should also be able to digitally sign and encrypt the message or parts of it. Figure 3 shows the interactions between a Web service consumer and an STS (WS-Trust) to translate a client application token.

V. WEB SERVICES SECURITY WALKTHROUGH

Figure 4 shows a deployment scenario in which a cloud provider offering IaaS deploys a Web service that authorized business partners can access. An organization subscribes to a SaaS provider, so its business partners receive access to the Web services hosted at the IaaS cloud provider. The organization deploys an internal application that consumes services from the SaaS provider. The organization has clearly leveraged interoperable standards to secure Web services interactions.

Consider its use of the IaaS. It uses WS-Policy to describe its Web services security policy, and it has a dedicated virtual private network (VPN) tunnel for its corporate network, which leverages the STS based on WS-Trust to translate tokens. It also exchanges an incoming username and password (invoked by a business partner) token for a SAML token with an XACML profile. Finally, it uses an XACMLcompliant PEP to enforce access control for service requests.

[image:3.595.51.302.506.710.2]

(4)

International Journal of Emerging Technology and Advanced Engineering

148

Also, the STS maintains control over which users or business partners can access the service and what operations they can perform (by sending XACML information). It also controls who can access the SaaS Web service, even though access is through an internal application (it translates the internal application token to the required SAML token).

[image:4.595.53.559.262.554.2]

Security Token Service(STS)

Figure 4 shows how to leverage an STS deployed by a cloud provider (IaaS) in an internal corporate network

with a dedicated VPN tunnel. However, you could deploy an STS at any number of places based on the need for a service provider or consumer to support multiple tokens. For example, there could be one STS for every group of Web services (typically grouped by either the organization or cloud service model) that can translate the tokens received from various service consumers. The same concept can apply to service consumers. Each service consumer or set of service consumers can trust an STS to translate client credentials into the required token.

Figure 4. A sample Web services security architecture. The organization leverages interoperable standards to secure Web services interaction

VI. CONCLUSION

The standards here we explained aren’t the only ones that address Web services security. Other standards exist, including the Oasis Digital Signature for signature processing, the XML Key Management Specification12 for distributing and registering public keys, and the WS-Metadataexchange13 (proposal) for exchanging metadata for Web services security. However, the standards mentioned here address the most common challenges experienced when securing a service.

REFERENCES

[1] Web Services Security: SOAP Message Security 1.1 (WSSecurity 2004), Organization for the Advancement of Structured Information Standards(Oasis),Feb.2006

[2] WS-SecureConversation 1.4, Organization for the Advancement of Structured Information Standards (Oasis), Feb. 2009; http://docs.oasis-open.org/ws-sx/ ws-secureconversation/v1.4/os/ws-secureconversation 1.4-spec-os.pdf.

(5)

International Journal of Emerging Technology and Advanced Engineering

149

[4] Interoperable Security Standards for Web Services by IT Pro September/October 2010 Published by the IEEE Computer Society

[5] XML and Web Security Standards-Nils Agne Nordbotten IEEE Communication survey and tutorial Vol.11 third quarter 2009 [6] en wi ipedia org wi i WS-Security

[7] https www oasis-open org committees wss

[8] Web Services Policy 1.5—Framework, World Wide Web Consortium (W3C) recommendation, Sept. 2007;www.w3.org/TR/ws-policy.