Web Services: The Next Step in Internet Evolution

1
Web ServicesThe Next Step in Internet
Evolution ?

• By
• Arpit Mathur

2
Talk Outline

• State of the internet today
• Web services explained
• Security the Nemesis
• Redesigning existing architectures for web
  services A case study
• The future of web services

3
The Internet Today

• World of custom-solutions
• Entities exchange information

• The Promise
• Tighter Integration between corporations
• Less Redundancy
• Units will exchange Services

4
Introduction to Web Services

• References
• Java Web Services
• David A Chappell Tyler Jewell
• OReilly Publications
• http//www.w3.org
• http//www.UDDI.org

5
Current Situation
SERVICE PROVIDERS
Service A
Service A
Company A
Company B
6
Ideal SolutionThe Web Services Promise
SERVICE PROVIDER
Web Service A
Company A
Company B
7
What are Web Services?

• A set of XML-based standards and programming
  guidelines that allow applications to swap data
  over the Internet
• Integrate inter / intra organization services
  into a cohesive whole by automating the process
  of sharing data across the net between
  heterogeneous systems

8
A Complete Solution
WSP 2
My Data
My Result
WSP 1
WSP 3
9
Scenario
SERVICE PROVIDER
Create Service
Describe Your Service
Publish it to enable discovery
SERVICE CONSUMER
Discover Service
Consume
10
Web Services Diagram
11
An introduction to XML

• XML eXtensible Markup Language
• Markup Language that doesnt lose semantic
  knowledge
• Similar to HTML but HTML only contains
  browser-rendering information
• Standard way of sending data across the internet

12
Example

• HTML page
• lth1gtmyNamelt/h1gt
• lth4gtmy addresslt/h4gt
• XML document
• ltnamegtmyNamelt/namegt
• ltaddressgtmy addresslt/addressgt

13
Step 1
SERVICE PROVIDER
Create Service
Describe Your Service
Publish it to enable discovery
Developer Specific Java, C, .NET
Discover Service
Consume
SERVICE CONSUMER
14
Step 2
SERVICE PROVIDER
Create Service
Publish it to enable discovery
Describe Your Service
Any Language
CONSISTENT DESCRIPTION LANGUAGE
Discover Service
Consume
SERVICE CONSUMER
15
WSDL

• The Web Services Description Language (WSDL) is
  an XML-based language used to describe the
  services a business offers and to provide a way
  for individuals and other businesses to access
  those services electronically
• It specifies the location of the service and the
  operations (or methods) the service exposes.

16
WSDL Element Definitions

• ltportTypegt
• Defines the operations performed by the web
  service
• ltoperationgt
• Defines each operation that the port exposes
• ltmessagegt
• Defines data elements of the web services
• lttypesgt
• The data types used by the web service
• ltbindinggt
• The communication protocols used by the web
  service

17
WSDL Example

• ltmessage name"getTermRequest"gt
• ltpart name"term" type"xsstring"/gt
• lt/messagegt
• ltmessage name"getTermResponse"gt
• ltpart name"value" type"xsstring"/gt
• lt/messagegt
• ltportType name"glossaryTerms"gt
• ltoperation name"getTerm"gt
• ltinput message"getTermRequest"/gt
• ltoutput message"getTermResponse"/gt
• lt/operationgt
• lt/portTypegt

18
WSDL Example (cont)

• ltbinding type"glossaryTerms" name"b1"gt
• ltsoapbinding style"document"
  transport"http//schemas.xmlsoap.org/soap/http"
  /gt ltoperationgt
• ltsoapoperation soapAction"http//example.com
  /getTerm"/gt
• ltinputgt
• ltsoapbody use"literal"/gt
• lt/inputgt
• ltoutputgt
• ltsoapbody use"literal"/gt
• lt/outputgt
• lt/operationgt
• lt/bindinggt

19
Step 3
SERVICE PROVIDER
Create Service
Describe Your Service
Publish it to enable discovery
Any Language
WSDL
CONSISTENT DISCOVERY LANGUAGE
Discover Service
Consume
SERVICE CONSUMER
20
UDDI

• UDDI (Universal Description, Discovery and
  Integration ) is an XML-based registry for
  businesses worldwide to list themselves on the
  Internet
