Web Services Security and Interoperability

Bjarne Rasmussen

Manager, Messaging Technology

Novell, Inc.

Vijay Rajan

Senior Engineer

Novell, Inc.

one Net: Information without boundaries…where the right people are connected with the right information
at the right time to make the right decisions.

The one Net vision

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:

The one Net vision

Novell exteNd solutions provide you with a range of advanced Web application development tools to liberate information and create more effective business solutions for your customers, partners, and employees.

Novell exteNd™

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:

Agenda

Brief Introduction to Web Services

Web Services Security

WS-I (Web Services Interoperability) Organization

WS-I Sample Application & Demo

Summary

Brief Introduction to Web Services

Brief Introduction to Web Services

What it is ?

Basically a transparent and flexible mechanism to perform Remote Procedure Calls and Message Passing

Differentiation from previous technologies

Internet based (i.e. accessible through standard-based Internet protocols such as HTTP)

Language & platform independent

Based on open standards

Firewall-friendly

Inherently loosely coupled (suitable for SOA)

Based on standardized (XML) as opposed to proprietary binary standards

Characteristics of Web Service

WSDL (Web Services Description Language) to describe the interface to a service

UDDI (Universal Description, Discovery and Integration of Web Services) to advertise and lookup services

SOAP (Simple Object Access Protocol) used for message passing

HTTP transport to carry the SOAP messages

Key to Web Services is the unification of the industry around these standards

Extensible Markup Language (XML)

Cornerstone of technology to permit interoperable communication

Ideal for representing data

Generic and language neutral way to represent structured and typed data

XML incorporated into several networking protocols in order to provide a standard way to applications to communicate – one such example is SOAP

WSDL also based on XML

Simple and extensible mechanism to represent complex documents

Simple Object Access Protocol (SOAP)

<SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header>

...

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<ns1:sayHello

xmlns:ns1="http://www.hello" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

SOAP block

SOAP block

SOAP block

SOAP block

SOAP body

SOAP header

SOAP envelope

Web Service Stack

Client

Server

Skeleton

Stub

Web Service

runtime

Web Service

runtime

HTTP

HTTP

Internet

SOAP

SOAP

RPC vs Document Style

RPC mechanism provides a way to represent a remote procedure call and its return value

In RPC style the SOAP Body contains a single SOAP struct

The direct child of the Body contains the method name

The method element contains the parameters in the same order as the method signature

The parameters are accessible via an accessor (either a tag or an original value for arrays)

Document style does not contain the method name or parameter accessors

Encoded vs Literal

Encoding rules provide a convention for serializing datatypes into a XML representation

soap:encodingStyle attribute is used to indicate the encoding rules used in the message

http://schemas.xmlsoap.org/soap/encoding/ refers to rules based on the schema for SOAP 1.1

In the literal case messages are an instance of the XML schema and look exactly as described in the schema.

Due to the complexity created by encoding, WS-I Basic Profile prefers the use of literal, non-encoded XML

Security

Security Needs

Web Service Infrastructure

Authentication

Data Integrity

Data Confidentiality

Combining Identity and Web Services

Authentication

Authorization and Access Control

Single sign-on

Identity

Authentication

Ensure identity of the user or service

Various authentication mechanisms

Mature industry standards exist

HTTP Authentication

Basic

Digest

NTLM

Secure Socket Layer (SSL)

UsernameToken (OASIS WS-Security)

Data Integrity

Ensure that information has not been modified

Can also be used to identify sender of information

Secure Socket Layer (SSL)

Only point to point

Cannot be applied to parts of the information

Difficult for workflow applications, SOAP intermediaries etc.

No security for persistent data

Introduces transport dependency

XML Digital Signature - W3C

WS-Security (Web Services Security) – OASIS

WS-I Basic Security Profile 1.0 (work in progress)

Data Confidentiality

Protect information from unauthorized viewing

Secure Socket Layer (SSL)

Same issues as in data integrity

XML Encryption - W3C

WS-Security (Web Services Security) – OASIS

Symmetric and Public Key Encryption

WS-I Basic Security Profile 1.0 (work in progress)

WSSDK APIs for Authentication

stub.setProperty(PROPERTY_NAME, value);

PROPERTY_NAME

javax.xml.rpc.Stub.USERNAME_PROPERTY

javax.xml.rpc.Stub.PASSWORD_PROPERTY

com.sssw.jbroker.web.portable.Stub.AUTH_SCHEME

BASIC_AUTH_SCHEME

