Wsdl 2.0 message exchange and WS Security

WSDL 2.0 MESSAGE
EXCHANGE AND WS-
SECURITY
HILAL TAHA (267365)
GAGANA KAVERIAPPA (267359)
JAYASURYA ARASUR SUBRAMANIAN (267412)
MOISES ROMERO ROMO (266567)
1
SERVICE ORIENTED SOFTWARE ENGINEERING 2019-2020

WSDL
▪ The Web Services Description
Language (WSDL) is an XML-
based interface description
language that is used for describing
the functionality offered by a web
service
2
Fig: WSDL Specificationhttps://www.w3.org/TR/wsdl.html

EXISTING STANDARDS
▪ WSDL 1.0 SEP 2000
▪ WSDL 1.1 MAR 2001
▪ WSDL 1.2 JUN 2003
▪ WSDL 2.0 JUN 2007
3SERVICE ORIENTED SOFTWARE ENGINEERING 2019-2020

WSDL 2.0
▪ The W3C's Web Services
Description Working Group, part of
the Web Services Activity, has
defined a language for describing
web services and the possible ways
to interact with them.
▪ The WG published its WSDL 2.0
working drafts on 26 March 2004.
This is a significant milestone in
the progress of WSDL
4
Fig: Difference between WSDL 1.1 and 2.0
▪ https://www.w3.org/TR/wsdl20-adjuncts/

WHY WSDL 2.0…?
▪ Found to reduce interoperability
issues in WSDL.
▪ Permit fault message to declare
with in interface element.
▪ Support additional message patterns
(ex: out-multi in).
▪ Gives better fault handling notation.
▪ Support interface inheritance.

Template for Message Exchange
Patterns
▪ New message exchange patterns may be defined by any
organization able and willing to do so. It is recommended
that the patterns use the general template provided in Pattern
Name, after examination of existing predefined patterns.
https://www.w3.org/TR/wsdl20-adjuncts/

Pattern Name
▪ This pattern consists of [number] message[s, in order] as follows:
[enumeration, specifying, for each message] And [optional] message:
1. indicated by an Interface Message Reference component whose
{message label} is "[label]" and {direction} is "[direction]"
2. [received from|sent to] ['some' if first mention] node [node identifier]

The Interface Message Reference
Component
● {message label} REQUIRED
● {direction} REQUIRED
● {message content model} REQUIRED.
● {element declaration} OPTIONAL
● {parent} REQUIRED
https://www.w3.org/TR/2007/REC-wsdl20-20070626/#component-
InterfaceMessageReference

FAULT PROPAGATION RULES
▪ Fault Replaces Message propagation rule
▪ Message Triggers Fault propagation rule
▪ No Faults propagation rule
https://www.w3.org/TR/wsdl20-adjuncts/

MESSAGE EXCHANGE
PATTERNS
▪ IN-ONLY
▪ ROBUST-IN-ONLY
▪ IN-OUT
▪ IN-OPTIONAL-OUT
▪ OUT-ONLY
▪ ROBUST-OUT-ONLY
▪ OUT-IN
▪ OUT-OPTIONAL-IN
10Fig: WSDL 2.0 Message exchange patternsSERVICE ORIENTED SOFTWARE ENGINEERING 2019-2020

IN-ONLY MESSAGE
EXCHANGE PATTERN
▪ A request message is sent to the web service
provider, and a response message is returned to
the web service requester. The response message
could be a normal SOAP message or a SOAP
fault.
11
CLIENT SERVICE
Fig: IN – ONLY (no fault)

ROBUST IN-ONLY MESSAGE
EXCHANGE PATTERN
provider, and a response message is only returned
to the web service requester if an error occurs. If
there is an error, a SOAP fault message is sent to
the requester.
12
CLIENT SERVICE
Fig: Robust IN-ONLY (Message Triggers Fault)

IN-OUT MESSAGE
EXCHANGE PATTERN
provider, and a response message is returned to
the web service requester. The response message
could be a normal SOAP message or a SOAP
fault.
13
CLIENT SERVICE
Fig: IN-OUT (Fault Replaces Message)

IN-OPTIONAL OUT MESSAGE
EXCHANGE PATTERN
▪ A request message is sent to the
web service provider, and a
response message is optionally
returned to the web service
requester. If there is a response, it
could be either a normal SOAP
message or a SOAP fault
14
CLIENT SERVICE
Fig: IN-Optional OUT (Message Triggers Fault)

