icta technology meetup 03 - soa security
DESCRIPTION
SOA SecurityTRANSCRIPT
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
NonRepudiation
5
An Introduction to An Introduction to PKIPKI
6
PKI enables parties to an ecommerce 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 2way authentication can ensure nonrepudiation
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 “publicprivate” keypair
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 rootca 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
WSSecurity)● 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 WSSecuritywith WSSecurity
34
WSSecurity An Introduction
The standard framework for including XMLformatted security data into SOAP messages
is WSSecurity
35
WSSecurity An Introduction
It basically provides a XML based Abstraction Layer for the above established cryptography
techniques.
36
WSSecurity An Introduction
37
WSSecurity SOAP
38
Apache Rampart An Introduction
● Apache Rampart is the security module of Apache Axis2
● It provides the WSSecurity 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 WSSecurity and WSSecureConversation.
● Rampart Policy: This implements WSSecurityPolicy specification, which is an extension to WSPolicy, Apache Neethi implements the WSPolicy specification.
● Rampart Trust: This implements the WSTrust 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