• UDDI is a directory of web service interfaces
  described by WSDL
• Business can register three types of information
  into the registry
• White pages Basic business information
• Yellow pages Categorized web service lists
• Green pages Technical information describing
  the behaviors and supported functions

21
UDDI diagram
22
Step 3
SERVICE PROVIDER
Create Service
Describe Your Service
Publish it to enable discovery
Any Language
WSDL
UDDI
Semantically meaningful exchange that isnt
blocked by firewalls
Discover Service
Consume
SERVICE CONSUMER
23
Introduction to SOAP

• SOAP Simple Object Access Protocol
• Standard way of transmitting XML over HTTP (
  SMTP, FTP) between heterogeneous
  clients/servers.
• Package XML in a
• ltSOAP-ENVEnvelopegt pair, with a
• ltSOAP-ENVHeadergt and a
• ltSOAP-ENVBodygt tag pair
• Missing security, reliability, routing,
  interaction rules.

24
Optional SOAP tags

• ltSOAPHeadergt
• The optional SOAP Header element contains
  application
• specific information
• Ex MustUnderstand
• ltSOAPfaultgt
• ltfaultcodegt
• A code for identifying the fault
• ltfaultstringgt
• A human readable explanation of the fault
• ltfaultactorgt
• Information about who caused the fault to happen
• ltdetailgt
• Holds application specific error information
  related to the Body
• element

25
Typical Soap Request

• POST /InStock HTTP/1.1
• Host www.stock.org Content-Type
  application/soapxml
• charsetutf-8 Content-Length nnn
• lt?xml version"1.0"?gt
• ltsoapEnvelope xmlnssoap"http//www.w3.org/2001
  /12/soap-envelope" soapencodingStyle"http//www.
  w3.org/2001/12/soap-encoding"gt
• ltsoapBody xmlnsm" http//example.com/getTerm
  "gt   
• ltmgetTermgt
• ltminputgtIBMlt/minputgt     
• lt/mgetTermgt
• lt/soapBodygt
• lt/soapEnvelopegt

26
Typical Soap Response

• HTTP/1.1 200 OK
• Content-Type application/soap
• charsetutf-8 Content-Length nnn
• lt?xml version"1.0"?gt
• ltsoapEnvelope xmlnssoap"http//www.w3.org/2001/
  12/soap-envelope" soapencodingStyle"http//www.w
  3.org/2001/12/soap-encoding"gt
• ltsoapBody xmlnsm" http//example.com/getTerm
  "gt ltmgetTermgt
• ltmoutputgt34.5lt/moutputgt
• lt/mgetTermgt
• lt/soapBodygt
• lt/soapEnvelopegt

27
The Complete Picture
SERVICE PROVIDER
Create Service
Describe Your Service
Publish it to enable discovery
Any Language
WSDL
UDDI
SOAP
Discover Service
Consume
SERVICE CONSUMER
28
Web services in action
29
WEB SERVICES ARE TAKING OVER
30
or are they ?

• In a survey in 2003,
• 54 participants said they intended to use web
  services to integrate systems
• 5 had completed a project by the end of 2002

Image source news.com.com
31
Security Issues in Web Services

• References
• XML, Web Services and XML
• Win Terese
• SAML and Federated Authentication Whitepaper
• SIGABA (www.sigaba.com)
• Web Services Security Whitepaper
• RSA Security (www.rsasecurity.com)

32
The Problem

• SOAP is designed to go through firewalls since it
  is piggybacked over HTTP.
• Check every incoming message ???
• How do you identify malicious incoming requests ?
• Need to address
• Confidentiality
• Authentication,
• Integrity,
• Non-repudiation,
• Authorization

33
Options

• Communicate over the internet using SSL
• XML Encryption recommendation using conventional
  and public key cryptography
• XML digital signatures recommendation
• Authorization use Security Assertion Markup
  Language

34
Problems with domain-specific authentication

• Conventional Public Key Infrastructure Coupled
  Authentication sources giving authentication keys
  
• ? not workable
• Organizations are dynamic Each subunit has its
  own authentication scheme