OUT-ONLY MESSAGE
EXCHANGE PATTERN
▪ The service provider sends the
message. The message can be
normal SOAP message or an fault
message.
15
CLIENT SERVICE
Fig: OUT-ONLY (No Fault)

ROBUST OUT-ONLY MESSAGE
EXCHANGE PATTERN
▪ The Service provider sends the
message and in case of a fault at the
partner service it receives a fault
message.
16
CLIENT SERVICE
Fig: Robust OUT-ONLY (Message Triggers Fault)

OUT-IN MESSAGE
EXCHANGE PATTERN
▪ The Service provider sends the
message and receives a response
message. The message can be a
simple SOAP message
17
CLIENT SERVICE
Fig: OUT-IN (Fault Replaces Message)

OUT-OPTIONAL-IN
MESSAGE EXCHANGE
PATTERN
▪ The Service provider sends a
message and optionally receives a
response message. The message
can be a simple SOAP message.
18
CLIENT SERVICE
Fig: OUT-OPTIONAL-IN (Message Triggers Fault)

Programming part

Apache CXF

Axis history
21
Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol")
submission to W3C.
Version history:
Axis 1.1
Axis 1.2
(October 5, 2005): Axis 1.3
(April 22, 2006): Axis 1.4

Axis2
22
▪ Apache Axis2™ is a Web Services / SOAP / WSDL engine
▪ Apache Axis2 not only supports SOAP 1.1 and SOAP 1.2, but it also has
integrated support for the widely popular REST style of Web service.
▪ Apache Axis2 is more efficient, more modular and more XML-oriented than
the older version. It is carefully designed to support the easy addition of
plug-in "modules" that extend their functionality for features such as security
and reliability.
▪ The Modules currently available or under development include:
● WS-Security - Supported by Apache Rampart
● WS-Addressing -Module included as part of Axis2 core

Axis2

Last attempt

WS SECURITY ROADMAP
▪ WS-SECURITY
▪ SECURITY THREATS AND COUNTERMEASURES
▪ STANDARD HTTPS COMMUNICATION
▪ COMMUNICATION WITH MULTIPLE SERVERS
▪ MULTIPLE SERVER ENVIRONMENT
▪ WEB SERVICE SECURITY STANDARDS
▪ FLOW DIAGRAM OF SECURITY MODEL IN WS-SECURITY
▪ STEPS IN THE WORKFLOW
▪ WSDL SNIPPET
▪ WEB SERVICE SECURITY BEST PRACTICES
▪ SUMMARY

WS SECURITY
▪ A standard that addresses security
when data is exchanged as a part of
a Web service.
▪ A key feature in SOAP.
▪ Security is an important feature in
any web application.
▪ We should always develop web-
based applications with security in
mind.

SECURITY THREATS AND
COUNTERMEASURES
▪ A simple scenario of a web
application.
▪ See how it works in terms of
Security.

SECURITY THREATS AND
COUNTERMEASURE
▪ One of the security measures for the
HTTP is the HTTPS protocol.
▪ HTTPS makes use of the Secure
Sockets layer for secure
communication.
▪ Both the client and the server will
have a digital certificate to identify
themselves.

STANDARD HTTPS
COMUNICATION
▪ Steps:
▪ Client sends a request to the server
via the client certificate.
▪ The server then authenticates itself
to the client by sending its
certificate.
▪ All comunication thereafter
between the client and server is
encrypted.
But the above type of security will not
work in all situations. 33

COMMUNICATION WITH
MULTIPLE SERVERS
▪ Example shows a client talking to both a
database and a web server at a time.
▪ Not all information can pass through the
https protocol.
▪ SOAP comes in action to overcome such
obstacles by having the WS Security
specification in place.
▪ All security related data is defined in the
SOAP header element.
▪ 1.If the the message is signed…
▪ 2.If any element is encrypted 34

MULTIPLE SERVER
ENVIRONMENT
▪ The previous techniques helps in the
following way.
▪ SOAP body encrypted.
▪ Message is passed to the database
server in an HTTP request.
▪ Appropriated response to the client.

WEB SERVICE SECURITY
STANDARDS
▪ The credentials in the SOAP header
is managed in two ways.
▪ UsernameToken.
▪ BinaryToken via the
BinarySecurityToken

