Web Services Security

Transcription

1 Web Services Security Submitted to Dr. Stefan Robila As Part of CMPT-585, Final Project By Nagalakshmi Kohareswaran Shilpa Venugopal Department of Computer Science Montclair State University Montclair, NJ Fall 2005

2 Web Services Security 1. Abstract Web Services are emerging as an important technology for enabling various forms of information services across programming languages and platforms. Web Services enable applications to communicate more effectively without having to work out the underlying mechanics of the communication. A key benefit of the Web Services architecture is the ability to deliver integrated, interoperable solutions. Interoperability among these applications is ensured through the use of standards such as SOAP, XML, and WSDL. This paper starts with a brief description of what web services are and the scenarios in which web services find their use. It describes the security requirements of web service applications and how they are greater than traditional e-commerce over the Internet. It attempts to analyze the security standards associated with Web Services in general, and how they are related to each other and how they coordinate to form the modules of the web services security architecture. 2. Introduction In the modern days the organizations have started relying a great deal on the IT infrastructure to carry out their business processes and manage their resources. Companies deploy customized applications to manage the functioning of different departments. These applications need to be integrated with each other for consolidated decision-making, accurate system information, better performance and monitoring. There are technologies available that help in integrating these custom applications within an enterprise. Enterprise Application Integration (EAI) is one of such processes that create an integrated infrastructure within an enterprise. EAI enables the development of software that sit between these applications within an enterprise and help them function in harmony. In many scenarios, integration within the enterprise is not sufficient. The organizations need to integrate applications across enterprises. For example they may need to integrate applications with their partners, customers and suppliers. Although cross-enterprise integration is very vital it may have many security implications. Since the information is exchanged over the Internet they may be exposed to malicious attacks. Also, all the information offered by companies on the Internet may not have the same level of business confidentiality. Some of the information offered may be meant to be available publicly while the others may be meant for the company s partner companies. Companies secure their resources available on the Internet by defining business roles, access rights and system policies. One of the ways of doing this is by means of network level firewalls. Firewalls have the following functions: To monitor all the incoming traffic

3 To check the identity of the information requesters To authenticate users based on their identities, which can be the network addresses of the service requesters or security tokens. To check security and business policies to filter access requests and verify whether the service requester has the right to access the intended resource. To provide for encrypted messages in order to secure confidentiality of business information that is to be sent across the Internet privately. The next issue in cross enterprise integration is the need for interoperability between the various systems involved. The companies involved may not have control over or may not even know much about the infrastructure of the partner companies. One of the companies could be using Java over Solaris servers and another could be using.net or some other technology. It may not be feasible to agree upon messaging formats for exchange of information and interoperability. This would involve an endless task of designing and redesigning message formats for each partner company. To resolve this problem many applications shift from legacy integration to Service Oriented Architecture (SOA) provided by web services. Service Oriented Architecture consists of applications that can be called externally. It provides remote invocation functionality to service classes. Services in SOA are similar to classes in object-oriented languages. These service classes implement the business logic. The functionalities of these classes are exposed by hosting them on the SOAP server. The SOAP server works over HTTP. SOAP uses XML to specify remote method invocation calls. Most of the web services have some methods that are meant to be available publicly and some that are strictly private between the partner companies. The SOAP server cannot provide security by itself. The SOAP server maintains only the information related to the web services it is hosting, like the names of the services, names of the methods in each service, location of the classes that implement the web services and more. But the SOAP server does not have the capability to check whether the incoming SOAP request is coming from an anonymous customer or a partner company. It does not perform user authentication, authorization and access control. A remote client that has accessed a SOAP server can invoke any method of any service hosted on that SOAP server. Even a network firewall will not be able to distinguish between a customer and a partner once it has reached a SOAP server. There are two solutions to this problem. One is to use a different SOAP server for each level of sensitivity, so that different authentication policies can be enforced on each sensitivity level. But this method would make the web service infrastructure very complex, making it very hard and expensive to build. The second solution is to make the firewall XML and SOAP aware. The firewall will be able to inspect the SOAP messages and try to match the user roles with the access lists, policy levels etc. The web service users can add in security information like signatures, tokens etc The SOAP and XML- aware firewall will check the message before it reaches the SOAP server. The security information added is based on XML-based security protocols. (Siddiqui, 2003)

