Microsoft PowerPoint - Smith-6-25-08


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Microsoft PowerPoint - Smith-6-25-08

  1. 1. Securing SOA: Meeting the Challenge Kevin T. Smith Technical Director, ManTech International
  2. 2. About the Presenter • Architect of SOA Security solutions for many government customers • Killer of Trees - Books and Articles focusing on SW Contributing Author 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. )
  3. 3. Why Some Get Overwhelmed Authentication Federated Identity SAML Liberty Alliance WS-Trust Authorization XACML XML Signature Integrity WS-Security SAML Token Profile WS-Security WS-Availability Confidentiality ABAC PBAC Kerberos WS-SecurityPolicy IPSec PADBAC XKMS Single Sign-On WS-SecureConversation SSL RBAC WS-Security X.509 Certificate Profile PKI TLS Passport Availability Multi-Level Security WS-Security REL Token Profile XML Encryption WS-Policy WS-Security Kerberos Token Profile Auditing Non-Repudiation WS-Security Kerberos Token Profile Key Management Politics involved with “standards bodies”, vendors, partial implementations…
  4. 4. Agenda • 4 SOA Security Challenges • 2 Good Practices • A Few “Gotchas” to Avoid: Avoiding SOA Security Pitfalls • Final Thoughts
  5. 5. 4 SOA Security Challenges
  6. 6. Challenge 1: A Change in Mindset Required Not just …. But Also Service Service Service Service Service Client Client Service Service We can no longer only think Point-to Point Security, We need End-To-End Security Solutions!
  7. 7. Challenge 2: A Dynamic Environment A • From a security standpoint, “expect the B C D unexpected!” – Assume that services will be used in a way that you did not anticipate!! E F G • The interface & consequence of every service call must be explicitly defined and understood! H I J • Run-time Management & Governance required Chances are, B-J don’t know that they are all participating in the same message request
  8. 8. Challenge 3: User Distance • Authentication & Authorization: A – Each node may need to know who the end-user is and what they can do • Single Sign-On: B C D – 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 E F G allowed to see all data in the transaction • Integrity – Need to have assurance that message has not been altered in transit • Performance H I J – Every network call and all cryptography will lead to performance degradation
  9. 9. Challenge 3, Continued - (Transitive Trust – Avoiding the “Kevin Bacon” Game) • Transitive Trust Solutions – “Kevin told Bob to tell Fred to tell me Lbl ae A Lbl ae A that I can take $500 out of his account. So I am here to make a withdrawal B C D please.” Lbl ae A – Certain standards allow trust PKI Certificate propagation and transitive trust options Lbl ae A Lbl ae A • SAML E F G • WS-Security SAML Token Profile Lbl ae A • Certain Gov’t SOA Standards.. • Many man-in-the middle attacks – If token is not signed, must trust B-J not Lbl ae Lbl ae A A to alter the token between points H I J – If token is signed, must trust B-J to use token in the way that does not violate its conditions of use Am I really sure • Many options, based on which Access that this is Kevin Control Policy Model you use Bacon?
  10. 10. Challenge 4: Access Ctrl Policy Enforcement • Centralized Management, Centralized Does Kevin have permission? Decision Making Policy – “Does Kevin have permission to A B Decision Service Based on access me?” (Yes/No Policy Model) Call to Policy Service • Decentralized Management, Delegated What are Kevin’s Attributes so Attribute Decision Making A B I can make a decision Service Based on locally – Local services express & enforce their Expressed policy? own policy based on user credentials Instant Decision • Centralized Management, Delegated A B Based on Locally Expressed Policy atts Decision Making Sends policy – Policy “pushed”/syndicated to, or updates Policy “Push” retrieved by local service Service • Pre-Determined Authorization Decision A B Instant Decision Based Access Control (PADBAC) atts Based on Globally Expressed Policy – Requests include Signed Authorization Decisions Authorization Instant Enforcement • Each has performance/security A decision B Based on Previously Agreed Upon Decision implications
  11. 11. Two Good Practices for Meeting the Challenges
  12. 12. 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
  13. 13. Use of Interceptors for Achieving Security Goals The Interoperability Is In The Messaging. Embrace multiple options for policy enforcement.
  14. 14. Avoiding Some “Gotchas”: A Few Security Pitfalls
  15. 15. 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",, May 2008.
  16. 16. Pitfall #2 – The “Kevin Bacon” Game • Make sure that your governance team Lbl ae A Lbl ae A identifies: B C D – Conditions of use of Lbl ae A tokens PKI Certificate – When and when not to Lbl ae Lbl ae A A use “sender-vouches” E F G Lbl ae • Explore authentication A delegation & token Lbl ae Lbl ae creation to a trusted A A entity, separating trust H I J of sender & asserter Am I really sure that this is Kevin Bacon?
  17. 17. Pitfall #3 - Forgetting to Secure Your Data Secret User • Some focus so much on access control to Portal services, that they forget to control access to the data Service (S) • On government projects, especially, data must be marked with access control (releasability) A markings & filtered on the C D way back to the user (S) B (S) (S) (S) • Header-level vs. Element- level solutions (S) TS OOPS!
  18. 18. Pitfall #4 – Security Related Tight Coupling • A good practice is to separate security logic & business logic Service between – Security handlers or related components – The logic of the service themselves • But what about the clients of A C E your services adhering to your connection policy? – If you change your B D messaging security, do your clients have to re- Will changes in your service’s write client handlers, etc? connection policy require – If so, you are tightly- client integration? coupled to your clients.
  19. 19. Pitfall #5 – No Security Scalability Planning Confidentiality Performance & Availability Integrity Authentication & Authorization Understand the double-edged sword of cryptography and network calls to security services.
  20. 20. 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.