SOA Security

1. ICTA Technology Meetup 03
Enterprise Security
(Part 01)
By Crishantha Nanayakkara

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. Functional Aspects
of Security
3

4. Authentication
Confidentiality
Integrity
Non­Repudiation
4

5. An Introduction to
PKI
5

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. Ensuring
Authentication
7

8. –
Transport Layer
●
–
SSL certificates
HTTP Layer / Message Layer –
●
●
–
HTTP Basic Authentication
UserNameTokens
Application Layer –
●
Form based Authentication
8

9. Ensuring
Confidentiality
9

10. Public Key Encryption
10

11. Ensuring
Non Repudiation
11

12. By maintaing key pairs at both ends with 2­way
authentication can ensure non­repudiation
12

13. Ensuring
Integrity
13

14. Digital Signatures
(Signing Process)
14

15. Digital Signatures
(Verification Process)
Step 1
Step 2
15

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. 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. 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. 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. 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. 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. Keystore and Truststore
22

23. PKI
Trust Models
23

24. PKI Trust Models
(Rooted Heirarchy Model)
24

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. PKI Trust Models
(Network/ Cross Certification Model)
26

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. So what is National
CA?
28

29. An Introduction to
SOA Security
29

30. SOA Security
●
SOAP Web Services
–
●
Transport Level and Message Level (Using
WS­Security)
REST Web Services
–
Transport Level and OAuth
30

31. Securing SOAP
Web Services
31

32. Securing a SOAP web service
with HTTPS
Client
Client
Server Public Key
Secured using
HTTPS
Web Service
Web Service
Server Certificate
32

33. Securing a SOAP
web service
with WS­Security
33

34. WS­Security
An Introduction
The standard framework for including XML­
formatted security data into SOAP messages
is WS­Security
34

35. WS­Security
An Introduction
It basically provides a XML based Abstraction
Layer for the above established cryptography
techniques.
35

36. WS­Security
An Introduction
36

37. WS­Security
SOAP
37

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. 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. Apache Rampart
An Introduction
40

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. 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. The Callback Handler
43

44. The Service Policy
44

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. Service Policy (Sign only)
46

47. Service Policy (Sign) cont..
47

48. The Callback Handler
48

49. Securing a SOAP web service
Message Level Security ­ Asymmetric
49

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. Service Policy (SignEncrypt)
51

52. The Callback Handler
52

53. Ensuring Interoperablity
53

54. Mediating Secure
Web Services via
ESB
54

55. End to End Security
with a ”Pass Through Proxy”
55

56. End to End Security
with a ”Secure Proxy”
56

57. 57