4 3. Web Services Security 3.1 Challenges Web Services standards do not completely address security issues - which are a major inhibitor for corporations embracing Web Services. There are many new kinds of security challenges in addition to traditional security problems for adopting Web Services. The objective is to create an environment, where message level transactions and business processes can be conducted securely in an end-to-end fashion. Ensuring the integrity, confidentiality and security of Web Services through the application of a comprehensive security model is critical, both for organizations and their customers. It is important to provide capabilities to ensure availability, reliability and security of web services. Security is important for any distributed computing environment. But security is becoming even more important for Web Services due to the following reasons: (Java World, 2003) Interactions between communicating parties are expanding from intranets to the Internet. Most businesses perform transactions over the Internet using Web Services. From a security perspective, Internet communication is less protected than intranet communication. More interactions are expected to occur between programs rather than between humans and programs. Therefore, interactions involving Web Services are anticipated to be more dynamic and instantaneous. Communicating parties are likely to interact with each other without establishing a business relationship. This means that all security requirements such as authentication, access control, non-repudiation, data integrity and privacy must be addressed by the underlying security technology. Finally, as more and more business functions are exposed as Web services, the number of participants in a Web services environment will be larger than what we have seen in other environments. 3.2 Requirements The requirements for providing end-to-end security for Web Services are (Barbir, 2003): Authentication mechanisms: This is required in order to allow mutual authentication of a service provider and a service invoker to verify their identities. Authorization to access resources: Once authenticated, access to appropriate system resources is controlled by authorization mechanisms. Access to systems and their components should be controlled.

5 Data integrity and confidentiality: This ensures that information has not been modified during transmission and is only accessible to intended parties. Encryption technology and digital signature techniques can be used for this purpose. Integrity of transactions and communications: This is needed to ensure that the business process was performed properly and the flow of operations was executed in a correct manner. End-to-end integrity and confidentiality of messages: The integrity and confidentiality of messages must be ensured even in the presence of intermediaries. Non-repudiation: This is needed so that a party cannot deny the occurrence of a transaction. Audit Trails: This is needed in order to trace user access, behavior and system integrity verification. Distributed enforcement of security policy: Implementers must be able to define a security policy and enforce it with varying privileges across various platforms. 3.3 Current Security Mechanisms There are two ways with which we can ensure security with Web Services. They are: Security at the Transport level Security at the XML level Security at the Transport level Transport level security is based on Secure Sockets Layer (SSL) or Transport Layer Security (TLS) that runs beneath HTTP. SSL and TLS provide security features including authentication, data protection and cryptographic token support for secure HTTP connections. The integrity and confidentiality of transport data, including SOAP messages and HTTP basic authentication is confirmed when you use SSL and TLS. Web Services applications can also use Federal Information Processing Standard (FIPS) approved ciphers for more secure TLS connections. SSL is the Industry accepted standard protocol for secured encrypted communications over TCP/IP. In this model, SSL is used by a Web Service client to open a secure socket to a Web Service. The client then sends and receives SOAP messages over this secured socket using HTTPS. The SSL implementation takes care of ensuring privacy by encrypting all the network traffic on the socket. SSL can also authenticate the Web Service to the client using the PKI infrastructure. Encryption is provided by HTTPS, which ensures privacy and message integrity. HTTPS also provides authentication through the use of certificates, which can be used on the server side, the client side, or both. The most common configuration on the Web

6 today is HTTPS with server-side certificates. In this configuration, clients can authenticate servers, but servers cannot authenticate clients. However, HTTPS can also be used in conjunction with basic or digest authentication, which provides a weaker form of authentication for clients. In order to authenticate a service client to a secure endpoint, HTTP basic authentication uses a user name and password. The basic authentication is located in the HTTP header that carries the SOAP request. When the application server receives the HTTP request, the user name and password are retrieved and verified using the authentication mechanism specific to the server. The integrity and confidentiality of the data can be protected by the Secure Sockets Layer (SSL) protocol. (SCDJWS, 2006) SSL Limitations First of all, SSL provides point-to-point security, which is not sufficient for Web Services because we need end-to-end security, since multiple intermediary nodes can exist between two endpoints. In a typical Web Services environment where XML-based business documents are routed through multiple intermediary nodes, it is difficult for those intermediary nodes to participate in security operations in an integrated manner. SSL provides security for communication at the transport level rather than message level. As a result, messages are protected only while in transit on the wire. Unless you apply a proprietary encryption technology, sensitive data on your hard disk drive is not generally protected. HTTPS in its current form does not support non-repudiation well. Nonrepudiation is critical for Web Services and any business transaction. With nonrepudiation, a communicating party can prove that the other party has performed a particular transaction. For example, if E-StockTrade received a stock transaction order from one of its clients and performed the transaction on behalf of that client, if a dispute arises, E-StockTrade wants to ensure that it can prove that it completed the transaction to an arbitration committee. We need some level of non-repudiation for Web services-based transactions. Finally, SSL does not provide element-wise signing and encryption. For example, if you have an XML document for a purchase order, but you want to sign or encrypt only a credit card element, signing or encrypting only that element with SSL proves to be difficult since SSL is a transport-level security scheme as opposed to a message-level scheme. (Java World, 2003) Security at the XML level To overcome the limitations of SSL, some standards have been developed for securing Web Services at the XML level. These XML-based security schemes provide comprehensive and unified security schemes required for Web services.