DIGEST_AUTH_SCHEME

NTLM_AUTH_SCHEME

com.sssw.jbroker.web.portable.Stub.NTLM_HOST

com.sssw.jbroker.web.portable.Stub.NTLM_DOMAIN

Basic Authentication

// set basic authentication properties

stub.setProperty(USERNAME_PROPERTY, “username”);

stub.setProperty(PASSWORD_PROPERTY, “password”);

Stub properties

Basic Authentication: HTTP Header

POST /services/hello HTTP/1.1

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

Content-Length: 297

soapAction: ""

Authorization: Basic dG9tY2F0OnRvbWNhdA==

User-Agent: Jakarta Commons-HttpClient/2.0rc1

Host: localhost:80

<?xml version="1.0" encoding="utf-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

......

</SOAP-ENV:Envelope>

Digest Authentication

// set digest authentication properties

stub.setProperty(USERNAME_PROPERTY, “username”);

stub.setProperty(PASSWORD_PROPERTY, “password”);

stub.setProperty(AUTH_SCHEME, DIGEST_AUTH_SCHEME);

Stub properties

NTLM Authentication

// set NTLM authentication properties

stub.setProperty(USERNAME_PROPERTY, “username”);

stub.setProperty(PASSWORD_PROPERTY, “password”);

stub.setProperty(AUTH_SCHEME, NTLM_AUTH_SCHEME);

stub.setProperty(NTLM_HOST, “host”);

stub.setProperty(NTLM_DOMAIN, “host”);

Stub properties

Public Key Cryptography

Encryption/Decryption Keys used in pairs

One key used to encrypt (transform) the data

Only the other key can decrypt the data

Public/Private Key pair

Computationally infeasible to derive one key from the other

Digital Certificates

Binding between public key and its owner

WSSDK SSL Support

SSL support provided through stub

Set properties for various SSL parameters

Certificates

Private key to be used for encryption

SSL transport handler takes care of negotiation between client and server

SSL

WSSDK SSL Configuration

// set certificate chain

File certFile = new File(“clientCertChain.der”);

byte[][] certChain = loadChainFromFile(certFile);

stub.setProperty(SSLProperties.WSSDK_SSL_CERT_CHAIN, certChain);

// set private key

File keyFile = new File(“clientKey.pkcs8”);

byte[] prvKey = loadFromFile(keyFile);

stub.setProperty(SSLProperties.WSSDK_SSL_PRIVATE_KEY, prvKey);

// set pass phrase

stub.setProperty(SSLProperties.WSSDK_SSL_PASS_PHRASE, “password”);

// set root CAs

byte[][] rootCAs = getRootCAs();

stub.setProperty(SSLProperties.WSSDK_SSL_ROOT_CA_CERTS, rootCAs);

Stub properties

Digital Signature

First Step is to generate a “hash”

For message M, generate H(M)

Need to prevent H(M) from being modified

HMAC (Hashed Message Authentication Code)

Public Key Cryptography

Send M and {H(M)}private-key (Signature)

Receiver computes H'(M) and checks if it matches with decrypted Signature

WS Security Header

<SOAP-ENV:Envelope ...>

<SOAP-ENV:Header>

....

<wsse:Security SOAP-ENV:mustUnderstand="1" xmlns:wsse"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

....

</wsse:Security>

.....

</SOAP-ENV:Header>

......

</SOAP-ENV:Envelope>

WS Security Continued....

<wsse:Security SOAP-ENV:mustUnderstand="1" xmlns:wsse"...">

<wsse:UsernameToken use:Id="....">

<wsse:Username>....</wsse:Username>

</wsse:UsernameToken>

<wsse:BinarySecurityToken EncodingType=".." ValueType="..">

........

</wsse:BinarySecurityToken>

<ds:Signature ... xmlns:ds=”.....>

.........

</ds:Signature>

<xenc:EncryptedKey ... xmlns:xenc=”.....>

.........

</xenc:EncryptedKey>

</wsse:Security>

WS Security Continued....

<wsse:BinarySecurityToken xmlns:wsu="..." ValueType="..." EncodingType="....." wsu:Id="CertId-1454099">

MIICYDCCAcmgAwIBAgIQNHArdwcE/7xw9tt+unwB2zANBgkqhkiG9w0BAQUFADBDM

</wsse:BinarySecurityToken>

<wsse:SecurityTokenReference xmlns:wsu="...">

<wsse:Reference URI="#CertId-1454099"/>

</wsse:SecurityTokenReference>