• ( Ex passwords / retinal scans etc)
• Need Authentication system that works with
  authentication from various sources

35
The idea of Federated Authentication

• Each organization authenticate its user
  individually
• No need for a central repository for verification
• Enables global single sign on access
• Seamless integration of legacy into future
  security systems

36
SAML Introduction

• SAML Security Assertion Markup Language
• XML based framework that enables web services to
  exchange information on authentication and
  authorization in the form of trusted statements
  called security assertions
• An assertion is a digitally signed statement
  about a subject issued by an authority

37
Common Assertion Information

• Issuer and issuance timestamp
• Assertion ID
• Subject
• Name Security Domain
• Optional subject confirmation (public key)
• Conditions for assertion validity
• Advice on how the assertion was made
• All Assertions are digitally signed

38
SAML Assertions

• Authentication Assertions
• Issued by an authentication service
• Declare the user S was authenticated by means M
  at time T
• 2. Attribute Assertions
• Declare that the user S is associated with
  attributes A,B,etc and has values a,b,etc

39
SAML Assertions
An Authentication Service Brings together these
assertions and Authorization policies and
generates Authorization Assertions that define
which resources the web service is authorized to
access

• Authorization Assertion
• An authorization service decides whether to grant
  the request by subject S for action A on resource
  R given evidence E

40
SAML Authentication Assertion

• ltsamlAssertation
• MajorVersion1 MinorVersion0
• AssertionID186CB370-5C81-4716-8F65-F0B4FC4B4A0B
  
• Issuerhttp//www.example.com/
• IssueInstant2001-05-31T132000-0500gt
• ltsamlConditions
• NotBefore2001-05-31T132000-0500
• NotAfter2001-05-31T132500-0500/gt
• ltsamlAuthenticationStatement
• AuthenticationMethodpassword
• AuthenticationInstant2001-05-31T132100-0500gt
  
• ltsamlSubjectgt
• ltsamlNameIdentifiergt
• ltSecurityDomaingthttp//www.example.com/lt/Securit
  yDomaingt
• ltNamegtcnAlice,coexample,ousaleslt/Namegt

41
SAML Response Example

• ltsamlpResponse
• MajorVersion1 MinorVersion0
• RequestID186CD370-181-4236-8F65-F0B4FC4B4A0B
• InResponseToEE52CAF4-3452-4ebe-84D3-4D372C892A5D
  
• StatusCodeSuccessgt
• ltsamlAssertion
• MajorVersion1 MinorVersion0
• AssertionID186CD370-5C81-4716-8F65-F0B4FC4B4A0B
  
• Issuerhttp//www.example.com/gt
• ltsamlConditions
• NotBefore2001-05-31T132000-0500
• NotAfter2001-05-31T132500-0500/gt
• ltsamlAuthorizationDecisionStatement/gt
• lt/samlAssertiongt
• lt/samlpRequestgt

42
SOAP Profile of SAML

• SOAP Message
• SOAP Header
• SAML Assertion
• About SOAP Body
• SOAP Body
• SOAP Message
• SOAP Header
• SOAP Body
• SAML Request
• or Response
• SOAP Profile of SAML
• Contrasted with
• SOAP Binding of SAML

43
A Simulated Secure Web Service Access ExampleA
Pseudo Mortgage Application
44
Step 1/2

• Applicant fills form and clicks submit
• WS tries to authenticate itself and presents a
  digital certificate issued by a third party.The
  XKMS (XML Key Management System) server retrieves
  the mortgage companys digital certificate

45
Step 3

• Mortgage WS queries UDDI registry asking to be
  connected to any of the three nationally known
  credit rating firms. UDDI returns the name of one
  of the firms and indicates the request must be
  digitally signed

46
Step 4

• 4) Mortgage WS submits its signed request. The
  Credit service accesses the XKMS server to
  validate the WSs PKI credentials.
• XKMS validates the credentials
• Credit bureau responds with an attribute
  assertion stating the requestors credit rating

47
Step 5

• 5. The WS now verifies the property details by
  accessing the government database.
• The database service verifies the WS has
  contracted to access the service

48
Step 6

• 6)Mortgage WS submits a property query with the
  header containing the authorization assertion
  issued