7 4. XML Security Standards XML level security involves standards that form the modules of the XML firewall. We will discuss each one of these XML security protocols in detail in the rest of the paper. We will look at: XML Signature specification developed by W3C and IETF and used to ensure data integrity and signer authentication. XML Encryption specification developed by W3C and used to ensure data confidentiality. WS Security developed by OASIS defines ways of including digital signature, message digest and encrypted data in a SOAP message. Security Assertion Markup Language (SAML) developed by OASIS provides a way for the partner applications to share user authentication and authorization information enabling single sign-on (SSO) feature. SAML provides an alternative to use of cookies in HTTP to implement SSO. The data can be wrapped inside XML and sent across so that cookies are not required for this purpose. extensible Access control Markup Language (XACML) developed by OASIS provides a way for specifying the authorization and access policies in XML. XML Key Management Services (XKMS) describe a method for clients to securely access public key-related services such as key generation, registration and revocation. 4.1 XML Signature In Service Oriented Architecture, each of the partner companies has some services that are publicly available for access and some services that are strictly private for the partner companies. The partner company that wants to access one of the private services of another partner company would have to include message integrity and user authentication information within the SOAP method invocation. The XML firewall that receives this message will need to look into the SOAP message to verify the integrity of the message and to check if the message is from a trusted business partner. The firewall will only let the request pass onto the SOAP server if the both- message integrity verification and user authentication are done. One of the ways of doing this is by using XML Signature. XML Signature provides syntax for wrapping the message integrity, message authentication and user authentication data inside an XML format. XML signatures are digital signatures designed for use in XML transactions. The standard defines a schema for capturing the result of a digital signature operation applied to arbitrary (but often XML) data. XML signatures provide authentication, data integrity, and support for non-repudiation to the data that they sign. XML signatures provide a flexible means of signing and support diverse sets of Internet transaction models. A fundamental feature of XML Signature is the ability to sign only specific portions of the

8 XML tree rather than the complete document. This flexibility will also be critical in situations where it is important to ensure the integrity of certain portions of an XML document, while leaving open the possibility of other portions of the document to change. For example, you can sign individual items or multiple items of an XML document. The document you sign can be local or even a remote object, as long as those objects can be referenced through a URI (Uniform Resource Identifier). A signature can be either enveloped or enveloping, which means the signature can be either embedded in a document being signed or reside outside the document. XML digital signatures also allow multiple signing levels for the same content, thus allowing flexible signing semantics. For example, the same content can be semantically signed, cosigned, witnessed and notarized by different people Structure of Digital Signature The basic structure of XML digital signature is as follows: <Signature> <SignedInfo> (SignatureMethod) (CanonicalizationMethod) (<Reference (URI=?)> (Transforms) (DigestMethod) (DigestValue) </Reference>) </SignedInfo> (SignatureValue) (KeyInfo) (Object) </Signature> Figure 1 SignedInfo - This element specifies what was signed and with what algorithms. SignatureMethod This element indicates the algorithm used to produce the signature. It is used by the SignatureValue element and is included in the SignedInfo to prevent any tampering.

9 CanonicalizationMethod This element indicates the algorithm used to canonize the SignedInfo element. It is used by the SignatureValue element and is included in the SignedInfo to prevent any tampering. Reference There can be a list of reference elements in the SignedInfo element that specifies which resources have been signed using URI references. It contains the Transforms, DigestMethod and DigestValue elements. Transforms - This element also specifies any transforms to apply to the resource before applying the hash. DigestMethod This element specifies any digest (hash) algorithm to apply to the resource. DigestValue This element specifies the result of applying the digest (specified in the DigestMethod) to the resource. SignatureValue This element carries the value of the signature of the SignedInfo element, produced according to the SignatureMethod after serializing it with the algorithm specified by the CanonicalizationMethod element. KeyInfo This is an optional element that enables the recipients to obtain the key needed to validate the signature. If a KeyInfo element is no present the recipient is expected to identify the key from the context. Object This is also an optional element that is used to hold the signed data in case of an enveloping signature Steps in Creating Digital Signature The steps involved in creating digital signature are 1. Identifying the resources to be signed The reference can be Character-encoded data (HTML) e.g. Binary-encoded data like an image file on the web (JPG) e.g. XML file on the web e.g. Specific element in an XML file on the web e.g.

