Title: SOA-39: Securing Your SOA
1SOA-39 Securing Your SOA
- Mitigating Security Risks of a De-coupled
Infrastructure
Francois Martel
Principal Solution Engineer
2Agenda
- The Fundamental Shift
- SOA Security Challenges
- The Standards
- The Progress Security Solution
3SOA Security The Fundamental Shift
In Traditional applications the backend is
dedicated to the application which provides the
security.
Application
4SOA Security The Fundamental Shift Application
Silo Security
- Single (simple) security model
- Security policies apply to the application only
- Trustworthiness is not an issue
- Security decisions have local impact only
- Hard Coding Security Common
- Security context commonly sent in the clear
5SOA Security The Fundamental Shift
In SOA the backend is exposed as Services that
are shared across applications.
Service Provider
Application
Service Provider
Application
6SOA Security The Fundamental ShiftSOA Business
Processes Span Applications
- Developers cant account for all interactions
- Cannot hard-code security into applications
- Security policies must apply to entire processes
- Sensitive information may not be intended for all
parties consuming the same service - The typical transport protocol is HTTP(S) which
is open on most firewalls
7SOA Security Challenges Functional Aspects of
Security
8SOA Security TRUST Trust in a SOA
- Traditional
- There is typically a concept of a trusted
computing base. The TCB provides mechanisms for
enforcing security policy that protects resources
in a controlled environment
9SOA Security AUTHENTICITY Authenticity
(Authentication) for SOA
- Traditional Applications
- No matter how the user authenticates to the
application, the onus of validating and
authorizing the user typically falls on the
application, regardless of what the application
is using to do the access control
- SOA
- Services are accessed on behalf of users. Service
developers dont know all the different contexts
in which their services will be used
10SOA Security INTEGRITY Data Integrity/Confident
iality Strategy for SOA
- Traditional
- Transport layer security (SSL/TLS) is used for
secure communications between points
SSL
- SOA
- SSL everywhere is not practical
- Message data is relayed from service to service
- Some data is intended for services further down
the chain - Integrity of relayed data is questionable
11SOA Security CONTROL Control Procedures for SOA
- Traditional
- Controls are tightly coupled to applications and
thus can be managed directly from the application
itself
- SOA
- Need the ability to centrally and consistently
enforce and audit policy and procedures across
disparate applications
12SOA Security INTEROPERABILITY Interoperability
in a SOA
- Traditional
- As interoperability between applications was
itself not guaranteed, interoperability of
security implementations was traditionally no a
topic of great interest as most applications
could handle this on a one-to-one basis
- SOA
- Must support multiple security mechanism because
there is little control over service consumers
13SOA Security Challenges Summary
- Authenticity (Access Control)
- Services are accessed on behalf of users
- User identity must be propagated
- The service consumers are not homogeneous
- Different credentials must be supported
- Integrity / Privacy
- Data is relayed from service to service
- Some data must be passed but should only be
accessed by specific backend services - Encrypt part of the message
- Some data has to be passed in the clear but its
origin verified - Sign part of the message
- Controls and Interoperability
- Harder to manage as the number of applications
involved in a process increases
14SOA Security The Standards
- The new challenges of SOA Security require both
new technology as well as new standards. - Standards help with security interoperability
- Two standards have been very broadly adopted
- WS-Security
- SAML
15SOA Security Standards to the RescueWS-Security
- Specifies how integrity and confidentiality can
be enforced on Web services messaging - Describes how to attach signatures and encryption
headers to SOAP message
- Helps with interoperability
- Supports signing/encrypting message fields
16SOA Security Standards to the RescueWS-Security
- its a protocol, not a toolset
ltwsseSecurity xmlnswsse"..."
xmlnswsu"..."gt ltdsSignature
xmlnsds"http//www.w3.org/2000/09/xmldsig"gt
ltdsSignedInfogt ltdsReference
URI"body"gtlt/dsReferencegt ltdsReference
URI"keyinfo"gt ltdsTransformsgt
ltdsTransform Algorithm"...STR-Transform"gt
ltwsseTransformationParametersgt ltdsCanonicaliza
tionMethod Algorithm""/gt lt/wsseTransformati
onParametersgt lt/dsTransformgt
lt/dsTransformsgt lt/dsReferencegt
lt/dsSignedInfogt ltdsSignatureValuegtHFLPlt/dsS
ignatureValuegt ltdsKeyInfo Id"keyinfo"gt ltwss
eSecurityTokenReferencegt ltwsseKeyIdentifier
ValueType"X509SubjectKeyIdentifier"gt MIGfMa0
GCSqLKFSJDLSDJ.... lt/wsseKeyIdentifiergt lt/wss
eSecurityTokenReferencegt lt/dsKeyInfogt
lt/dsSignaturegt lt/wsseSecuritygt
17SOA Security Standards to the RescueSAML
- Standard for exchanging authentication and
authorization data between security domains - Back end service can verify what user was
authenticated by the gate keeper - Equivalent to Single Sign-On (SSO) for Web
Services
18SOA Security Standards to the RescueSAML Its
a protocol, not a toolset
ltsamlAssertion AssertionID" "gt
ltsamlConditions NotBefore"2008-05-06T152313.8
85Z" NotOnOrAfter"2008-05-06T153823.885Z"/gt
ltsamlAttributeStatementgt
ltsamlSubjectgt
ltsamlNameIdentifier Format"
NameQualifier"AI"gttestlt/samlNameIdentifiergt
ltsamlSubjectConfirmationgt
ltsamlConfirmationMethodgturnoas
isnamestcSAML1.0cmsender-voucheslt/samlConfi
rmationMethodgt
lt/samlSubjectConfirmationgt
lt/samlSubjectgt lt/samlAttributeSta
tementgt ltSignature
xmlns"http//www.w3.org/2000/09/xmldsig"gt
ltSignedInfogt
ltCanonicalizationMethod Algorithm"http//www.w3.o
rg/2001/10/xml-exc-c14n"/gt
ltSignatureMethod Algorithm"http//www.w3.org/2000
/09/xmldsigrsa-sha1"/gt
ltReference URI"Id-3a3c3dd1-debb-9b50-6379-177b18
01e28f"gt ltTransformsgt
ltTransform
Algorithm"http//www.w3.org/2000/09/xmldsigenvel
oped-signature"/gt
ltTransform Algorithm"http//www.w3.org/2001/10/xm
l-exc-c14n"/gt
lt/Transformsgt
ltDigestMethod Algorithm"http//www.w3.org/2000/09
/xmldsigsha1"/gt
ltDigestValuegtYQIsRZPBnfEMkehIvuq/WueeGzolt/DigestV
aluegt lt/Referencegt
lt/SignedInfogt
ltSignatureValuegtencoded signaturelt/SignatureValu
egt ltKeyInfogt
ltX509Datagt
ltX509Certificategtencoded public key
certificatelt/X509Certificategt
lt/X509Datagt lt/KeyInfogt
lt/Signaturegt lt/samlAssertiongt
19SOA Security - Did Standards Save Us?
20SOA Security Challenge and Opportunity
Separating policies from the service lifecycle
Policy Groups
- Centralize policy definitions and enforcement
- No per-service work as policies change
21SOA Security Challenge and Opportunity
Separating policies from the service lifecycle
22SOA Security Challenge and Opportunity
- Security Contracts
- User Credentials
- Authentication
- Authorization
- Encryption/Signature
- Schema Validation
- Applications
- Managed Service Security Settings
- Load Balancing
- Failover
- Policy Groups
- Shared Message Processing Blocks
23SOA Security Challenge and Opportunity
Separating policies from the service lifecycle
First Mile Security
Last Mile Security
Security Proxy
24Protecting the Last Mile
- Having a security enforcement point is one thing,
ensuring all service consumers use it is another.
Service
Authorized consumer
Service
Unauthorized consumer
25Trust Zones Protect the Last Mile
Last-mileSecurityAttack
CONSUMER
X
Service
Normal Path
INTERNAL CONSUMER
Service
TRUSTZONE
26Visibility is critical to Security
- If you cant see it
- You cant measure it
- You cant secure it
- You cant control it
- You cant manage it
27Visibility is critical to SOA Security
- Discover
- Dynamic service discovery
- Automatic service delivery flow mapping
- End-to-end multi-protocol support
- Service network visualization
Discover ? Monitor ? Evaluate Policy ? Alert ?
Resolve
28?
Questions
29Thank You
30(No Transcript)