• The DB response is sent to the WS

49
Step 7

• 7) Now the WS issues a signed contract approving
  the loan

50
Adopting the Web Services Framework

• Migration to Web Services Oriented Architecture
• Jia Zhang et. Al
• How will Web Services Evolve
• George Eby Mathew and Sumantha Deb
• SETLabs

51
The Situation

• ePayment Online Synchronous / Asynchronous
  payment processing application handling credit
  card payment,e-Check payment, bill presentation,
  payment history presentation etc
• Can be hosted on an enterprise server or in
  Application Service Provider (ASP) style with the
  application running on a central server for
  multiple enterprises.
• ASP style preferred by companies since no
  resource consumption or maintenance hassles

52
Issues with conventional deployment

• Username Password recorded on the companys site
  has to be sent over the internet.
• User has to go through the e-Payment web pages to
  use the application
• Need a pass-through authentication which allows
  users logged in at site A to access resources on
  machines they have no accounts on ? the key idea
  of federated trust

53
Service requests in e-Payment Web Service

• URL string
• https//epayment.com/institution/payer.do?userId9
  99999p
• aymentMethodachtimestamp949924800hashb14ac9
  d2960e53dbb2f061b236d7a0a

54
Increase Flexibility and UsabilityDeploy as a
Web Service

• Features
• Every deployed e-Payment application is wrapped
  with a PTA service wrapper
• All the wrappers exhibit the same web service
  registry and invocation to the SOAP/UDDI bus
• Application administration web service allows
  users to adapt the PTA as per their need

55
So a perfect solution?..No !

• Limited benefit
• Each PTA still implements proprietary versions of
  common services
• PTAs are built on top of individual e-Payment
  System ? Limited reusability
• No central management of services such as
  monitoring and load balancing
• ? Need to rethink the overall application
  architecture

56
Application redesigned

• Each monolithic ePayment System is dissolved into
  a self contained service
• Only 1 PTA service
• Separate Administration / Management Web Service

57
Case Study Results

• Migration to WS standard enabled the system to be
  considered a reusable asset
• Lower level developers can be made to work on
  individual components
• WS architecture facilitates easier testing
• Easier maintainability
• Better scalability and higher ROI

58
How will Web Services Evolve
59
The Timeline of the future

• Web Services will see a disconnect between
  adoption and pace of maturity the technology
• Initially web services will be designed for
  invocation within the enterprise itself
• Companies with huge legacy data will be among the
  early adopters of the technology
• All ERP / SCM / CRM vendors have announced
  support for
• SOAP

60
Timeline(2)

• 4. Web Services may not change fundamental
  business models They will be more a mechanism
  for reduced costs and easier integration
• 5. Web Services will lower the cost of
  integration in B2B scenarios

61
Three Phases in WS adoption

• EXPERIMENTAL PHASE
• Companies will experiment with security and QOS
  issues within the corporate firewall.
• Transaction Basic Information

• BUILD PHASE
• Available Mature standards
• Web Services will add to, not replace, Middleware
  like Enterprise Application Integration (EAI)
  Systems

62

• 3) Leverage Phase
• Early Web Service Adopters will see a dramatic
  ROI
• Dynamic discovery based applications will emerge
• Stronger models for enterprise security
• Web Service architecture as commonplace as
  client-server architecture

63
parting thought

• Continental Airlines Worked on data in legacy
  flight operation management systems wrapped it
  with WS communication standards creating a
  service accessible from PDAs and cell phones
• General Motors initiated a web services project
  last year to set up a Build-to-Order system for
  cars connecting with 8000 of its dealers over the
  internet

64
References

• Java Web Services
• David A Chappell Tyler Jewell
• OReilly Publications
• http//www.w3.org
• http//www.UDDI.org
• XML, Web Services and XML
• Win Terese
• SAML and Federated Authentication Whitepaper
• SIGABA (www.sigaba.com)
• Web Services Security Whitepaper
• RSA Security (www.rsasecurity.com)
• Migration to Web Services Oriented Architecture
• Jia Zhang et. Al
• How will Web Services Evolve
• George Eby Mathew and Sumantha Deb
• SETLabs
• xmethods.net

65
Thank You