WSSDK APIs for WSS Signatures

// set this property to sign outgoing messages

stub.setProperty(XMLSignatureProperties.SIGN_OUTGOING,

Boolean.TRUE);

// set this property to validate incoming messages

stub.setProperty(XMLSignatureProperties.VALIDATE_INCOMING,

Boolean.TRUE);

// set key store for certificates

KeyStore ks = KeyStore.getInstance("JKS");

// ...

// signature method

stub.setProperty(XMLSignatureProperties.SIGNATURE_METHOD_URI,

XMLSignatureProperties.ALGO_ID_SIGNATURE_RSA);

Stub properties

APIs for WSS Signatures Cont’d …

// digest method

stub.setProperty(XMLSignatureProperties.DIGEST_URI,

XMLSignatureProperties.ALGO_ID_DIGEST_SHA1);

// transforms

String[] tsfms = new String[] {

XMLSignatureProperties.TRANSFORM_ENVELOPED_SIGNATURE,

};

stub.setProperty(XMLSignatureProperties.TRANSFORM_URIS, tsfms);

// canonicalization method

stub.setProperty(XMLSignatureProperties.CANONICALIZATION_METHOD_URI,

XMLSignatureProperties.ALGO_ID_C14N_OMIT_COMMENTS);

Stub properties

Stub properties

APIs for WSS Signatures Cont’d …

// key info certificate

X509Certificate cert = (X509Certificate) ks.getCertificate("test");

stub.setProperty(XMLSignatureProperties.CERTIFICATE,

cert.getEncoded());

// validation public key

stub.setProperty(XMLSignatureProperties.VALIDATION_PUBLIC_KEY,

cert.getPublicKey().getEncoded());

// signing key

PrivateKey privateKey = (PrivateKey) ks.getKey("test", secret);

byte[] prvKeyBytes = privateKey.getEncoded();

stub.setProperty(XMLSignatureProperties.PRIVATE_KEY, prvKeyBytes);

Stub properties

Stub properties

SOAP Message with WSS Signature

<SOAP-ENV:Envelope ...>

<SOAP-ENV:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://...."/>

<ds:SignatureMethod Algorithm="http://...."/>

<ds:Reference URI="#id-32486590">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/...."/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/...."/>

<ds:DigestValue>w22BXO84rYix5VdLJhh7+v67KpU=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

Message with WSS Signature Cont'd ...

<ds:SignatureValue>

J01xJ/X6zTzamy/5UvcqLY+Jcia/D5QDm7o23Shtm3Vr+IaiJKG3QWDrM/WSe

vk2P8YTkbyRr0ZalVKbh+uRqWq1yf1suBdTfEMXjwXsxEbprVP5r7RXt9Rq8GtAPr9Kgus6dqOXUaa32Je565ftPFgKrnww=

</ds:SignatureValue>

<ds:KeyInfo>

<wsse:SecurityTokenReference ...>

<wsse:Reference URI="#CertId-1454099"/>

</wsse:SecurityTokenReference>

</ds:KeyInfo>

</ds:Signature>

</wsse:Security>

</SOAP-ENV:Header>

<SOAP-ENV:Body xmlns:wsu="..." wsu:Id="id-32486590">

...

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Encryption – Public, private & secret

Asymmetric Key - using Public and Private Keys

Can only encrypt data of limited size

Symmetric Key

Need to have a common shared Key

Faster performance, no size limit

Asymmetric encryption to send secret Key

Generate a random secret Key and encrypt using receiver's public Key.

SOAP Message with WSS Encryption

<SOAP-ENV:Envelope ...>

<SOAP-ENV:Header>

<wsse:Security ... xmlns:wsse="...">

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/....">

<xenc:EncryptionMethod Algorithm="http://....#rsa-1_5"/>

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<wsse:SecurityTokenReference>

<wsse:KeyIdentifier ..>lE5aEvMfbq8V62s=</wsse:KeyIdentifier>

</wsse:SecurityTokenReference>

</ds:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>LjZiNGjx1EEzGxQ+WIS7G</xenc:CipherValue>

</xenc:CipherData>

<xenc:ReferenceList>

<xenc:DataReference URI="#EncDataId-3089045"/>

</xenc:ReferenceList>

</xenc:EncryptedKey>

</wsse:Security>

Message with WSS Encryption Cont'd ..

</SOAP-ENV:Header>

<SOAP-ENV:Body xmlns:wsu="...." wsu:Id="id-3089045">

