Upload
zubin67
View
201
Download
1
Embed Size (px)
Citation preview
Securing SOA:Meeting the Challenge
Kevin T. SmithTechnical Director, ManTech International
About the Presenter • Architect of SOA Security
solutions for many government customers
• Killer of Trees - Books and Articles focusing on SW Engineering, Web Services, XML, Enterprise Architecture, and SOA Security
Recent Book: Applied SOA (Published this Month!)
• Speaker – SOA Security Workshop Presenter at many conferences (RSA, JavaOne, ApacheCon, Net-Centric Warfare, AFEI, Semtech, OMG, Potomac Forum, etc. )
Contributing Author
Why Some Get OverwhelmedFederated Identity
Key Management
Multi-Level Security
Politics involved with “standards bodies”, vendors, partial implementations…
PBACSingle Sign-On
Authentication
Authorization Integrity
Confidentiality
Auditing
RBAC
Non-Repudiation
Availability
ABAC PADBAC
WS-Security Kerberos Token Profile
PKI
XKMS
Liberty AllianceSAMLXACML XML Signature
WS-Security
XML Encryption
Kerberos
SSL
IPSec
TLS
WS-Policy
WS-Trust
WS-Availability
WS-SecureConversation
Passport
WS-SecurityPolicy
WS-Security SAML Token Profile
WS-Security Kerberos Token Profile
WS-Security X.509 Certificate Profile
WS-Security REL Token Profile
Agenda
• 4 SOA Security Challenges• 2 Good Practices • A Few “Gotchas” to Avoid: Avoiding
SOA Security Pitfalls • Final Thoughts
4 SOA Security Challenges
Challenge 1: A Change in Mindset Required
We can no longer only think Point-to Point Security,We need End-To-End Security Solutions!
Client Service
Service
Service
Service
Service
Service
Client Service
Not just …. But Also
Challenge 2: A Dynamic Environment
• From a security standpoint, “expect the unexpected!”– Assume that services
will be used in a way that you did not anticipate!!
• The interface & consequence of every service call must be explicitly defined and understood!
• Run-time Management & Governance required
B C D
E F G
H I J
A
Chances are, B-J don’t know that they are all participatingin the same message request
Challenge 3: User Distance
• Authentication & Authorization:– Each node may need to know who the
end-user is and what they can do• Single Sign-On:
– If nodes B-J have different login credentials for the user, we don’t want to force the user to log in 9 times!
• Confidentiality– Not all nodes in the middle may be
allowed to see all data in the transaction• Integrity
– Need to have assurance that message has not been altered in transit
• Performance – Every network call and all cryptography
will lead to performance degradation
B C D
E F G
H I J
A
Challenge 3, Continued -(Transitive Trust – Avoiding the “Kevin Bacon” Game)
• Transitive Trust Solutions– “Kevin told Bob to tell Fred to tell me
that I can take $500 out of his account. So I am here to make a withdrawal please.”
– Certain standards allow trust propagation and transitive trust options
• SAML• WS-Security SAML Token Profile• Certain Gov’t SOA Standards..
• Many man-in-the middle attacks– If token is not signed, must trust B-J not
to alter the token between points– If token is signed, must trust B-J to use
token in the way that does not violate its conditions of use
• Many options, based on which Access Control Policy Model you use
B C D
E F G
H I J
Label
ALabel
A
Label
A
Label
ALabel
A
Label
A
Label
ALabel
A
Am I really sure that this is Kevin
Bacon?
PKICertificate
Challenge 4: Access Ctrl Policy Enforcement• Centralized Management, Centralized
Decision Making– “Does Kevin have permission to
access me?” (Yes/No Policy Model)• Decentralized Management, Delegated
Decision Making – Local services express & enforce their
own policy based on user credentials• Centralized Management, Delegated
Decision Making– Policy “pushed”/syndicated to, or
retrieved by local service • Pre-Determined Authorization Decision
Based Access Control (PADBAC)– Requests include Signed
Authorization Decisions • Each has performance/security
implications
APolicy
ServiceBDoes Kevin have
permission?
A AttributeServiceB
What are Kevin’sAttributes so
I can make a decisionBased on locally
Expressed policy?
A Batts
Instant DecisionBased on LocallyExpressed Policy
DecisionBased on Call to Policy Service
A
Policy“Push”Service
B
Sends policyupdates
Instant DecisionBased on Globally Expressed Policy
A BAuthorization
decision Instant EnforcementBased on PreviouslyAgreed Upon Decision
atts
Two Good Practices for Meeting the Challenges
Use of Accepted Standards• Utilize accepted standards for Messaging Security (WS-
Security * Token Profiles) • Explore the Use of WS-Trust STS for establishing trust &
conveying of subject tokens• Each standard has multiple options, some containing
risks and potential vulnerabilities that should be studied -not all options are correct for your enterprise.
• Applied SOA contains an overview of many of the accepted standards, along with decision flowcharts which may help you determine: – approaches to use for identity/attribute propagation – access control enforcement methodologies
Use of Interceptors for Achieving Security Goals
The Interoperability Is In The Messaging. Embrace multiple options for policy enforcement.
Avoiding Some “Gotchas”:A Few Security Pitfalls
Pitfall #1 – Security Planning Anti-Patterns
• “Shock and Paralysis”
• “Security at the Last Minute”
• “Death By Security”
See "Avoiding SOA Security Anti-Patterns: Practical Planning for Success", SOAInstitute.org, May 2008.
Pitfall #2 – The “Kevin Bacon” Game• Make sure that your
governance team identifies:– Conditions of use of
tokens– When and when not to
use “sender-vouches”• Explore authentication
delegation & token creation to a trusted entity, separating trust of sender & asserter
B C D
E F G
H I J
Label
ALabel
A
Label
A
Label
ALabel
A
Label
A
Label
ALabel
A
Am I really sure that this is Kevin
Bacon?
PKICertificate
Service(S)
A(S) C
(S)B(S)
D(S)
Portal
Secret User
TS OOPS!(S)
Pitfall #3 - Forgetting to Secure Your Data • Some focus so much on
access control to services, that they forget to control access to the data
• On government projects, especially, data must be marked with access control (releasability) markings & filtered on the way back to the user
• Header-level vs. Element-level solutions
Pitfall #4 – Security Related Tight Coupling
Service
A C E
B D
Will changes in your service’sconnection policy require
client integration?
• A good practice is to separate security logic & business logic between– Security handlers or
related components– The logic of the service
themselves • But what about the clients of
your services adhering to your connection policy? – If you change your
messaging security, do your clients have to re-write client handlers, etc?
– If so, you are tightly-coupled to your clients.
Confidentiality
Integrity Authentication&
Authorization
Performance&
Availability
Pitfall #5 – No Security Scalability Planning
Understand the double-edged sword of cryptography and network calls to security services.
Final Thoughts• Good SOA Security Solutions are doable if you…
– Plan from the beginning (requirements analysis, security architecture & governance)
– Use well-accepted standards– Hire SOA Security professionals – Plan for performance and scalability
• Detailed SOA Security Blueprints & Best Practices are available in the “SOA Security” chapter of Applied SOA: Service Oriented Architecture and Design Strategies.