ICTA Technology Meetup 03ICTA 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

3

Functional Aspects Functional Aspects of Securityof Security

4

Authentication

Confidentiality

Integrity

Non­Repudiation

5

An Introduction to An Introduction to PKIPKI

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)

7

EnsuringEnsuringAuthenticationAuthentication

8

– Transport Layer  ● SSL certificates

– HTTP Layer / Message Layer – ● HTTP Basic Authentication● UserNameTokens

– Application Layer – ● Form based Authentication 

9

EnsuringEnsuringConfidentialityConfidentiality

10

Public Key Encryption

11

EnsuringEnsuringNon RepudiationNon Repudiation

12

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

13

EnsuringEnsuringIntegrityIntegrity

14

Digital Signatures(Signing Process)

15

Digital Signatures(Verification Process)

Step 1

Step 2

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.

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.

18

Creating SSL Digital Certificates

crishantha@crishantha-laptop$ keytool -list -v -keystore crish_keystore.jks -storepass password Keystore type: JKSKeystore provider: SUN

Your keystore contains 1 entry

Alias name: certificatekeyCreation date: Mar 10, 2012Entry type: PrivateKeyEntryCertificate chain length: 1Certificate[1]:Owner: CN=Crishantha Nanayakkara, OU=ICTA, O=ICTA, L=Colombo, ST=Western, C=SLIssuer: CN=Crishantha Nanayakkara, OU=ICTA, O=ICTA, L=Colombo, ST=Western, C=SLSerial number: 4f5b98a6Valid from: Sat Mar 10 23:38:38 IST 2012 until: Fri Jun 08 23:38:38 IST 2012Certificate 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

● Step 2: Retrieve the contents of the keystorekeytool ­list ­v ­keystore crish_keystore.jks ­storepass password

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-----MIICtTCCAZ0CAQAwcDELMAkGA1UEBhMCU0wxEDAOBgNVBAgTB1dlc3Rlcm4xEDAOBgNVBAcTB0NvbG9tYm8xDTALBgNVBAoTBElDVEExDTALBgNVBAsTBElDVEExHzAdBgNVBAMTFkNyaXNoYW50aGEgTmFuYXlha2thcmEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChSHnDxgNLna8PBG6j7c3+Id6q38BRmyGarLHtuvhTMxPV3r/ad49makBCPE9yeKrr1MiRMkuPYGasXunfo4Tqehcivc7nox0MjC5rqi1sVTrxtVlfRozSNa3bVp83b/Iz5f7A8QS0YaoZo+RAHSKi6V2gC/OLMHABe/WQ/6DvtmZ7ojY00H/nIPVZXUScNjwNGLLYohVYH9+Pd4NKG7GfqE4bnhnTVQfrpglsWcENioeSmlJ6pWLj04PkpfqBN06YIvKZB5aZu+GsnmUHUI0po3vWBr+8JcLTAF3LBkFnTkzt2YWZZ17Tdybo7lHGLlzDUR6rTmKSQ0qztTmIMIpzAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAlMP4SfcCasFktKDH+fLj1F3xSfEUZIj1AvbVM1qHorTlBZPFPjpQkpZJtfSFnBdWScJoEH5RdqdROzXxgwcCLH10wRCAxARPEg7YEAegQXhquyqCMGQ5q8SvtV9WHI5GH/UgCOcRLxF07pxjEii3YT9GRYXZwNRGDfJAZjOkd+Hri9ywhFBzLy4D5x9kcW43WYCXnIXFcL0vDXMD/5qkdgXUdgXWzhl7r3F4B1l1HFcwzzgomeGAWGHuplrPEpFMPm0bwbmpu2rEA3SoiSmOVKc8c5C8jPM2r/dpKMqpvx/focMoRLneJpCHfx0iVmlNKHuqQNc1yis0rXRfMFCWeQ==-----END NEW CERTIFICATE REQUEST-----

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

21

Creating Digital Certificates

● Step 6: Importing the CA root certificatekeytool  ­import  ­alias  root­ca  ­v  ­trustcacerts    ­keystore crish_keystore.jks ­file ca.der

● Step 7: Importing the CA signed certificatekeytool ­import ­alias certificatekey ­file signed_ca.der  ­keystore crish_keystore.jks

● Step 8: Retrieve the contents of the keystorekeytool ­list ­v ­keystore crish_keystore.jks ­storepass password

22

Keystore and Truststore

23

PKIPKITrust ModelsTrust Models

24

PKI Trust Models(Rooted Heirarchy Model)

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.

26

PKI Trust Models(Network/ Cross Certification Model)

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

28

So what is National So what is National CA?CA?

29

An Introduction toAn Introduction toSOA SecuritySOA Security

30

SOA Security

● SOAP Web Services– Transport Level and Message Level (Using 

WS­Security)● REST Web Services

– Transport Level and OAuth

31

Securing SOAP Securing SOAP Web ServicesWeb Services

32

Web ServiceWeb ServiceClientClientSecured using

HTTPS

Server CertificateServer Public Key

Securing a SOAP web servicewith HTTPS

33

Securing a SOAP Securing a SOAP web serviceweb service

with WS­Securitywith WS­Security

34

WS­Security An Introduction

The standard framework for including XML­formatted security data into SOAP messages 

is WS­Security

35

WS­Security An Introduction

It basically provides a XML based Abstraction Layer for the above established cryptography 

techniques.

36

WS­Security An Introduction

37

WS­Security SOAP

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

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.

40

Apache Rampart An Introduction

41

Web ServiceWeb ServiceClientClientSecured using

HTTPS

Server Key PairServer Public Key

Securing a SOAP web serviceTransport level with HTTPS

42

Web ServiceWeb ServiceClientClient

Secured usingHTTPS

+ Authenticated withUserNameToken

Securing a SOAP web serviceUserNameToken with Transport level HTTPS

Server Key PairServer Public Key

Call back HandlerUsernameToken

43

The Callback Handler

44

The Service Policy

45

Web ServiceWeb ServiceClientClient Message isSigned

Securing a SOAP web serviceMessage Level Security – Asymmetric (Sign)

Server Key PairClient Key Pair

Call back HandlerCallback Handler

46

Service Policy (Sign only)

47

Service Policy (Sign) cont..

48

The Callback Handler

\

49

Securing a SOAP web serviceMessage Level Security ­ Asymmetric

50

Web ServiceWeb ServiceClientClient Message isSigned and Encrypted

Securing a SOAP web serviceMessage Level Security – Asymmetric 

(SignEncrypt)

Server Key PairClient Key Pair

Call back HandlerCallback Handler

51

Service Policy (SignEncrypt)

52

The Callback Handler

53

Ensuring Interoperablity

54

Mediating Secure Mediating Secure Web Services viaWeb Services via

ESBESB

55

End to End Securitywith a ”Pass Through Proxy”

56

End to End Security with a ”Secure Proxy”

57