<xenc:EncryptedData Id="EncDataId-3089045" xmlns:xenc="..." Type="http://www.w3.org/2001/04/xmlenc#Content">

<xenc:EncryptionMethod Algorithm="http://...#aes128-cbc"/>

<xenc:CipherData>

<xenc:CipherValue>

TpS3kJ+NIMa7c+vMjAQamaASBKxeRCdLB3tGn7yCp1AD8Z7h0tVJ3bAcCRtyg

Bf3dSCLNgAiQ7QdbUCtJMABlqQoGNrjbyR5HTjD1n7MXVxR1fhjuTMfgiZMTc

80wr3GXCyyBF27yte7YCPOn6tDcFVCWeYexL65TGQ86rcx2Do15fTfer0nmr6

KmJG7aP6pbEeUnlh9DKkzkFV1EbvKnwXTAp1QEvkLNi6+kCKpIRX12YCijMG/

5d6ILl4hbrpZTr8uxcCOopkOKd6+YOd4WIDu2R+OWv3E/M4VbC4abcVAUDDC8

</xenc:CipherValue>

</xenc:CipherData>

</xenc:EncryptedData>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Web Services Interoperability

Web Services Interoperability (WS-I) Organization

Open Industry effort to promote Web Services interoperability across platforms, applications, and programming languages

Members include software vendors, system integrators, enterprise customers, and many others

Provide guidance, recommended practices, and support resources for developing interoperable Web Services

Not a standards organization

Guidance, clarity, best-practices based on industry standards, such as XML, SOAP, UDDI, WSDL, etc.

WS-I Deliverables

Profiles – Sets of specifications based on Web Services standards to simplify implementation and promote interoperability

Sample Implementations – Application to exercise main features of the profile & demonstrate interoperability

Implementation Guidelines – Recommendations for use of specifications in ways proven to be most interoperable

Sniffer – monitor and log interactions with Web Services

Analyzer – Process sniffer logs and verify that the Web Services comply with the profile

WS-I Basic Profile 1.0

Set of non-proprietary Web services specifications, along with clarifications and amendments of those specifications which promote interoperability

Impossible to completely guarantee interoperability

Address the most common problems

Testing achieved in a non-intrusive manner (by examining artifacts - WSDL, SOAP Messages)

Only addresses inconsistencies and design flaws in referenced specifications that affect interoperability

Profile's scope is bounded by the specifications referenced by it

Scope is further refined by extensibility points

WS-I Sample Application 1.0

Supply Chain Management Application

Model a simplified supply chain management scenario

Demonstrate features in WS-I Basic Profile 1.0

Showcase interoperability between all vendor implementations (BEA, Bowstreet, Corillian, IBM, Microsoft, Novell, Oracle, Quovadx, SAP, Sun)

Documents & Implementation

WS-I SCM Use Cases 1.0

WS-I SCM Usage Scenarios

WS-I SCM Technical Architecture 1.0

Sample Application 1.0 implementations

Supply Chain Example

Customer Data

Configure

Place Order

Order Status

Order Tracking

Configurator

Retailer

Warehouse

WarehouseCallback

Manufacturer

Logging Facility

Request/Response

One Way

Basic Callback

Interoperability Demo

WS-I work in progress (Continued involvement by Novell)

Attachment Profile 1.0

Sample Application

Mid 2004

WS-1 Testing Tools not yet ready

Basic Security Profile 1.0

Profile work in progress

Mid 2005

WS-1 Testing Tools not yet ready

Conclusion

Significant advances in Web Services Interoperability

WS-I Basic Profile 1.0

WS-I Attachment Profile 1.0

Evolving standards in Web Services Security

WS-I Basic Security Profile

Continued involvement with standards organizations

Novell WSSDK supports all features in WS-I Profile plus features not used in the profile (e.g. rpc/encoded)

Recommended to follow WS-I profiles when interoperability with other vendors is critical

This represents our one Net vision. As a company, we are committed to providing solutions to your business problems based on the fulfillment of this strategic framework. Since we announced one Net in 1999, we have been working to identify and develop the technologies, products and solution suites that make the vision a reality for our customers. One Net brings you closer to a world where networks of all types work together seamlessly, so you can connect employees, customers, suppliers and partners across organizational boundaries – and give them faster, easier and more secure access to all the information and resources they need, when and where they need it. And our fulfillment of the one Net strategic framework translates directly into business solutions that offer more opportunity, higher ROI and closer, more productive relationships with you and everyone who matters to your business.

Let’s take a brief tour of one Net to help set the context for our discussion today.

