Summer School - Security in SOA

6,000 views

Published on

Published in: Technology, Education
3 Comments
4 Likes
Statistics
Notes
No Downloads
Views
Total views
6,000
On SlideShare
0
From Embeds
0
Number of Embeds
2,640
Actions
Shares
0
Downloads
322
Comments
3
Likes
4
Embeds 0
No embeds

No notes for slide

Summer School - Security in SOA

  1. 1. Security In SOA WSO2 Security Team
  2. 2. Do we need security.. It’s extra cost right…?
  3. 3. Everything comes at a cost… security is not an option
  4. 4. … not an option.. But a must..
  5. 5. Security is NOT an option – it’s a must
  6. 6. Security should be by design – not an after thought
  7. 7. We run everything on HTTPS – aren’t we yet secured…?
  8. 8. It’s NOT the best of the assumptions in the world you could make…
  9. 9. LISTEN..!!! I know HTTPS….
  10. 10. HTTPS helps you transfer data from one point to another point.. Securely..
  11. 11. That is.. HTTPS helps you to encrypt data transferred between a client and a server
  12. 12. That’s all about confidentiality – how about integrity?
  13. 13. Confidentiality The assurance that a message has not been read by anyone other than the intended reader
  14. 14. Integrity The assurance that data is complete and accurate
  15. 15. Authentication The verification of a claimed identity
  16. 16. With HTTPS we can have Confidentiality, Authentication & Integrity
  17. 17. Service Authentic Service ates to the client Client
  18. 18. Mutual Service Authentic ation Client
  19. 19. Don’t think all our clients want to have their own certificates – can we have user name/password instead???
  20. 20. Easy thing – use BasicAuth over HTTPS
  21. 21. Wait…. Basic auth sends username / password in clear text..right?
  22. 22. But – we are on HTTPS and it won’t be an issue… BTW what are the other options…
  23. 23. The other Option is to use Digest…
  24. 24. Let’s summarize.. Securing web services with HTTPS
  25. 25. Let’s summarize.. 1.Provides confidentiality through encryption
  26. 26. Let’s summarize.. 2.Service authenticates to the client via certificates
  27. 27. Let’s 3.Client can summarize.. authenticate via certificates, basic auth / digest
  28. 28. I need a better subject… any guesses???
  29. 29. That’s actually Transport-level security
  30. 30. OMG….I remember somebody saying Transport level security – can be insufficient….??? Who said that…?
  31. 31. Patience…. Sir.. It’s me….
  32. 32. I can explain….
  33. 33. Transport level security secures a message only during the transfer from one point to another point.
  34. 34. In other words.. Only while the message is on the wire…
  35. 35. HTTPS HTTPS
  36. 36. When we use Transport level security [SSL] our messages are not secured on ‘intermediaries’
  37. 37. Not – just that – we cant even encrypt only a part of the message – if we depend on transport level security
  38. 38. Need a way to get rid of transport level security….
  39. 39. We can handle security at the message level…
  40. 40. That way – we can protect entire message or even just a part of it….
  41. 41. Just – confidentiality is NOT enough – we need to think about adding Integrity and Authentication at the Message level…
  42. 42. Let’s start with one by one – can anyone tell me how do we support authentication at the message level….???
  43. 43. It’s simple – I will add a custom SOAP HEADER
  44. 44. <Credentials> <UserName></UserName> <Password></Password> </Credentials>
  45. 45. I don’t like having custom headers… that kills interoperability….
  46. 46. Yes – true – we should not try to re- implement the wheel..
  47. 47. Okay – then somebody explain – what do we have on our hands…?
  48. 48. Haven’t you guys heard of WS- Security….
  49. 49. It defines how to achieve confidentiality, integrity and authentication on SOAP messages…
  50. 50. Let me clarify – ws- security doesn’t define new security technology….
  51. 51. It focuses on applying existing security technologies to SOAP messages…
  52. 52. Wow… exactly what we wanted…
  53. 53. For authentication – WS-Security defines UsernameToken
  54. 54. <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>
  55. 55. I looked into the WS-Security spec – but it does NOT provide enough details on UsernameToken…. Where else should I look into..?
  56. 56. Here it is – you need to look into the UsernameToken Profile spec…
  57. 57. Let’s summarize.. Your findings on Securing Message level security and web Username Token… services with Message level Security
  58. 58. Let’s summarize.. Your findings on Message level security and 1.Defined in Username Token… WS-Security specification
  59. 59. Let’s summarize.. Your findings on Message level security and 2.End to end Username Token… security with support for confidentiality, integrity and authentication
  60. 60. Let’s summarize.. Your findings on Message level security and 3.UsernameToken Username Token… can be used to authenticate users to the service.
  61. 61. Let’s summarize.. Your findings on Message level security and 4.UsernameToken Username Token… can have password in clear text or as a digest.
  62. 62. Let’s summarize.. Your findings on Message level security and 5.UsernameToken Username Token… defined in UsernameToken Profile specification.
  63. 63. Let’s move forward – how about Encryption with Message level security
  64. 64. With WS-Security we can encrypt Body, Header and any of those sub- structures…
  65. 65. Can somebody explains me how this encryption happens???
  66. 66. That is basically a shared symmetric key….
  67. 67. It can be with a key already shared or known to both the service and the client
  68. 68. We are going off the topic here.. Anyway here’s some basic explanation….
  69. 69. Symmetric key encryption uses a shared key for both encryption and decryption…
  70. 70. Public key encryption uses different keys for encryption and decryption…
  71. 71. Let me add more….
  72. 72. Symmetric key encryption is fast…
  73. 73. It can operate on large plain text messages…
  74. 74. Symmetric key encryption uses public key encryption to manage shared key distribution securely
  75. 75. Okay..okay.. I know… AES, 3DES are shared key encryption algorithms
  76. 76. Back to the topic…. WS-Security can also use wrapped key encryption as well…
  77. 77. Got the point…. If shared key being used then both client and service have to share the key…..
  78. 78. If client doesn’t have a key – then a shared key will be derived through a key wrapping algorithm with service’s certificate
  79. 79. That sounds good – even client not having a cert – we still can have encryption…. Let’s move to the other aspect… Integrity…..
  80. 80. WS-Security brings XML Signature in to SOAP messages to achieve integrity….
  81. 81. BTW.. Signature not only gives you integrity – but also the non-repudiation
  82. 82. Let me add little more… if you need to know bit more about XML Signature
  83. 83. XML Signature defines three types of Signatures – enveloping, enveloped and detached. WS- Security utilizes only Detached…
  84. 84. Okay – that’s enough… let’s start building the big picture on WS- Security now… from what we have discussed so far….
  85. 85. WS - Security XML Username X.509 Token XML Signature Encryption Token Profile Profile
  86. 86. Now we know how to authenticate users with message level security….
  87. 87. Also how to add confidentiali ty…
  88. 88. And.. Integrity and non- repudiation…
  89. 89. Now – the question is… who should be able to access our system???
  90. 90. All our employees need access…
  91. 91. Some of our partner companies also need access…
  92. 92. We maintain the credentials of our employees - so we can easily authenticate them…
  93. 93. How can we authenticate users from partner companies…
  94. 94. Let’s create individual accounts to each of them and maintain those records locally….
  95. 95. What a dumb idea is that… you want to maintain thousands of external domain user accounts internally…
  96. 96. We need not to trust each individual belong to our partner companies… we only trust them until they belong to our partner companies…
  97. 97. Exactly – we only trust our partners only… But we can let their employees to access our system if the company says it’s okay to give access…
  98. 98. In simple terms now we need to find out a way to establish trust between our partner companies…
  99. 99. That’s simple… let’s accept requests from out-siders - only if those requests being signed by a trusted partner…
  100. 100. That sounds cool.. So we’ll be maintaining a set of public certs of trusted partners to validate signatures
  101. 101. This only solves part of the problem… how about our users who need access to external system…. How do we sign all the requests when they go out to external services…
  102. 102. Listen… I found some thing interesting – WS- Trust – this exactly solves our problem….
  103. 103. We’ll be maintaining an STS – which is connected to our internal user store
  104. 104. Any of our users who needs access to an external service will send a request to our internal STS
  105. 105. Need to authenticate him with a Username Token
  106. 106. Since the internal STS is connected to the internal user store – STS can verify user credentials
  107. 107. Once the credentials validated, the STS will issue a token with the required claims and sign it by our private key
  108. 108. If the external service trusts our STS – our users will let in…
  109. 109. Sounds GREAT..!!! It’s the same for external users who needs access to our services… we will only trust their STS…
  110. 110. Let me build the BIG picture once again…..
  111. 111. WS - Trust WS - Security XML Username X.509 XML Encryptio Token Token Signature n Profile Profile
  112. 112. Now we have secured our system…..
  113. 113. Also we know who to trust and how….
  114. 114. But – how do we let other’s who work with us know security standards we use….
  115. 115. Ah… yes… when external users accessing our system they must provide their email address with all their requests….
  116. 116. Not – just that – they also have to know encryption/signature algorithms we use….
  117. 117. Also – we are not going to encrypt entire message – only some parts – so we need to tell them which parts to encrypt…
  118. 118. I am going to prepare a document which includes all our security requirements..
  119. 119. - Requires Email address… - Encryption algorithms AES - Encryption key size 256 - Encryption algorithms AES - All the parts in the <Body> must be signed - Parts to be encrypted depends on the service…
  120. 120. Looks good… we need to extend this further…And this is our security policy…
  121. 121. There should be a standard way of communicating our security policy to others… let me Google….
  122. 122. Oh.. Yes.. WS- SecurityPolicy…
  123. 123. We can use it to express security requirements of a Web service according to, What needs to be protected… What tokens to use… Algorithms, reference types, etc….
  124. 124. We need to have different security policies for different services… how can we associate a security policy with a given service….
  125. 125. That’s simple – you can point to a policy from the WSDL
  126. 126. But .. People may access our service with SOAP1.1 over HTTP, SOAP 1.2 over HTTPS, SOAP 1.1 over JMS…
  127. 127. We may need to change our policy based on different ways people access…. If we have this pointed in WSDL – it will be same for all those cases… right….?
  128. 128. Okay – you want to change the policy based on the message format and the protocol
  129. 129. That is… you want to have different security policies for different ‘bindings’… that is possible and it’s the recommendation…
  130. 130. <wsdl:binding name="HelloServiceSoap11Binding“ type="ns:HelloServicePortType"> <wsp:PolicyReference xmlns:wsp=“" URI="#SgnEncrUsername" /> <soap:binding transport=http://schemas.xmlsoap.org/soap/http style="document" /> <wsdl:operation name="greet"> <soap:operation soapAction="urn:greet“ style="document" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding>
  131. 131. Now.. Let’s see how we can express some of our requirements in WS-SecurityPolicy
  132. 132. UsernameToken should be included….
  133. 133. <wsp:Policy> <sp:UsernameToken sp:IncludeToken=“”/> </wsp:Policy>
  134. 134. We should accept UsernameToken – only if they are signed…
  135. 135. <sp:SignedSupportingTokens xmlns:sp=""> <wsp:Policy> <sp:UsernameToken sp:IncludeToken=“"/> </wsp:Policy> </sp:SignedSupportingTokens>
  136. 136. Will be using AES with 256 key size…
  137. 137. <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite>
  138. 138. We need entire <Body> of the message to be signed…
  139. 139. <sp:SignedParts> <sp:Body/> </sp:SignedParts>
  140. 140. How about encrypting just a part of the <Body>….
  141. 141. <sp:EncryptedElements XPathVersion="xs:anyURI"? ... > <sp:XPath>xs:string</sp:XPath>+ ... </sp:EncryptedElements>
  142. 142. Also… we need to express the requirement for the required claim set….
  143. 143. <sp:RequestSecurityTokenTemplate xmlns:t=""> <t:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1 </t:TokenType> <t:KeyType > http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey </t:KeyType> <t:KeySize>256</t:KeySize> <t:Claims Dialect=http://wso2.org/claims xmlns:ic=""> <ic:ClaimType Uri="http://wso2.org/claims/email" /> </t:Claims> </sp:RequestSecurityTokenTemplate>
  144. 144. That’s it… let’s move forward… Now we are secured.. We know who to trust and how to trust…
  145. 145. We also know how to communicate our security requirements to the rest….
  146. 146. Let me build the BIG picture once again…..
  147. 147. WS - Trust WS- SecurityPo licy WS - Security XML Username X.509 XML WS-Policy Encryptio Token Token Signature n Profile Profile
  148. 148. Now we need to find out a way to put this all- together…
  149. 149. We should not expose all our services directly to external domain…
  150. 150. Agreed – having multiple entry point into the system could create security holes…
  151. 151. Let’s make sure we authenticate and authorize users centrally…. And we can load balance on that end point….
  152. 152. So let’s not expose any of our services to out side….
  153. 153. We can have proxy service and in front and only the authenticated and authorized requests will flow through to the internal services…
  154. 154. Authentication Module Authorization Module Service Service Service A B C
  155. 155. This is a familiar security pattern… Message Interceptor Gateway…
  156. 156. Let me improve the diagram a bit….. Authentication Module Authorization Module LDAP Service Service Service A B C
  157. 157. Anybody knows what the authorization module does…? We need fine grained authorization….
  158. 158. Yes.. Exactly… we need a way to say.. Users belong to the role X can access Resource Y only during this particular time…
  159. 159. We should also be able to say – any users belong to role Z cannot access any resources….
  160. 160. That’ s simple – give me your requirement – I’ll right a policy for it –and Authorization module will evaluate it…
  161. 161. Oh..NO… don’t panic – we need not to reinvent the wheel… this what exactly XACML does…..
  162. 162. Sounds good – we should go ahead with the standards….
  163. 163. I know XACML….
  164. 164. It’s a specification which defines how to implement fine grained authorization in a standard way…
  165. 165. Let me add XACML to out architecture diagram…
  166. 166. Now – under the XACMl terminology, our Authorization module will act as the Policy Evaluation Point [PEP]
  167. 167. Authentication Module Authorization Module [PEP] LDAP Service Service Service A B C
  168. 168. PEP is not just enough – we need to have a XACML engine to act as a Policy Decision Point….
  169. 169. Yes…. Policy decision is made at the PDP – PEP will build the Auth’Z request and contact PDP… let’s bring PDP to the picture…
  170. 170. Authentication Module Authorization Module [PEP] LDAP Service Service Service PDP A B C
  171. 171. Then again – PDP has to retrieve XACML policies from a policy store….
  172. 172. Authentication Module Authorization Module [PEP] LDAP Service Service Service PDP A B C Policy Store
  173. 173. How do we going to add new policies… we also need to have a policy administration point…
  174. 174. Authentication Module PAP Authorization Module [PEP] LDAP Service Service Service PDP A B C Policy Store
  175. 175. Let’s celebrate – we completed the security design for our backend services…
  176. 176. Now… we need to think about how we authenticate users at the front-end….
  177. 177. I hate passwords… how many passwords I have to remember even now… If this going to add another password to that list – I am against it…
  178. 178. I agree – too many password is a problem…
  179. 179. See… even within our company we need to have different passwords to access different systems…
  180. 180. Okay… let’s solve the too many passwords problem…
  181. 181. Hey…. We need not to worry about it… OpenID is for that…
  182. 182. Also – OpenID facilitates decentralized single sign on…
  183. 183. That’s great – if we use OpenID – we only sign in once…
  184. 184. How can we implement this…?
  185. 185. First thing… our web application needs to be an OpenID relying party…. That is our application will accept OpenID logins….
  186. 186. Also – we can run our own OpenID Provider…
  187. 187. Then all our web applications will redirect users to our own OpenID Provider for authentication….
  188. 188. I don’t like OpenID – it’s phishing heaven…
  189. 189. Hey.. Man… You got it wrong… Phishing is a separate issue – OpenID doesn’t try to address Phishing…
  190. 190. Then who’s going to solve the problem of solving phishing…?
  191. 191. Heard of Information Cards…??? It’s going to address the issue of phishing…
  192. 192. I know Information cards… it’s an application of WS- Trust….
  193. 193. We already decided to run an STS – so we can easily become an information cards provider too…..
  194. 194. Then what…???
  195. 195. Then – at the OpenID provider – we can ask users to authenticate with information cards – in a phishing resistant manner….
  196. 196. Great.. That sounds perfect….
  197. 197. Okay.. We are almost done…
  198. 198. But… yet we need to figure out how to implement this…
  199. 199. Remember guys…. The cost matters the most….
  200. 200. Yes.. We can’t let product vendors kill us…
  201. 201. So… let’s figure out available open source options first….
  202. 202. Let’s use WSAS to deploy our services…
  203. 203. Who knows more about WSAS….?
  204. 204. It is an open source, enterprise- ready, Web services engine based on Apache Axis2….
  205. 205. Authentication Module PAP Authorization Module [PEP] LDAP PDP Service Service Service A B C Policy Store
  206. 206. Now… What.. Anybody knows an open source XACMl engine….
  207. 207. WSO2 Identity Server can do it for sure…
  208. 208. It’s not just an XACML engine… we can use it as our OpenID Provider as well…
  209. 209. Also… it comes with an Information Card provider…
  210. 210. Wow… that looks perfect for us… let’s see how this fits into our architecture diagram….
  211. 211. Authentication Module PAP Authorization Module [PEP] PDP LDAP Service Service Service A B C Policy Store
  212. 212. Looks good…. hmm… a question – can we deploy Identity Server over our LDAP server…?
  213. 213. Yes…. That’s a must – we need to use our existing user store….
  214. 214. That’s easy – you can simply connect Identity Server to our LDAP server…
  215. 215. Exactly – it’s a matter of a simple configuration…
  216. 216. Okay…. That sounds good.. So… Identity Server will be our XACMl engine, OpenID Provider and also the Information Card provider….
  217. 217. Authentication Module PAP Authorization Module [PEP] PDP Service Service Service LDAP A B C Policy Store
  218. 218. How about the STS…? Can we use Identity Server for that…?
  219. 219. One more thing… we need the STS to be claim aware…
  220. 220. … it should connect to our LDAP and pick the user attributes from there… can Identity Server do it?
  221. 221. Look at this… you can do it with Identity Server…
  222. 222. … it has this claim management component… we can easily configure Identity Server STS to use our LDAP…
  223. 223. Authentication Module PAP STS Authorization Module [PEP] PDP Service Service Service LDAP A B C Policy Store
  224. 224. Looks perfect…. What else missing…
  225. 225. How about using WSO2 ESB… as the service bus…?
  226. 226. Yes… that helps us implementing Message Interceptor Gateway pattern easily…
  227. 227. See this… it comes with an Entitlement Mediator – which can connect to the Identity Server’s XACMl engine…
  228. 228. Wow…!!! I like whatever makes us less work…
  229. 229. Who knows more about WSO2 ESB….?
  230. 230. It enables the loose- coupling of services, connecting systems in a managed virtualized manner….
  231. 231. …. allowing administrators to control and direct communication without disrupting existing applications
  232. 232. PAP Authentication Module STS Authorization Module [PEP] PDP Service Service Service LDAP Policy Store A B C
  233. 233. Okay…. Now we need a policy store….
  234. 234. Let me.. Suggest this time… WSO2 Governance Registry will do that….
  235. 235. So.. Clever  I also found the same… It’s very much more than just a policy store – or a registry…
  236. 236. …It is an enterprise-ready open source product for governing SOA deployments…
  237. 237. Sounds great.. Let’s update the diagram… we are almost getting to the end….
  238. 238. PAP Authentication Module STS Authorization Module [PEP] PDP Service Service Service LDAP A B C
  239. 239. Looks great..!!! Finally we came up with a fully open source solution for our security design…
  240. 240. Thanks a lot… for your participation…
  241. 241. Time for questions… I am sure you guys have many….???
  242. 242. …also you can reach us through… http://wso2.com, http://wso2.com/about/contact & bizdev@wso2.com
  243. 243. Thank You…!!!

×