Elegant Report



University of Colorado, Colorado Springs

Maria Lizarraga

CS691

WEB SERVICE SECURITY

ADVANCED SYSTEM SECURITY DESIGN

Table of Contents

Introduction 3

WEB SERVICES ARCHITECTURE 3

COMMUNICATION 4

SOAP MESSAGES 4

SECURITY IN WEB SERVICES 5

XML DIGITAL SIGNATURES 6

XML ENCRYPTION 7

BASIC AUTHENTICATION 8

IMPLEMENTING SECURITY WITHIN WEBSPHERE 8

SUMMARY 8

REFERENCES 9

APPENDIX 10

XML DIGITAL SIGNATURE EXAMPLE 10

XML ENCRYPTION EXAMPLE 12

BASIC AUTHORIZATION EXAMPLE 14

WEB SERVICE SECURITY

Advanced System Security Design

Introduction

An important benefit of web services is being able to programmatically access remote data easily. There is no need for human intervention. If the service is between two businesses, they will most likely want to share private information. They will want to limit access to the data, they will want on ensure the data does not get corrupted, and they will not want others to see the data as it passes over the network. Today’s firewalls are XML aware. Web services can take advantage of XML security standards to implement security within a web service.

To begin this discussion, I first briefly discuss the web service architecture and how the communication process works. Then I will get in to the specific techniques that can be used to secure the service.

Web Services Architecture

There are three entities that communicate with each other during the lifecycle of a web service. These entities are depicted in figure 1. They use HTTP to communicate with each other. There are 3 communication links—server/client, server/registry, and client/registry. Security can be a concern on all links.

[pic]

• Figure 1. Web Service Architecture

All links use Simple Object Access Protocol, SOAP, messages embedded into HTTP. Security is enabled in the SOAP message through XML security technologies.

Communication

Web services are transmitted to the server using SOAP messages over HTTP. With a traditional network layer firewall, if the user was authenticated at the firewall, the message would be routed to the web server, as shown in figure 2. However, if a service had limited access, the firewall was not able to read into the SOAP message to determine whether the user had privileges to use the service or not. Any user who made it through the firewall was able to use the service. The SOAP server does not handle security.

[pic]

• Figure 2. Web Service Communication Through a Traditional Firewall

Nowadays, firewalls are XML aware and can look at the application layer. SOAP messages adhere to a standard XML format to transmit information. This makes SOAP messages a perfect vehicle for supplying the security information necessary for the XML firewall to determine whether to authorize a client to use a service. Only those authorized to utilize the service are forwarded to the SOAP server. Let’s take a look at the structure of the SOAP message.

SOAP Messages

The SOAP message contains three parts—an envelope, a header, and the body. The header is optional. The header and the body go into the envelope. A message can have attachments. Video or image files can be sent as attachments. Let’s take a look at the first three elements a little closer.

Envelope

The envelope must contain the opening and closing envelope tags. These tags make it a SOAP message. The attribute xmlns: defines what namespace to use. The envelope must contain a soap envelope namespace. In this case, it is:



This is what a typical soap envelope looks like:

...

Header

The header is an optional element. There can be more than one header element. If used, it must be the first child element. One use of the header is to supply security processing information. For basic operation this element is not used. I will be going into detail on the contents of header as it is used for security.

Body

The soap tag is soap:Body. Inside the body is the message. In the example below, the setStudents is the web service operation accessed. It asks for a list of students.

SOAP Message

Put all the parts together along with the HTTP you get:

POST /GradesService/services/GradesService HTTP/1.0

Content-Type: text/xml; charset=utf-8

