Your SlideShare is downloading. ×
A Public Web Services Security Framework Based on Current and Future Usage Scenarios - Summary
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

A Public Web Services Security Framework Based on Current and Future Usage Scenarios - Summary

1,065
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,065
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. A Public Web Services Security Framework Based on Current and Future Usage Scenarios J.Thelin, Chief Architect PJ.Murray, Product Manager Cape Clear Software Inc. Internet Computing 2002 Conference, Las Vegas, June 2002
  • 2. Web Services Usage Scenarios
    • Point-to-point system integration
    • Enterprise application integration
    • Technology integration
    • Business partner collaboration
    • Composite business processes
    • Reducing I.T. lifecycle costs
    • I.T. investment protection
  • 3. 3 Main Concerns of a Security Framework
    • Authentication – identity
      • Who is the caller?
      • How do we prove they are who they say they are?
    • Authorization – access control
      • What is the caller authorized to do?
      • Is the caller permitted by perform the operation it is requesting?
    • Confidentiality – encryption and tamper-proofing
      • How do we prevent snoopers viewing our messages and data?
      • How do we prevent messages being tampered with between sender and receiver?
  • 4. Web Service Interaction Levels Web Service client Web Service SOAP Stack SOAP Stack HTTP client HTTP listener Application level Message level Transport level
  • 5. Transport Level Security
    • Uses existing Web tier technology such as HTTP and SSL
    • Authentication
      • HTTP authentication schemes – Basic or Digest
      • SSL client side certificates
    • Authorization
      • J2EE Servlet declarative security constraints
    • Confidentiality
      • SSL encrypted connections
  • 6. Message level security
    • Security data built in to the XML message text – usually as additional SOAP header fields
    • Authentication
      • SSO (single sign-on) header tokens
      • SAML authentication assertions
    • Authorization
      • SSO session details
      • SAML attribute assertions
    • Confidentiality
      • XML Encryption specification
      • XML Digital Signatures specification
  • 7. Application level security
    • A Web Service application handles its own security scheme – for example, UDDI
    • Authentication
      • App specific authentication messages
      • App specific credential headers in other messages
      • App maintains its own security domain
    • Authorization
      • App performs its own access control checks
    • Confidentially
      • App can apply an encryption scheme to some or all data fields
      • XML Digital Signature specification for tamper detection
  • 8. Lessons from the First Wave
    • Existing Web tier security infrastructure usually sufficient for internal projects
    • Necessary to accommodate third-party security products already in use in the organization
    • End-to-end framework is necessary to avoid security gaps
    • Operational security procedure best practices for Web services have yet to be developed
    • XML security standards have not yet been widely adopted
    • Rival XML security standards are still emerging
    • Lack of experience and training on XML security standards is holding back adoption
  • 9. Recommendations for the future
    • Track usage scenarios in an organization to determine security levels
    • Start with “proof-of-concept” projects to gain experience
    • Integration with Microsoft .NET security schemes will be vital
    • Track emerging XML security specifications
    • Don’t throw away the organization’s existing security infrastructure
    • Plan to implement end-to-end security
  • 10. Conclusions – Key Issues
    • A Web Services security framework must support existing security products
    • Must be an end-to-end framework (not just a “firewall” layer) to avoid any security gaps
    • New XML security standards are not yet proven (so probably contain “holes”)
    • Use existing proven Web tier security infrastructure until XML security standards and infrastructure is validated
  • 11. Resources
    • CapeScience
      • Papers, articles, tutorials, and webcasts for Web Services developers
      • http://www.capescience.com
    • Cape Clear Academic Licenses
      • Free licenses for Cape Clear products to academic users
      • http:// www.capescience.com /academic/