ICTA Technology Meetup 03 - SOA Security

564 views
326 views

Published on

SOA Security

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
564
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ICTA Technology Meetup 03 - SOA Security

  1. 1. ICTA Technology Meetup 03 Enterprise Security (Part 01) By Crishantha Nanayakkara
  2. 2. Agenda ● Functional Aspects of Security ● An Introduction to PKI ● An Introduction to SOA Security ● Securing SOAP Web Services ● An Introduction to Apache Rampart ● Security Patterns with Apache Rampart ● Mediating SOAP Web Services via ESB 2
  3. 3. Functional Aspects  of Security 3
  4. 4. Authentication Confidentiality Integrity Non­Repudiation 4
  5. 5. An Introduction to  PKI 5
  6. 6. PKI enables parties to an e­commerce  transaction to identify one another by  providing authentication with digital  certificates, and allows reliable business  communications by providing confidentiality  through the use of encryption, and  authentication, data integrity and a  reasonable basis for nonrepudiation through  the use of digital signatures. (Resource ­ WebTrust) 6
  7. 7. Ensuring Authentication 7
  8. 8. – Transport Layer   ● – SSL certificates HTTP Layer / Message Layer –  ● ● – HTTP Basic Authentication UserNameTokens Application Layer –  ● Form based Authentication  8
  9. 9. Ensuring Confidentiality 9
  10. 10. Public Key Encryption 10
  11. 11. Ensuring Non Repudiation 11
  12. 12. By maintaing key pairs at both ends with 2­way  authentication can ensure non­repudiation 12
  13. 13. Ensuring Integrity 13
  14. 14. Digital Signatures (Signing Process) 14
  15. 15. Digital Signatures (Verification Process) Step 1 Step 2 15
  16. 16. Digital Certificates A digital certificate is basically a wrapper around a  public key, which includes identifying information  for the party owning that key. This wrapped body is  then signed by a trusted third party, and the  signature is included in the certificate. The trusted  third party vouches for the public key and  identifying information by issuing the certificate with  its signature. 16
  17. 17. Creating Digital Certificates ● Step 1: Creating the “public­private” key­pair keytool  ­genkey  ­keyalg  RSA  ­keysize  2048  ­keystore  crish_keystore.jks ­alias certificatekey At this stage your certificate is owned and issued by you.  However, a certificate issued by you will not be trusted by  other organizations that does business with you electronically.  Therefore your certificate would need to be “signed” by a recognized certification authority. 17
  18. 18. Creating SSL Digital Certificates ● Step 2: Retrieve the contents of the keystore keytool ­list ­v ­keystore crish_keystore.jks ­storepass password crishantha@crishantha-laptop$ keytool -list -v -keystore crish_keystore.jks -storepass password Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: certificatekey Creation date: Mar 10, 2012 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=Crishantha Nanayakkara, OU=ICTA, O=ICTA, L=Colombo, ST=Western, C=SL Issuer: CN=Crishantha Nanayakkara, OU=ICTA, O=ICTA, L=Colombo, ST=Western, C=SL Serial number: 4f5b98a6 Valid from: Sat Mar 10 23:38:38 IST 2012 until: Fri Jun 08 23:38:38 IST 2012 Certificate fingerprints: MD5: D0:56:A2:FE:EF:B0:CE:08:A6:28:FF:2C:2C:33:D7:4D SHA1: 1D:77:C2:42:FD:AC:FA:32:7C:2B:D1:FF:70:95:0A:A2:66:4C:CE:27 Signature algorithm name: SHA1withRSA Version: 3 18
  19. 19. Creating Digital Certificates ● Step  3:  Generating  the  Certification  Service  Request (CSR) keytool  ­certreq  ­alias  certificatekey  ­keystore  crish_keystore.jks  ­file certificate_request.csr crishantha@crishantha-laptop:~/test$ cat certificate_request.csr -----BEGIN NEW CERTIFICATE REQUEST----MIICtTCCAZ0CAQAwcDELMAkGA1UEBhMCU0wxEDAOBgNVBAgTB1dlc3Rlcm4xEDAOBgNVBAcTB0Nv bG9tYm8xDTALBgNVBAoTBElDVEExDTALBgNVBAsTBElDVEExHzAdBgNVBAMTFkNyaXNoYW50aGEg TmFuYXlha2thcmEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChSHnDxgNLna8PBG6j 7c3+Id6q38BRmyGarLHtuvhTMxPV3r/ad49makBCPE9yeKrr1MiRMkuPYGasXunfo4Tqehcivc7n ox0MjC5rqi1sVTrxtVlfRozSNa3bVp83b/Iz5f7A8QS0YaoZo+RAHSKi6V2gC/OLMHABe/WQ/6Dv tmZ7ojY00H/nIPVZXUScNjwNGLLYohVYH9+Pd4NKG7GfqE4bnhnTVQfrpglsWcENioeSmlJ6pWLj 04PkpfqBN06YIvKZB5aZu+GsnmUHUI0po3vWBr+8JcLTAF3LBkFnTkzt2YWZZ17Tdybo7lHGLlzD UR6rTmKSQ0qztTmIMIpzAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAlMP4SfcCasFktKDH+fLj 1F3xSfEUZIj1AvbVM1qHorTlBZPFPjpQkpZJtfSFnBdWScJoEH5RdqdROzXxgwcCLH10wRCAxARP Eg7YEAegQXhquyqCMGQ5q8SvtV9WHI5GH/UgCOcRLxF07pxjEii3YT9GRYXZwNRGDfJAZjOkd+Hr i9ywhFBzLy4D5x9kcW43WYCXnIXFcL0vDXMD/5qkdgXUdgXWzhl7r3F4B1l1HFcwzzgomeGAWGHu plrPEpFMPm0bwbmpu2rEA3SoiSmOVKc8c5C8jPM2r/dpKMqpvx/focMoRLneJpCHfx0iVmlNKHuq QNc1yis0rXRfMFCWeQ== -----END NEW CERTIFICATE REQUEST----- 19
  20. 20. Creating Digital Certificates ● ● Step  4:  Send  the  generated  CSR  to  the  Certification Authority (CA) Step 5: CA will send you two things – CA root certificate – CA signed certificate Both of these need to be imported to the keystore of  yours 20
  21. 21. Creating Digital Certificates ● Step 6: Importing the CA root certificate keytool  ­import  ­alias  root­ca  ­v  ­trustcacerts    ­keystore  crish_keystore.jks ­file ca.der ● Step 7: Importing the CA signed certificate keytool ­import ­alias certificatekey ­file signed_ca.der  ­keystore  crish_keystore.jks ● Step 8: Retrieve the contents of the keystore keytool ­list ­v ­keystore crish_keystore.jks ­storepass password 21
  22. 22. Keystore and Truststore 22
  23. 23. PKI Trust Models 23
  24. 24. PKI Trust Models (Rooted Heirarchy Model) 24
  25. 25. PKI Trust Models (Rooted Heirarchy Model) The subordinate CAs (intermediate CAs and  Issuing CAs) are certified by the parent CAs.  The parent CAs are usually an intermediate  CA or a Root CA. 25
  26. 26. PKI Trust Models (Network/ Cross Certification Model) 26
  27. 27. PKI Trust Models (Network/ Cross Certification Model) Root CA can cross certify the other Root CA by  just importing the public key certificate of the  other Root CA. This relationship can be  unidirectional or bidirectional 27
  28. 28. So what is National  CA? 28
  29. 29. An Introduction to SOA Security 29
  30. 30. SOA Security ● SOAP Web Services – ● Transport Level and Message Level (Using  WS­Security) REST Web Services – Transport Level and OAuth 30
  31. 31. Securing SOAP  Web Services 31
  32. 32. Securing a SOAP web service with HTTPS Client Client Server Public Key Secured using HTTPS Web Service Web Service Server Certificate 32
  33. 33. Securing a SOAP  web service with WS­Security 33
  34. 34. WS­Security  An Introduction The standard framework for including XML­ formatted security data into SOAP messages  is WS­Security 34
  35. 35. WS­Security  An Introduction It basically provides a XML based Abstraction  Layer for the above established cryptography  techniques. 35
  36. 36. WS­Security  An Introduction 36
  37. 37. WS­Security  SOAP 37
  38. 38. Apache Rampart  An Introduction ● ● ● Apache Rampart is the security module of  Apache Axis2 It provides the WS­Security functionality  to Axis2 web services and their clients Mainly has 3 components – Rampart core – Rampart policy – Rampart trust 38
  39. 39. Apache Rampart  An Introduction ● ● ● Rampart Core: This drives security enforcement and  validation on SOAP messages. Implements WS­Security  and WS­SecureConversation. Rampart Policy: This implements WS­SecurityPolicy  specification, which is an extension to WS­Policy, Apache  Neethi implements the WS­Policy specification. Rampart Trust: This implements the WS­Trust  specification. Basically this provides a framework to  issue, cancel, renew and validate security tokens. For  example STS (Security Token Service) tokens. 39
  40. 40. Apache Rampart  An Introduction 40
  41. 41. Securing a SOAP web service Transport level with HTTPS Client Client Server Public Key Secured using HTTPS Web Service Web Service Server Key Pair 41
  42. 42. Securing a SOAP web service UserNameToken with Transport level HTTPS Client Client Server Public Key UsernameToken Secured using HTTPS + Authenticated with UserNameToken Web Service Web Service Server Key Pair Call back Handler 42
  43. 43. The Callback Handler 43
  44. 44. The Service Policy 44
  45. 45. Securing a SOAP web service Message Level Security – Asymmetric (Sign) Client Client Client Key Pair Callback Handler Message is Signed Web Service Web Service Server Key Pair Call back Handler 45
  46. 46. Service Policy (Sign only) 46
  47. 47. Service Policy (Sign) cont.. 47
  48. 48. The Callback Handler 48
  49. 49. Securing a SOAP web service Message Level Security ­ Asymmetric 49
  50. 50. Securing a SOAP web service Message Level Security – Asymmetric  (SignEncrypt) Client Client Client Key Pair Callback Handler Message is Signed and Encrypted Web Service Web Service Server Key Pair Call back Handler 50
  51. 51. Service Policy (SignEncrypt) 51
  52. 52. The Callback Handler 52
  53. 53. Ensuring Interoperablity 53
  54. 54. Mediating Secure  Web Services via ESB 54
  55. 55. End to End Security with a ”Pass Through Proxy” 55
  56. 56. End to End Security  with a ”Secure Proxy” 56
  57. 57. 57

×