10 Each reference to resources is specified using a <Reference> element. 2. Determine the digest for each resource Calculate the digest for each referenced resource and place the value in the <DigestValue>. The algorithm used to calculate the digest for the resource is placed in the <DigestMethod> Example: <Reference URI= <DigestMethod Algorithm= <DigestValue> j6lwx3rvepo0vktmup4huhevu8nk=</digestvalue> </Reference> <Reference URI= <DigestMethod Algorithm= <DigestValue> j6lwx3rvepo0vktmup4huhevu8nk=</digestvalue> </Reference> Figure 2 3. Add the SignedInfo Element Collect all the resource elements and place them within the <SignedInfo> element. Then place the <CanonicalizationMethod> containing the algorithm used for canonicalizing the SignatureInfo. Different data streams with the same XML information set may have different textual representations for e.g. they could differ in white spaces. Two logically equivalent XML files will contain two different data streams and may produce different digest values. The XML information sets must first be canonized be before extracting their bit information for signature processing. This helps prevent incorrect verification results. Place the <SignatureMethod> element that indicates the algorithm used to produce the signature value within the <SignedInfo> element.

11 Example <SignedInfo Id="foobar"> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" /> <Reference URI=" <DigestMethod Algorithm=" /> <DigestValue>j6lwx3rvEPHO0vKtMup4NbeVu8nk=</DigestValue> </Reference> <Reference URI=" <DigestMethod Algorithm=" <DigestValue>UrXLDLBIta6skoVF5/A8Q38GEw44=</DigestValue> </Reference> </SignedInfo> 4. Sign Figure 3 Calculate the digest of the <SignedInfo> element, sign the digest and put the signature value in a <SignatureValue> element. <SignatureValue>MC0E~LE=</SignatureValue> 5. Add the KeyInfo Figure 4 The KeyInfo element is optional. If any information about the Key that would be used for signature verification is to be added, place it in the KeyInfo element. It could contain the certificate from the sender that contains the public key needed for signature verification. 6. Add the Signature element Add the Signature element that wraps all the other element. Add the XMLDS namespace declaration ( in the SOAP envelope. Add the Signature element in the SOAP header. Example containing all the XMLDS elements

12 <?xml version="1.0" encoding="utf-8"?> <Signature xmlns=" <SignedInfo Id="foobar"> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" /> <Reference URI=" <DigestMethod Algorithm=" /> <DigestValue>j6lwx3rvEPO0vKDtMup4NbeVu8nk=</DigestValue> </Reference> <Reference URI=" <DigestMethod Algorithm=" <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0E~LE=</SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName> <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate> </X509Data> </KeyInfo> Validating an XML Signature </Signature> The steps involved in validating the XML signature are the following: Figure 5 1. Verify the signature of the <SignedInfo> element To verify the signature of the <SignedInfo> element, recalculate the digest of the <SignedInfo> element and use the public verification key to verify that the <SignatureValue> element is same as the calculated digest. 2. Verify the Digest values of the <Reference> elements Recalculate the digests of the references contained within the <SignedInfo> element and compare them to the values in the corresponding <DigestValue> elements.

13 4.2 XML Encryption XML Encryption is an encryption technology that is optimized for XML data. XML Encryption standard specifies the process of encrypting data and representing the result in an XML document. XML Encryption provides end-to-end security for applications that require secure exchange of structured data. The advantages include partial encryption which encrypts specific tags contained in XML data, multiple encryption, which encrypts data multiple times and complex encryption such as the designation of recipients who are allowed to decrypt respective portions of data. The use of XML Encryption also helps solve security problems including XML-data eavesdropping. XML itself is the most popular technology for structuring data, and therefore XML-based encryption is the natural way to handle complex requirements for security in data exchange applications. The data may be an XML element, an XML element content or any arbitrary data (including XML document). XML Encryption addresses two requirements, end-to-end security and selective encryption. (Java World, 2002) End-to-end security Consider an example of an online credit card payment. It involves three parties: a cardholder, an online merchant, and your bank. Ideally, all parties should be authenticated to one another, and the secure communication path should stretch from the cardholder all the way to the bank. But SSL/TLS is not designed for such a scenario. SSL/TLS only handles point-to-point security. Thus, if you rely only on SSL, you cannot send your credit card number to the bank through the merchant without the merchant knowing it. The same applies to Web Services, although at a slightly different level. Web Service application topologies include all sorts of devices, PCs, gateways etc. Consequently, many intermediaries come between two communicating parties. SSL/TLS may secure the path between any two, but not from one end to the other. To address this problem, we need XML Encryption Selective encryption Standards like S/MIME and PGP do ensure that a message can only be read by its intended recipient. Unfortunately, these standards (as well as SSL/TLS) treat each message as a whole; these standards cannot selectively encrypt part of an XML document. Such selective encryption capabilities will prove important, especially when it comes to a workflow scenario where a document may be processed by several applications, or signed, viewed, or approved by numerous people. Consider the example of the online payment again. In practice, many messages travel to and fro among the three parties before the payment itself happens. For example, a message travels from the consumer to the merchant to the bank. Such a message may contain two things: information about the goods bought and instructions for the bank to

