The Secured Enterprise: Leverage OpenID with Web Services

7,722 views
5,946 views

Published on

SOA security needs to be by design, not as an afterthought. This session will demonstrate implementing Message Interceptor Gateway security pattern with WSO2 ESB, WSO2 WSAS and WSO2 Identity Server – together with the OpenID/Information Cards integration pattern at the front end. The Message Interceptor Gateway pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. Further, this session explores adding authentication and fine grained authorization for web services.

Published in: Technology

The Secured Enterprise: Leverage OpenID with Web Services

  1. OSCON July 20 – 24 , 2009 San Jose, California . . The Secured Enterprise: Leverage OpenID with Web Services Prabath Siriwardena Technical Lead & Product Manager WSO2
  2. WSO2 is an innovative Open Source technology company devoted to building Web services middleware for your SOA. Offering leading products, support and other services, WSO2 was founded in August 2005. It is a global corporation with offices located in USA, UK and Sri Lanka.
  3. 40,000,000 credit card numbers stolen
  4. Security needs to be by design NOT an after thought
  5. What do we need to secure… ROUND TABLE DISCUSSION
  6. We have a bunch of services already developed and some under development…. ROUND TABLE DISCUSSION
  7. Yes…. we need to make sure all the data transferred are secured…. ROUND TABLE DISCUSSION
  8. How about securing data transfer between service and the client through HTTPS…. ROUND TABLE DISCUSSION
  9. HTTPS is not bad.. But still it has certain limitations… ROUND TABLE DISCUSSION
  10. Transport level encryption NOTES…… HTTPS Point to point Entire message needs to be encrypted Adds less weight on message payload Applies only to HTTP
  11. ROUND TABLE DISCUSSION How about message level security?
  12. End to End NOTES…… MESSAGE LEVEL SECURITY Parts of the message can be encrypted Adds more weight on message payload Transport Independent
  13. Yes – let’s finalize on Message level security…. ROUND TABLE DISCUSSION
  14. How can we use Message Level Security to protect our services… ROUND TABLE DISCUSSION
  15. Confidentiality NOTES…… C-I-A Integrity Authentication
  16. The assurance that a message has NOTES…… CONFIDENTIALITY not been read by anyone other than the intended reader
  17. The assurance that data is complete and accurate NOTES…… INTEGRITY
  18. The verification of a claimed NOTES…… AUTHENTICATION identity
  19. Can we make sure we interoperate with the rest… ROUND TABLE DISCUSSION
  20. Yes… we need not to re-implement the wheel… what is the standard to achieve C-I-A with message ROUND TABLE DISCUSSION level security…?
  21. Defines how to achieve confidentiality, integrity and NOTES…… WS-SECURITY authentication with SOAP messages Does not define a new security technology only focuses on applying existing security technologies to SOAP messages
  22. With UserNameToken defined in WS- Security enables us to authenticate users with username/password… ROUND TABLE DISCUSSION
  23. NOTES…… USERNAMETOKEN <wsse:UsernameToken wsu:Id="Example-1"> <wsse:Username> ... </wsse:Username> <wsse:Password Type="..."> ... </wsse:Password> <wsse:Nonce EncodingType="..."> ... </wsse:Nonce> <wsu:Created> ... </wsu:Created> </wsse:UsernameToken>
  24. WS-Security brings XML Encryption to enable confidentiality in SOAP Messages…. ROUND TABLE DISCUSSION
  25. Shared Key NOTES…… ENCRYPTION Key Wrapping
  26. A shared key for both encryption NOTES…… SHARED KEY and decryption Can operate on large plain text messages Uses public key encryption to manage shared key distribution securely Fast
  27. Both the client & the service NOTES…… KEY WRAPPING need not to have a certificate A shared key is derived through the service’s certificate Further communication being encrypted with the derived shared key
  28. ROUND TABLE DISCUSSION Integrity comes through the XML Signature….
  29. Integrity NOTES…… SIGNATURE Non repudiation
  30. WS - Security NOTES…… XML Username X.509 Token XML Signature Encryption Token Profile Profile
  31. Okay… now all our services are secured with ws- security… What is next? ROUND TABLE DISCUSSION
  32. We need to see who should be given access to our services…. ROUND TABLE DISCUSSION
  33. Definitely all the internal users… ROUND TABLE DISCUSSION
  34. …also some of our partner companies…. ROUND TABLE DISCUSSION
  35. Okay… we can ROUND TABLE DISCUSSION easily authenticate internal users with UserNameToken - since we have their credentials internally….
  36. But we don’t maintain credentials of external users… coming from our partner ROUND TABLE DISCUSSION companies….
  37. ROUND TABLE DISCUSSION We need not to maintain external user credentials… we only need to trust our partners….
  38. ROUND TABLE DISCUSSION …and that is what WS-Trust does….
  39. NOTES…… WS-TRUST
  40. We need not to authenticate NOTES…… TRUSTING PARTENERS individual external users We only TRUST external partners All the requests coming through external users need to be signed by the corresponding partner companies Only the requests signed by TRUSTED partners will let in
  41. …also our users need access to external systems.. Out of our domain…. ROUND TABLE DISCUSSION
  42. That is exactly the other side of what we just discussed.. We need to maintain an internal STS ROUND TABLE DISCUSSION
  43. All the requests going out side from internal users need to have a security token issued by the internal STS NOTES…… STS Internal users should authenticate them selves with the internal STS – prior to obtaining a security token External services need to trust our STS
  44. WS - Trust NOTES…… WS - Security Username X.509 XML XML Token Token Signature Encryption Profile Profile
  45. Now… the question is how are we going to communicate our security requirements to ROUND TABLE DISCUSSION the rest…
  46. Let’s first list the security requirements….. ROUND TABLE DISCUSSION
  47. Internal users should authenticate with SECURITY REQUIREMENTS user name / password when accessing services directly
  48. External users should present a security SECURITY REQUIREMENTS token from a trusted STS
  49. Email address should be present in the SECURITY REQUIREMENTS security token comes with the external users.
  50. Only some parts of the message needs to be SECURITY REQUIREMENTS encrypted.
  51. Encryption algorithm should be AES. SECURITY REQUIREMENTS
  52. Encryption key size needs to be 256. SECURITY REQUIREMENTS
  53. All the parts in the <Body> must be signed SECURITY REQUIREMENTS
  54. We need a way to express all these in a ROUND TABLE DISCUSSION standard way….
  55. Ws-security policy exactly addresses that… ROUND TABLE DISCUSSION
  56. Used to express security requirements of NOTES…… WS-SECURITY POLICY a Web service according to, What needs to be protected… What tokens to use… Algorithms, reference types, etc…. Security policies can be defined at the binding level / operation level
  57. WS - Trust WS- SecurityPo NOTES…… licy WS - Security Username X.509 XML XML WS-Policy Token Token Signature Encryption Profile Profile
  58. Everything looks good…. Is there a way we could make sure we ROUND TABLE DISCUSSION strictly follow the security polices defined…
  59. ROUND TABLE DISCUSSION Okay – that means we need to validate each and every service developed…
  60. Yes – validation needs to happen at two stages… ROUND TABLE DISCUSSION
  61. Design time validations will make sure we adhere to proper standards and ROUND TABLE DISCUSSION polices at the time we develop …
  62. Runtime validations will make sure we evaluate all the requests coming in ROUND TABLE DISCUSSION against the defined security policies….
  63. Design time governance NOTES…… SOA GOVERNANCE Runtime time governance
  64. NOTES…… DESIGN TIME GOVERNANCE
  65. NOTES…… DESIGN TIME GOVERNANCE
  66. NOTES…… DESIGN TIME GOVERNANCE
  67. NOTES…… DESIGN TIME GOVERNANCE MONITORING
  68. ROUND TABLE DISCUSSION Yet… we haven’t figure out how to enforce policies on users – or the requests coming through to our services…
  69. Yes… we need to make sure all the requests comply with the defined security polices…. ROUND TABLE DISCUSSION
  70. NOTES…… MESSAGE INTERCEPTOR GATEWAY PATTERN
  71. Provides a single entry point and allows centralization of security NOTES…… MESSAGE INTERCEPTOR enforcement for incoming and outgoing messages. GATEWAY PATTERN Helps to apply transport-level and message-level security mechanisms required for securely communicating with a Web services endpoint.
  72. NOTES…… MIG - IMPLEMENTATION All the services can be deployed inside WSO2 Web Services Application Server [WSAS] – not publicly accessible An open source web services engine powered by Apache Axis2
  73. NOTES…… MIG - IMPLEMENTATION
  74. NOTES…… MIG - IMPLEMENTATION A Service B Service C Service
  75. NOTES…… MIG - IMPLEMENTATION A Service B Service C Service
  76. NOTES…… MIG - IMPLEMENTATION Authentication Module Authorization Module [PEP] LDAP Service Service Service A B C
  77. NOTES…… WSO2 ESB – SECURING PROXY SERVICES
  78. NOTES…… WSO2 ESB – SECURING PROXY SERVICES
  79. NOTES…… WSO2 ESB – SECURING PROXY SERVICES
  80. NOTES…… MIG - IMPLEMENTATION Authentication Module Authorization Module [PEP] LDAP PAP Service Service Service STS A B C PDP
  81. NOTES…… WSO2 IDENTITY SERVER Claim-based security token service - mapping user attributes to defined claims, which can be used to enable identity federation with claim aware web services. XACML Policy Administration Point & Policy Decision Point
  82. NOTES…… WSO2 IDENTITY SERVER - STS
  83. NOTES…… WSO2 IDENTITY SERVER - STS
  84. NOTES…… WSO2 IDENTITY SERVER – PAP/PDP
  85. NOTES…… WSO2 IDENTITY SERVER – PAP/PDP
  86. NOTES…… WSO2 IDENTITY SERVER PAP PDP STS
  87. WS-Security / WS-Trust / WS-Security Policy NOTES…… SUMMARY Message Interceptor Gateway Pattern WSO2 Governance Registry / WSO2 WSAS / WSO2 ESB / WSO2 Identity Server
  88. We have secured access to all our backend services… ROUND TABLE DISCUSSION
  89. Let’s think of securing the front end…. ROUND TABLE DISCUSSION
  90. ROUND TABLE DISCUSSION Yes… our backend services can be accessed through either with a direct client or with our web portal….
  91. Also we already have different web applications managed internally… ROUND TABLE DISCUSSION
  92. And it’s hard to have different credentials to each web application…. ROUND TABLE DISCUSSION
  93. Let’s redesign authentication for all our web applications…. ROUND TABLE DISCUSSION
  94. ROUND TABLE DISCUSSION One more thing… we also need to give access to external users to the web portal as well…
  95. Too many passwords NOTES…… PROBLEMS TO BE Single Sign On ADDRESSED Giving access to external domain users
  96. Decentralized Single Sign On NOTES…… OPENID Single User Profile Identity Federation
  97. NOTES…… OPENID LOGIN FOR WEB PORTAL BROWSER OP WEB PORTAL
  98. NOTES…… OPENID LOGIN FOR WEB PORTAL BROWSER OP WEB PORTAL
  99. NOTES…… OPENID LOGIN FOR WEB PORTAL BROWSER OP WEB PORTAL
  100. NOTES…… OPENID LOGIN FOR WEB PORTAL BROWSER OP WEB PORTAL
  101. NOTES…… OPENID LOGIN FOR WEB PORTAL BROWSER OP WEB PORTAL
  102. NOTES…… OPENID + INFORMATION CARDS OP
  103. NOTES…… WSO2 IDENTITY SERVER OpenID Provider OP InfoCard Provider
  104. NOTES…… TRUSTED SUB SYSTEM WEB PORTAL
  105. NOTES…… TRUSTED SUB SYSTEM WEB PORTAL OP
  106. WS-Security / WS-Trust / WS-Security Policy NOTES…… SUMMARY Message Interceptor Gateway Pattern WSO2 Governance Registry / WSO2 WSAS / WSO2 ESB / WSO2 Identity Server OpenID + InfoCard Trusted Sub System Pattern
  107. http://wso2.com http://wso2.com/about/contact DISCUSSION…... bizdev@wso2.com prabath@wso2.com
  108. Thank You…!!!

×