Starting in the center, our Ngage teams employ proven methodologies and expertise, training, and support at all levels of your organization to facilitate the design, development and deployment of secure, scalable business solutions.

Novell exteNd, our integrated development environment for the creation of Web services-based solutions help transform rigid “silo” applications into personalized, standards-based, process-driven secure Web solutions.

Novell Nsure, our secure identity management solutions family, delivers your enterprise resources and business information based on who people are and what they need, wherever they need it.

Novell Nterprise, our cross platform network services suites, add invaluable capabilities to all kinds of mixed networks and diverse infrastructures. Nterprise solutions are the embodiment of this philosophy. We will deliver and support the services on the platforms our customers and the market demand. Today and in the foreseeable future, Linux running on Intel is the platform the market and our customers are demanding.

This represents our one Net vision. As a company, we are committed to providing solutions to your business problems based on the fulfillment of this strategic framework. Since we announced one Net in 1999, we have been working to identify and develop the technologies, products and solution suites that make the vision a reality for our customers. One Net brings you closer to a world where networks of all types work together seamlessly, so you can connect employees, customers, suppliers and partners across organizational boundaries – and give them faster, easier and more secure access to all the information and resources they need, when and where they need it. And our fulfillment of the one Net strategic framework translates directly into business solutions that offer more opportunity, higher ROI and closer, more productive relationships with you and everyone who matters to your business.

Let’s take a brief tour of one Net to help set the context for our discussion today.

Starting in the center, our Ngage teams employ proven methodologies and expertise, training, and support at all levels of your organization to facilitate the design, development and deployment of secure, scalable business solutions.

Novell exteNd, our integrated development environment for the creation of Web services-based solutions help transform rigid “silo” applications into personalized, standards-based, process-driven secure Web solutions.

Novell Nsure, our secure identity management solutions family, delivers your enterprise resources and business information based on who people are and what they need, wherever they need it.

Novell Nterprise, our cross platform network services suites, add invaluable capabilities to all kinds of mixed networks and diverse infrastructures. Nterprise solutions are the embodiment of this philosophy. We will deliver and support the services on the platforms our customers and the market demand. Today and in the foreseeable future, Linux running on Intel is the platform the market and our customers are demanding.

A Brief introduction to Web Services: what it is, the key technologies involved.

Discuss the need for security and interoperability.

The WS-I organization and the role it is playing in advancing interoperability.

Demo of the WS-I Sample Supply Chain Management example.

Conclude with a look at work in progress and a summary.

Discuss what web services are and differences between previous distributed object technologies such as CORBA and COM/DCOM.

Some Examples:

Weather

Fedex

Amazon

Advantages of Web Services:

Stanndards based

Internet protocols

Interoperability across vendors/platforms/languages.

Disadvantages of Web Services:

Verbose wire protocol

Do not (yet) support all features of remote objects. e.g. Features are a subset of java.rmi.Remote (no remotes, interfaces etc).

Main technologies used by Web Services:

WSDL is a XML based technology that is used to describe a behavior of a web service in a standardized way. It defines the interface that can be used by a Web Serivce consumer to communicate with a Web Serivce provider.

UDDI is a worldwide registry of web services that is used to advertisement and discovery. The WSDL describing the Web Service is typically stored in the UDDI registry.

SOAP provides the encoding standards and wire protcol to carry data or XML documents over standard internet protocols such as HTTP, SMTP, FTP etc.

HTTP is the most commonly used transport protocol. Used everyday for communication between Browsers and Web Servers.

Simple grammar, key notions being elements and attributes.

A Key feature of XML is the ability to represent data or complex documents in a generic way.

XML is used to represent the description of a Web Service.

The Web Service in turn can also support the exchange of complex XML documents used to conduct business (purcase order, manuals, etc.).

Structure of a SOAP message with an example

Describe the following:

The required SOAP Envelope that wraps the complete message

The SOAP Body that containts the remote procedure call or data

The optional SOAP Header bock.

The SOAP-ENV and xmlns namespaces (similar to packages in Java).

RPC/encoded style : method wrapper, encodingStyle attribute

Description of a typical Web Services stack.

Role of compilers provided by Novell WSSDK to start from WSDL or RMI and generate stub/skeleton that enable the user to access a Web Service as a simple Java method.

Description of work done by Stub/Skeleton to and WSSDK runtime to convert data or DOM Element into SOAP, send over HTTP, and convert the response back to Java Objects.

XML is a simple and easy language, but difficult to program with.