14 pay the merchant. The bank does not need to know about the former and the merchant does not need to know about the latter. Therefore, the message must be partitioned in such a way that a merchant cannot see the bank's part of the message and vice versa. This is difficult to achieve. It is impossible with S/MIME or PGP because these standards will encrypt the entire XML document. XML Encryption's selective encryption feature, in contrast, allows an XML-based solution for such problems. XML encryption addresses the issue of data confidentiality using encryption techniques. Encrypted data is wrapped inside XML tags defined by the XML Encryption specification A simple example of secure exchange of XML data Consider the example of sending the following XML file to a publishing company. This file contains the details of a book that you want to purchase. In addition, it also contains your credit card information for payment. Hence you would like to use secure communication for this sensitive data. If the application requires the entire communication to be secure, SSL can be used. On the other hand, if the application requires a combination of secure and insecure communication (which means that some of the data will be securely exchanged and the rest will be exchanged as is) XML Encryption is the best choice. (IBM, 2002) <purchaseorder> <Order> <Item>book</Item> <Id> </Id> <Quantity>10</Quantity> </Order> <Payment> <CardId> </CardId> <CardName>abc</CardName> <ValidDate>11-04</ValidDate> </Payment> </purchaseorder> Figure 6 The XML Encryption specification satisfies confidentiality requirements in XML messages. XML encryption provides options for encrypting any of the following: A complete XML file Any single element of an XML file. Only the contents of an XML element. Non-XML data (e.g. a JPG image).

15 Encrypting a Complete XML File The following code fragment shows the resulting XML-encrypted file when the entire XML document is encrypted. Encrypting any XML file will produce the same XML structure, the only difference is the encrypted value wrapped inside the <CipherValue> element. (IBM, 2002) <?xml version='1.0'?> <EncryptedData xmlns=' Type=' types/text/xml'> <CipherData> <CipherValue>A123B456C7</CipherValue> </CipherData> </EncryptedData> Figure 7 The actual encrypted data appears as contents of the <CipherValue> tag. Therefore, encrypting the XML file produces the contents of the <CipherValue> element. The complete <CipherData> element appears within an <EncryptedData> element. The <EncryptedData> element has an attribute called xmlns that specifies the XML Encryption namespace used to encrypt the XML data. The other attribute of the <EncryptedData> element called Type is used to specify special application data types. (IBM, 2002) Encrypting a Single Element If you want to encrypt only one element of Figure 6, for example, the Payment element, the resulting XML-encrypted file is as follows: (IBM, 2002)

16 <?xml version='1.0'?> <PurchaseOrder> <Order> <Item>book</Item> <Id> </Id> <Quantity>6</Quantity> </Order> <EncryptedData Type=' xmlns=' #'> </EncryptedData> </PurchaseOrder> <CipherData> <CipherValue>A123B456C87</CipherValue> </CipherData> Figure 8 The above code fragment contains both XML Encryption as well as elements from the original data in Figure 6. In Figure 7, the XML Encryption is embedded inside the user's XML. Whenever an element of an XML file is encrypted, the identifier is used as the Type attribute value. This tells the recipient of the XML encrypted file that the encrypted data should be treated as an XML element. The value of the Type attribute, specifies that an XML element is encrypted. (IBM, 2002) Encrypting the Contents of an Element If you want to encrypt only the content in <CardId>, which is an element in Figure 1, the resulting XML-encrypted file is as follows: (IBM, 2002)