WEB SERVICE SECURITY
STANDARDS
▪ It is a Message Level Security
▪ Addresses three main security issues :
▪ Authentication (Identity)
▪ Confidentiality (Encryption and Decryption)
▪ Integrity (XML Signature)

FLOW DIAGRAM OF SECURITY MODEL IN
WS SECURITY

STEPS IN THE WORKFLOW
1. A request can be sent from the WS
client to Security token Service.
2. The security token is passed to the
WS client.
3. WS client called the web service.
4. Web service understands the SOAP
message with the authentication
token.

WSDL SNIPPET

WS-SECURITY
AUTHENTICATION
WS Security Standard offers three methods of authentication :
▪ UsernameToken Profile
▪ X 508 Certificates Token Profile
▪ SAML Token Profile

UsernameToken Profile
▪ UsernameToken represents a username and password pair in WS-Security
Standard.
▪ It is included in the SOAP header of the web service request.
▪ Since the SOAP message is sent as is, the Username and Password are in
plain text.
▪ In production environment, it should be used in association with
transportation layer encryption such as SSL.
▪ CXF supports the use of WS-Security Policy or Interceptors for adding the
UsernameToken security header.

JAX-WS CLIENT BASIC
AUTHENTICATION EXAMPLE
▪ In this Example :
▪ Creating a simple JAX-WS web service and client.
▪ Secure the web service with the UsernameToken profile - Using a Java
security callback - Configured with an Apache CXF Interceptor.
▪ Configure the same components on the Client side.

TOOLS USED IN THIS EXAMPLE
▪ Eclipse IDE for Enterprise Java Developers
▪ Maven
▪ Tomcat v8.5

Create the Web Service Provider

Create the Web Service Provider
46
Enter the Group ID and Artifact ID

Add Maven Plugins in pom.xml
47
▪ The Maven plugin compiler will
compile the source code
▪ The Maven war plugin will
package the application in a
deployable war file

Add Dependencies
48
▪ Spring dependencies are required
since we will be using a Spring
configuration file for configuring
the web service.

Create the Web Service
49

Create the Spring Configuration
file
50

Create the Spring Configuration
file
▪ The <jaxws:server> element configures a JAX-WS service provider.
▪ The <jaxws:server> element’s address attribute specifies the web service
HTTP endpoint, for example, /hello.
▪ The <jaxws:serviceBean> element specifies the Java class implementing the
web service.
51

Configure the cxf-servlet in
web.xml
▪ The CXFServlet searches for the cxf-servlet.xml by default and exposes all
the endpoints configured in that file.
▪ Set load-on-startup to any positive number so that CXFServlet immediately
loads all the web services endpoints on server startup.
▪ The recommended url pattern for web services is /services/*. 52

Create the Web Service Client
54

Securing the Web Service
▪ Adding UsernameToken profile authentication to our web service
▪ Adding authentication does not alter our existing web service business logic
code
▪ Add the following Maven dependency

Creta the UserToken Password
Callback Handler

Add the CXF Security Interceptor
57

Run the Web Service Client
We will get a SOAP Fault

Update the Client
Add Maven Dependencies

Create the UserToken Password
Callback Handler
We are hard-coding the username and password but typically these values are read from an
external source

Update the Client Code

Run the Client

WEB SERVICE SECURITY BEST
PRACTICES
▪ Auditing and Log management.
▪ Flow of calls to the web service.
▪ Sensitive information.
▪ Track Business Operations.
▪ Proper Authentication.

SUMMARY
▪ Additional layer of security.
▪ Username/Password or Binary
certificates.
▪ SOAP Header element.

REFERENCES
▪ W3C Recommendation https://www.w3.org/TR/wsdl20-adjuncts/
▪ IBM knowledge center
https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.1.0/com.ibm.c
ics.ts.webservices.doc/concepts/dfhws_wsdl_mep.html
▪ WS-Security
https://www.guru99.com/security-web-services.html
▪ http://axis.apache.org/axis/
▪ http://axis.apache.org/axis2/java/core/

Wsdl 2.0 message exchange and WS Security

Recommended

Recommended

More Related Content

Similar to Wsdl 2.0 message exchange and WS Security

Similar to Wsdl 2.0 message exchange and WS Security (20)

Recently uploaded

Recently uploaded (20)

Wsdl 2.0 message exchange and WS Security