Accept: application/soap+xml, application/dime, multipart/related, text/*

User-Agent: IBM WebServices/1.0

Host: localhost:9080

Cache-Control: no-cache

Pragma: no-cache

SOAPAction: ""

Content-Length: 356

Security in wEb Services

WS-Security specification outlines the standards for implementing

• message integrity,

• message confidentiality, and

• single message authentication

services in SOAP messages. They leverage the XML Signature and XML Encryptions standards. Let’s see how security services are implemented in SOAP messages by looking at specific examples.

XML Digital Signatures

This example will look at:

• message integrity

• message authentication, and

• user authentication

of a SOAP message. Integrity is ensured by obtaining the message digest of the part of the message requiring this sercurity service and signing it with the sender’s private key. By signing it with the sender’s private key, message and user authentication is established.

The security information is in the header of the message. XML elements are defined within matching tags. There are 2 main sections in a message providing a digital signature. They are described within the and tags. These tags, the sub elements, and attributes are described below.

• -- This section is for specifying the encoding format for binary encoded security tokens.

o EncodingType -- Encoding used on Security Token

o ValueType --

o ID

▪ Encoded Digital Certificate

• -- Signature specific information. It contains the following three subsections:

o -- Processing information

▪ -- Normalizing data algorithm

▪ -- Signature algorithm

▪ -- Points to signed content

• -- How to process data

• -- Hashing algorithm

•

o -- Value of the signed data

o -- Optional key identifier (such as a public key/symmetric key)

▪

• Reference -- Refers to public key inside

Digital Certificate

The first tag is . A token is a piece of security information used for authentication. The token can be a login/password or digital certificate. A digital certificate is binary encoded. It has to be converted to ASCII before it can be sent in the message. The indicates that a binary token is being sent and the method used to convert it to ASCII.

In the appendix, there is a XML Digital Signatures Example. In that example, the token is an X509.v3 digital certificate which uses Base64-encoded to convert it to ASCII. It is given an ID. This ID is referenced later in the section below.

The second main section is the section. This section contains the details of the signature. It has three sub sections--, and .

The tag has the signature processing information. The first processing tag is . This indicates that the data must first be normalized. Attributes can occur in any order and white space can be added to change the data. Canonicalization standardizes the data so that the input to the message digest is the same and therefore the same message digest is achieved for the section. The indicates the algorithm used to obtain the message digest. The example in the appendix uses SHA-1. The tag is next. The reference has an URI attribute. This attribute will point to the section for which the message digest is obtained. In the example in the appendix, the URI points to the . The first child is . This indicates any transformation that need to occur to the data before applying the message digest. In the example, it indicates that the data has to be canonicalized first. Schemas can also be applied at this point prior to signing the data. The indicates the method used for the message digest. This is SHA-1 in the example. The next section gives the digest value. In the example, this is the message digest of the .

The next tag is . This is the signed value of the section. Note that the message digest is in the part. Therefore, the signed valued has the message digest value of the body contained in it.

The key used to decrypt the signed valued is in the part. The indicates that the enclosed token, the digital certificate supplied above, is to be used to decrypt the . In the example, it provides a that points to the section above.

To check the integrity of the message, the receiver must first canonicalize the section. The message digest algorithm is applied to the section that is indicated within the element; in our example it points to the . If that checks out OK, the receiver uses the sender’s public key to decrypt the signature value and compare to the value they obtained for the section.

XML Encryption

For confidentiality, the symmetric key is used to encrypt the body. The symmetric key is encrypted with the recipient’s public key. Below are the tags that are used to do this. The contains the symmetric key information. The specifics of the key are in the children tags. For this section, refer to XML Encryption Example in the appendix.

• -- Symmetric key information

o -- Method of Encryption

o -- Encrypted Key Identifier

▪

•

o

▪ -- Encrypted Symmetric Key

o -- Reference to the encrypted text

The first child is the tag. This tag indicates the method of encryption of the symmetric key. The example in the appendix uses RSA. The next child, , is similar to covered in the XML Digital Signature section. This time, however, the key doesn’t point to a digital certificate in a section. It instead tells indicates a . It identifies the symmetric key. The encrypted symmetric key is within . The URI in the points to the . The contains the encrypted data instead of the plain data.

The receiver of the message first has to decrypt the symmetric key with their private key. Then the symmetric key is used to decrypt the in the .

Basic Authentication

For basic authentication, a is provided, as shown in the Basic Authentication Example. The has two children-- and . Note that they are not encrypted in this example. The encryption technique already discussed can be used to encrypt the password. The server firewall can authorize usage of the service based on the and . The tags look like the following.

• < UsernameToken>

o

o

Implementing Security Within WebSphere

Some of the security features built into XML are provide by web services development platforms. The following two are built in to IBM’s WebSphere web services development platform:

• XML Encryption and

• XML Digital Signature

WebSphere allows you to choose between these two options. They cannot be implemented simultaneously with the wizard and can only be employed on the body of the message.

Without the use of the wizard, security tokens for basic authentication can be added. Also, you can add additional digital signatures or encryption. Encryption is not limited to the body of the message. Any element of the message can be encrypted.

Other security tokens are available in WebSphere including:

• IDAssertions used for single sign on and

• LTPA, Lightweight Third Party Authentication, used for single sign on with other client attributes.

Summary

As web services become more popular, so does the need for security of these web services. Web services development platforms provide this capability. Wizards make implementing security easy. However, wizards are not capable of doing everything. Therefore, when working with web services, it is important you understand how security services of confidentiality, integrity, and authentication are implemented within a SOAP message.

References

• The Java Web Services Tutorial 1.0, August 7, 2002,

• Build secure Web services with WebSphere Studio, Indran Naick and Jeffrey Miller,

• Getting Started with XML Security, Frederick Hirsch,

• XML Signature WG (specification),

• XML Encryption WG (specification),

• OASIS Security Services (SAML) TC,

• OASIS eXtensible Access Control Markup Language (XACML) TC,

• SOAP Tutorial,

• Specification: Web Services Security (WS-Security),

• Web Services Security Part 1,

• Web Services Security, Part 2,

• Web Services Security, Part 3,

• Web Services Security, Part 4,

Appendix

XML Digital Signature Example

MIIDQTCCAqqgAwIBAgICAQQwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCSlAxETAP

BgNVBAgTCEthbmFnYXdhMQwwCgYDVQQKEwNJQk0xDDAKBgNVBAsTA1RSTDEQMA4GA1UE

AxMHSW50IENBMjAeFw0wMTEwMDEwOTU0MDZaFw0xMTEwMDEwOTU0MDZaMFQxCzAJBgNV

BAYTAkpQMREwDwYDVQQIEwhLYW5hZ2F3YTEMMAoGA1UEChMDSUJNMQwwCgYDVQQLEwNU

UkwxFjAUBgNVBAMTDVNPQVBSZXF1ZXN0ZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ

AoGBAMy3PfZ1mPhrEsBvYiOuIlPV3Uis5Yy6hmxo2YwYC2nNDBPzKslWUi/Q+fK+DNdY

6KEHmuDrcVcEma48J9X1a5avRlksQfKptKoVn4eBys2i/wkwyzQhDaFji79/MvnTRW8E

Vy99FNKw4PFnhOoe1tlDcNBuIH/fIuGOz9ElTV+fAgMBAAGjggEmMIIBIjAJBgNVHRME

AjAAMAsGA1UdDwQEAwIF4DAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQg

Q2VydGlmaWNhdGUwHQYDVR0OBBYEFIW3FD1cXie4j4zw1gAp4cuOAZ4lMIG6BgNVHSME

gbIwga+AFL35INU4+WRy09vaf9zOsP7QvO9voYGSpIGPMIGMMQswCQYDVQQGEwJKUDER

MA8GA1UECBMIS2FuYWdhd2ExDzANBgNVBAcTBllhbWF0bzEMMAoGA1UEChMDSUJNMQww

CgYDVQQLEwNUUkwxGTAXBgNVBAMTEFNPQVAgMi4xIFRlc3QgQ0ExIjAgBgkqhkiG9w0B

CQEWE21hcnV5YW1hQGpwLmlibS5jb22CAgEBMA0GCSqGSIb3DQEBBQUAA4GBAHkthdGD

gCvdIL9/vXUo74xpfOQd/rr1owBmMdb1TWdOyzwbOHC7lkUlnKrkI7SofwSLSDUP571i

iMXUx3tRdmAVCoDMMFuDXh9V7212luXccx0s1S5KN0D3xW97LLNegQC0/b+aFD8XKw2U

5ZtwbnFTRgs097dmz09RosDKkLlM

A0mOizFBq9p2ZzTYULxZ8sm/86E=

RWzwnZabmx94yc62lCC9GSDRNRLYmdOFBfAKCyBunBw1fNx+ANP0kigtUnYJ

B+wcSBrforI3TpJQrrl8f1JcfgZtGsPvnh8Uy5uHJZ8vPhBcbUbM1cSPUQA/

QAiFdtKS7hZdMsH/yuonAH9fXFb8dI/YlX5dq+nl6mX2EFZZ/ho=

Mary

XML Encryption Example

/62wXObED7z6c1yX7QkvN1thQdY=

IBKh4fn7TwL6P4zfPzuE3U90MYEMbqJqx+kg25FRwZF/P+Nm3jNrPkXIdtbjQgJk

Xn3SKh/BiuiC8xSsvyQx4btbRiIalE9psVBNrYKabkgjsElA9N7PqnIHV0hO/9rf

Lti/ljPBh+wfTPsbtU8c1eRl7x3dGF7Ru7gVD3763BA=

BQvc1SVeJnayDco0wAettaMyT1CkqgdOszlNoPOVx+ISk3GG6PHZcWE8qhQlinls

24XO7Zk6QK2Xp4SavgoZCrK7MJiF/4u1YwwX/b16nO0L55EfwjAeow==

Basic Authorization Example

xmlns:soapenc=""

xmlns:soapenc=""

xmlns:soapenc=""

/62wXObED7z6c1yX7QkvN1thQdY=

xmlns:soapenc=""

O7di9F7WV6Astaa2MY7vyHtn68kkJzoO5haTIXcpJ9iX2ME/95e3KQvXEvlJPP7D

FWhX0Jd1UK5hOZAVNjWvymCrFaqRmkc5FZV2lCfISd2GFZyFy7dpac/vsDFknrf4

pOnB2mpKQgqSzEr11RUePeNFv2fJK4PBpuXyEVlwLTM=

myUserName

myPassWord

PD0/cCbsLwTkDzdKzhAHIeyWri6zMyK7uWnZqzHigAP0qTHpsBgrbYeBrsXCb6sJ

ZEnTQ9Yu3SjKmxYLaR0dLFmtsf0hCgor41+q1xbw5qVspDgoIY55sg==

-----------------------

.

.

.

.

.

.

.

.

.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download