17 <?xml version='1.0'?> <PurchaseOrder> <Order> <Item>book</Item> <Id> </Id> <Quantity>6</Quantity> </Order> <Payment> <CardId> <EncryptedData Type=' xmlns=' <CipherData> <CipherValue>A123B456C87</CipherValue> </CipherData> </EncryptedData> </CardId> <CardName>pqr</CardName> <ValidDate>12-04</ValidDate> </Payment> </PurchaseOrder> Figure 9 The only difference between Figure 8 and Figure 9 is that #Content is used as the Type attribute value. This value will be used whenever we have to encrypt only the content and it specifies that the encrypted data should be treated as element content. (IBM, 2002) Encrypting non-xml data If you want to send a JPEG file through XML Encryption, the resulting file appears as follows: (IBM, 2002)

18 <?xml version='1.0'?> <EncryptedData xmlns=' Type=' types/jpeg' > <CipherData> <CipherValue>A123B456C87</CipherValue> </CipherData> </EncryptedData> Figure 10 The entire JPEG file in an encrypted sequence of bytes will appear as the content of the <CipherValue> element. The only difference between Figure 7 and Figure 10 is that the Type attribute of the <EncryptedData> element in Figure 10 includes the Internet Assigned Numbers Authority (IANA) type for the JPEG format. Similarly, it is possible to encrypt any format by providing IANA values. (IBM, 2002) 4.3 WS-Security WS-Security is a security specification from OASIS that can be used to add security to SOAP messages. It defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS- Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message. Now that we have seen what XML signatures and XML encryptions are, we will look at how to apply both to SOAP messaging using WSS specifications. WSS relies on XMLDS and XML encryption for low level details and defines the higher-level syntax to wrap security information inside the SOAP messages. WSS ensures three main security features: Message Integrity, User Authentication and Confidentiality Structure of WS Security A SOAP message using WSS specifications could have the following elements: (Bilal Siddiqui, 2003) 1. The SOAP: Envelope element has the namespace declarations for SOAP, WSS and XMLDS. 2. The SOAP:Header contains the <wsse:security> element that is the wrapper for all the necessary security information. It contains two elements: <wssse:binarysecuritytoken> element that is an electronic token that is required to shown when entering a restricted area. The security token could be a

19 login/password pair. Login/password pair is human readable token. There are binary security tokens like X509 certificate that could be included in this element. It has the following attributes: - ValueType attribute tells what binary security token is wrapped inside the <BinarySecurityToken> element - EncodingType attribute tell what encoding has been done on the binary security token. <ds:signature> element is same as that was discussed in the XMLDS. The <KeyInfo> element in <ds:signature> contains the <wsse:securitytokenreference>, which contains the reference to the security tokens that was indicated in the <wsse:binarysecuritytokens> element. The following example illustrates a SOAP message using the WS Security specifications.

20 Example <SOAP:Envelope xmlns:soap=" xmlns:wsse=" xmlns:ds=" <SOAP:Header> <wsse:security> <wsse:binarysecuritytoken ValueType=? EncodingType=? wsu:id=?> </wsse:binarysecuritytoken> <ds:signature> <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" -exc-c14n# "/> <ds:signaturemethod Algorithm=" <ds:reference URI=?> <ds:transforms> <ds:transform Algorithm=" </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue> <ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> </ds:signaturevalue> <ds:keyinfo> <wsse:securitytokenreference> <wsse:reference URI=?"/> </wsse:securitytokenreference></ds:keyinfo> </ds:signature> </wsse:security> </SOAP:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 11

21 4.4 Security Assertion Markup Language (SAML) The Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information such as authentication and authorization information between business partners over the Internet. SAML enables disparate security service systems to interoperate. It resides within a system's security mechanism to enable exchange of identity and entitlement with other services. The SAML specification does not define any new mechanisms or approaches for authentication or authorization. Instead it defines the structure of the documents that transmit security information among services. SAML delivers the following benefits: (Netegrity, 2001) Interoperability - With SAML, e-marketplaces, service providers, and end-user companies of all sizes can now securely exchange information about users, Web services and authorization information without requiring partners to change their current security solutions. SAML is the common language that determines how different systems communicate data about security. Open Solution - SAML is designed to work with multiple, industry-standard transport protocols such as HTTP, SMTP, FTP, and others. Single Sign-On Across Sites - SAML enables open and interoperable designs for web-based single sign-on service functionality across sites that are hosted by multiple companies. There has not been a secure, interoperable standard for exchanging secure sign-on information until now. SAML is the first one that offers this facility. Single sign-on is a mechanism in which a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, which is a major cause of system failures and is therefore highly desirable but difficult to implement. The second advantage of single sign-on is to enable sharing of authentication data between the sales and inventory applications. If a user is authenticated for one application, his authentication information is transferred to the second. The second application accepts the authentication information as such without going through all the authentication steps. There is no redundancy in this solution. The only requirement is that the two applications must trust each other so that each application accepts authentication data coming from the other. SAML supports single sign-on functionality by allowing users to authenticate themselves in one domain and use the resources in another domain without reauthenticating themselves. The user's authentication, authorization, profiles, and preferences are transmitted from an original source service provider to subsequent destination service providers selected by the user during the session. (Wiki, 2005).

