A Public Web Services Security Framework Based on Current and Future Usage Scenarios J.Thelin, Chief Architect PJ.Murray, ...
Web Services Usage Scenarios <ul><li>Point-to-point system integration </li></ul><ul><li>Enterprise application integratio...
3 Main Concerns of a Security Framework <ul><li>Authentication – identity </li></ul><ul><ul><li>Who is the caller? </li></...
Web Service Interaction Levels Web Service client Web Service SOAP Stack SOAP Stack HTTP client HTTP listener Application ...
Transport Level Security <ul><li>Uses existing Web tier technology such as HTTP and SSL </li></ul><ul><li>Authentication <...
Message level security <ul><li>Security data built in to the XML message text – usually as additional SOAP header fields <...
Application level security <ul><li>A Web Service application handles its own security scheme – for example, UDDI </li></ul...
Lessons from the First Wave <ul><li>Existing Web tier security infrastructure usually sufficient for internal projects </l...
Recommendations for the future <ul><li>Track usage scenarios in an organization to determine security levels </li></ul><ul...
Conclusions – Key Issues <ul><li>A Web Services security framework must support existing security products </li></ul><ul><...
Resources <ul><li>CapeScience </li></ul><ul><ul><li>Papers, articles, tutorials, and webcasts for Web Services developers ...
Upcoming SlideShare
Loading in …5
×

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

1,374 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,374
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

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

×