Binding to Java Objects simplifies this for the user/developer.

SOAP can represent either synchronous RPC Call or a more asynchrnous message-based document exhange.

Although SOAP messages are fundamentally a one-way transmission from a sender to a receiver, the HTTP proptool provides a neat mapping for a synchrnous request/response model required by RPC.

Any simple datatype or complex data structure can easily be serialized into XML based on encoding rules.

Novell WSSDK supports the following styles of web services

rpc/encoded

doc/literal

rpc/literal

For interoperability it is suggested to use doc/literal or rpc/literal.

Autentication refers to determining the identity of the consumer of the web service.

Integrity refers to the message being delivered without being modified during transit

Confidentiality implies that the message has not been seen intercepted or viewed

There are other factors related to security that we do not consider here

Authorization

Single sign-on

message replay

etc.

as techniques for these have not been well defined for web-services as oppsosed

to Authentication, Integrity, and Confidentiality..

HTTP authentication methods are well defined and used widely.

Since Web Services use HTTP as the transport we can make use of the

authentication techniques.

Another commonly used method for authentication and security is SSL.

Although HTTP is the most commonly used transport, SOAP and web services are protocol-independent. Therefore we should not always rely on transport level security and need to add authentication and security to the SOAP message itself.

Oasis WS-Security defines the concept of a UsernameToken that can be added to the Security information in the SOAP Header.

Authentication only identifies the caller. Authorization methods such as ACL, directlry etc will have to be used to determine if the caller has permissions to access the web service.

As discussed in the last slide, the idea is to incorporate authentication and security in the SOAP message itself, rather than rely on the transport protocol etc.

Inegrity is achieved by using XML digital signatures.

This relies on the use of PKI (Public Key Infrastructure).

PKI is based on a mathematical algorithm that generates encryption and decryption keys in pairs.

When one key is used to encrypt the data the other key can be used to decrypt it.

One key is public and the other is private.

An important part of PKI cryptograph is the generation, distribution, and verification of keys.

Non-repudation and Integrity are achieved by digitally signing a document (SOAP message). The sender uses its private key to sign the data, and the receiver can use the public key to verify the sender and to make sure that the data was not changed.

The XML digital signature specification defines an optional element that allows the inclusion of digital signature with the XML document. For a SOAP message this information is added in the <Signature> element of a SOAP Header.

HTTP Authentication framework

When the user requests a protected page from a HTTP Server, the server responds

with a 401 Unauthorized status code and includes a WWW-Authenticate field in its response. This header field contains at least one authentication challenge.

Now the client must make another request by including an Authentication header field that contains the user's credentials.

The format of the WWW-Authenticate and Authentication header fields depend of the authentication scheme being used.

The server's response contains an authentication challenge with the word “Basic” followed by the realm of the requested page.

WWW-Authenticate: Basic realm=”.....”

The follow up request from the client should contain an Authentication header with the contents “Basic” followed by the base64 encoding of username:password

Authorization: Basic Qxerijxcvk

The server base64 decodes the string to determine the username and password credentials of the user.

When no AUTH_SCHEME is specified, Novell WSSDK defaults to BASIC authentication.

The major drawback of this scheme is that is relatively easy for a listener to eavesdrop and determine the password.

This scheme is also prone to replay attacks, i.e. somebody captures the HTTP request, and can replay it later with the credentials.

This prevent easy decoding of the password and to prevent replay attacks ,

the DIGEST scheme uses a more sophisticated procedure.

The server's response for an authentication challenge also includes a value called a nonce. Each nonce is a unique value and not been previously used.

The response from the client contains the Username, the nonce value received from the server, and a MD5 message digest computed from the username, realm, password, and nonce (see RFC2617 for details). The server does the same computation of the MD5 digest and if the values match it knows that the user has the right credentials.

The server can prevent message replay by accepting a nonce value only once for each authentication request.

Setting the DIGEST_AUTH_SCHEME tells Novell WSSDK to use the DIGEST authentication scheme when responding to a 401 Unautorized status code response.

The NTLM authentication scheme is unique to Microsft IIS servers and uses the Windows Server user account to authenticate a user.

Setting the NTLM_AUTH_SCHEME along with the NTLM_HOST and NTML_DOMAIN will let Novell WSSDK respond appropriately to the server's 401 response.

The properties HTTP_PROXY_NTLM_HOST and HTTP_PROXY_NTLM_DOMAIN can also be set in order to use NTLM proxy authentication.

2003-12-08T12:43:39