22 4.4.1 Steps for exchanging authentication and authorization information: 1. The end-user submits credentials to the Authentication Authority (any security engine or business application that is SAML-aware). 2. Authentication Authority asserts the user s credentials against user directory and generates an Authentication Assertion together with one or more Attribute Assertions (e.g., role and other user profile information). An assertion is a declaration of a 'certain fact'about a subject, for example, a user or code. For example, an individual was authenticated by a particular method at a specific time, or that an application has been granted a certain class of access to a resource under certain conditions. The enduser is now authenticated and identified by an SAML token. 3. The end-user attempts to access a protected resource using his SAML token. 4. Policy Enforcement Point (PEP) is responsible for protecting access to one or more resources. When the user tries to access a resource, the PEP sends a description of the attempted access to a Policy Decision Point (PDP) in the form of an authorization decision request. 5. The PDP evaluates this request against its available policies and provides an authorization decision that is returned to the PEP. The PEP is responsible for enforcing the decision. If it authorizes access to the resource, it generates an Attribute Assertion attached to the user s SAML token. The end-user s SAML token can be presented to trusted business partners. (Netegrity, 2001) Syntax of an SAML Assertion The following code fragment describes an authentication statement in the form of an SAML assertion. An authentication statement specifies the outcome of an authentication, which took place in the past. The SAML authority authenticates a user and issues an assertion. (Siddiqui, 2003)

23 <?xml version="1.0" encoding="utf-8"?> <Assertion xmlns=? xmlns:ds=? MajorVersion= 1 MinorVersion= 0 AssertionID=? Issuer=? IssueInstant=?> <Conditions NotBefore=? NotOnOrAfter=?> <AuthenticationStatement AuthenticationMethod= urn:ietf:rfc:3075 AuthenticationInstant=?> <Subject> <NameIdentifier NameQualifier=? > </NameIdentifier> <SubjectConfirmation> <ConfirmationMethod>.</ConfirmationMethod> <ds:keyinfo> <ds:keyname>abckey</ds:keyname> <ds:keyvalue>... </ds:keyvalue> </ds:keyinfo> </SubjectConfirmation> </Subject> </AuthenticationStatement> <ds:signature>...</ds:signature> </Assertion> Figure 12 The root Assertion element encloses three types of information: a <Conditions> element, an <AuthenticationStatement> element and a <ds:signature> element. The Conditions element specifies two conditions for this assertion. The NotBefore attribute tells the time before which the assertion is not valid. Similarly, the NotOnOrAfter attribute specifies the time after which the assertion expires. The <AuthenticationStatement> states the outcome (the final result) of an authentication process. The other two elements (<Conditions> and <ds:signature>) are included for helper tasks. The <AuthenticationStatement> element contains two attributes and one child element. The first attribute of the element is <AuthenticationMethod>. The value of this attribute that we have used specifies that we used XML signatures to authenticate the subject. The second attribute AuthenticationInstant specifies the instant of time when the authentication took place.

24 The only child element is an element named <Subject>, identifying the subject of this assertion. The Subject element contains two child elements, a <NameIdentifier> element and a <SubjectConfirmation> element. The <NameIdentifier> element specifies the name of the subject. The <SubjectConfirmation> element, which specifies the relationship between the subject of an assertion and the author of the message that contains the assertion. In order to specify that the subject of an assertion and the author of the message that contains the assertion are the same, the <SubjectConfirmation> element includes two elements. The first is a <ConfirmationMethod> element and the second is a <ds:keyinfo> element. The two elements form a pair inside the <SubjectConfirmation> element. The <ConfirmationMethod> element specifies a method that a relying party will use to confirm the relationship between the subject of the assertion and the author of the message that contains the assertion. If the author of a message that contains an assertion can prove that he owns this key, then the relying party can be sure that the author is really the subject of the assertion. The <ds:signature> element is actually the signature of the assertion authority. The purpose of including the signature of the issuing authority is to allow the recipient of the assertion to verify that the assertion is not fake. (Siddiqui, 2003) 4.5 extensible Access Control Markup Language (XACML) The extensible Access Control Markup Language (XACML) is a simple, flexible way to express and enforce access control policies in a variety of environments, using a single language. The XACML language effectively protects content from unauthorized use in enterprise data exchanges by defining whether to permit requested access to a resource, whether it s an entire document, multiple documents, or a partial document. It is used in conjunction with SAML and it provides a means for standardizing access control decisions for XML documents. It defines a language for specifying how policy information linked to access control is articulated and conveyed. XACML receives an SAML request to determine if access should be granted to a resource based on rule sets, or policies, that are defined by the provider. As opposed to XML encryption, access control information is kept in a physically separate repository that is referenced when a request is made. Once the policy is evaluated and returns a true or false value to indicate whether or not access is granted, an SAML authorization decision assertion is returned, which is then processed accordingly. Multiple policy languages and formats have emerged over the years to control who is allowed access to what and under which conditions. Many of these languages are proprietary or apply only to specific applications, resulting in interoperability problems. Moreover, no current solution is adequate for the evolving world of inter-enterprise integration of supply chains, grid security, etc. None of the alternatives handle finegrained access control for XML documents. (Sun, 2005)

25 Hence we need a common language for expressing security policy, which provides a standard means of addressing access control and a standard that addresses the shortcomings and limitations of current solutions. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems. XACML has many benefits over other access control policy languages: (Sun, 2005) One standard access control policy language can replace dozens of applicationspecific languages Administrators save time and money because they don't need to rewrite their policies in many different languages Developers save time and money because they don't have to invent new policy languages and write code to support them. They can reuse existing code Good tools for writing and managing XACML policies will be developed, since they can be used with many applications XACML is flexible enough to accommodate most access control policy needs and extensible so that new requirements can be supported. One XACML policy can cover many resources. This helps avoid inconsistent policies on different resources. XACML allows one policy to refer to another. This is important for large organizations. For instance, a site-specific policy may refer to a company-wide policy and a country-specific policy. 4.6 XML Key Management Specification (XKMS) The XML Key Management Services (XKMS) describe a method for clients to securely access public key-related services such as key generation, registration and revocation. When you are sending secure Web Services messages, you need a way to verify signatures or obtain public keys to verify the identity of the sender. XML Key Management Services is a way to formalize the way you handle that process. It's independent of the type of key or encryption and the protocol, although a conforming implementation must work over HTTP with SOAP. It also includes methods for the validation of certificates and signatures. In essence, XKMS buffers applications from dealing with the complexities of PKI. XKMS allows applications to delegate the details of this task to remote or local Web services. The XML Key Management Specification (XKMS) comprises of two parts - the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). XML Key Information Service Specification: X-KISS defines a protocol for resolving or validating public keys contained in signed and encrypted XML documents. It provides a way in which an application can delegate the actual work of

26 requesting or verifying an ID to a service including processing of key information associated with an XML signature, XML encryption, or other public keys. Its functions include the location of required public keys and describing the binding of such keys to identification information. XML Key Registration Service Specification: X-KRSS enables a client to request the generation of a public and private key, or information such as a name or other attributes being bound to a private key. X-KRSS defines a protocol for public key registration, revocation or recovery of keys. PKI is important for E-commerce and Web services. However, one of the obstacles to the wide adoption of PKI is that PKI operations such as public key validation, registration, recovery and revocation are complex and require large amounts of computing resources, which prevents some applications and small devices such as cell phones from participating in PKI-based E-commerce or Web Services transactions. XKMS enables an XKMS server to perform these PKI operations. In other words, applications and small devices can ask the XKMS server to perform the PKI operations by sending XKMS messages over SOAP (Simple Object Access Protocol). In this regard, the XKMS server provides trust services to its clients in the form of Web services. 5. Conclusion Securing Web services is complex and overwhelming. Security must be incorporated into the planned requirements from the very beginning. Also, security should be enforced throughout the infrastructure, both electronically and physically. Standards related to security are being developed by many standards organizations. Some of these standards are mature enough to be incorporated into most Web services applications today. Security for Web services is a necessity and can be deployed. The paper provides a review of current efforts in developing security techniques for Web services. Securing Web Services is not an insurmountable challenge. With the right combination of network, transport and application security, companies can deploy Web Services in a secure manner. A comprehensive and consistent approach guarantees the integrity and confidentiality of SOAP messages as well as the authorized use of Web Services. Given the number of technologies that must interoperate, and the different security domains that must cooperate, a security solution is required that spans the entire integrated architecture and which distributes security policy enforcement to all points. XML and Web Services security is based upon the familiar principles: access control and content filtering. For a truly secure framework, any solution must incorporate both elements.