• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Toufic  Boubez   The  Future Of  S O A  Security
 

Toufic Boubez The Future Of S O A Security

on

  • 927 views

 

Statistics

Views

Total Views
927
Views on SlideShare
927
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Toufic  Boubez   The  Future Of  S O A  Security Toufic Boubez The Future Of S O A Security Document Transcript

    • 24-10-2008 This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena www.soasymposium.com info@soasymposium.com Founding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors The Future of SOA Security (as far as I can guess) Toufic Boubez, Ph.D. Chief Technology Officer Layer 7 Technologies tboubez@layer7tech.com www.layer7tech.com 1
    • 24-10-2008 Agenda  LOTS of material to cover!!  No time for Agenda!! © Toufic Boubez - Layer 7 Technologies Speaker Introduction  Current:  Layer 7 Co-Founder and Chief Technology Officer.  Co-Editor: WS-Policy W3C Work Group  Co-Author: WS-Trust, WS-SecureConversation, WS-Federation.  OASIS WS-RM TC, WS-SX TC  Books: Building Web Services with Java (12/2001), Java P2P Unleashed (8/2002).  Background:  IBM Lead Architect for Web Services.  IBM Lead Architect for Web Services Toolkit.  Co-Author of UDDI V1 specification.  Technical Chair/Track Chair for the XML Web Services One Conferences.  OASIS WS-Security TC, UDDI TC, SAML TC, WS-I Sample Apps WG  IBM technical lead for UN/OASIS ebXML. © Toufic Boubez - Layer 7 Technologies 2
    • 24-10-2008 Drivers for SOA  Growth and increased productivity:  Inside the organization, EAI (Enterprise Application Integration) is essential for increased productivity;  Outside the organization, integration with partners is essential for growth.  Flexibility and agility:  Easily integrate disparate internal and external resources and functionalities as needed;  Easily add and change integrations with business partners;  Easily add and change IT platforms – avoid vendor lock-in;  Runtime Configurable Models.  Just-in-time integration as required:  Loose coupling as a fundamental architectural principle. © Toufic Boubez - Layer 7 Technologies Scenario: Fluid Communities Of Interest Situation 1 Organization A Organization B Organization C Situation 2 © Toufic Boubez - Layer 7 Technologies 3
    • 24-10-2008 Issues: Runtime Constraints and Capabilities Situation 1 Organization A Organization B Identity Transport Trust API/Syntax Security Description Platform Discovery Auth/Auth Semantics Availability Context Response Organization C © Toufic Boubez - Layer 7 Technologies Theory vs. Practice  Web Services technology will solve these problems (will it?)  In theory, theory and practice are the same.  In practice, they're not!  Two major issues:  All kidding aside, why would I expose my backend systems on the Web? Security, Privacy, Reliability … anyone? anyone?  So, whatever happened to loose coupling? © Toufic Boubez - Layer 7 Technologies 4
    • 24-10-2008 Dealing with Security © Toufic Boubez - Layer 7 Technologies Fundamentals of Security ISO 7498-2, 10181 © Layer 7 Technologies 5
    • 24-10-2008 The Present: Essential Security Requirements for SOA  SOA brings new requirements:  Messages may pass through multiple transports/hops  Can’t rely on transport security  Can’t rely on socket continuity  At any intermediary, certain parts of the message may need to be processed  Only encrypt what we need to support the security policy Web Services Security © Layer 7 Technologies 11 The Present: New Security Model for SOA  SOA necessitates a new security model:  Need to decouple security from transport  Need to include security information in the message:  Credentials or tokens for AuthN/AuthZ  Encryption of message parts  Signing of message parts Web Services Security © Layer 7 Technologies 12 6
    • 24-10-2008 WS-Security  The security architecture for Web services  Defines SOAP security headers:  Tokens:  Binary Tokens (X.509)  Username, SAML, Kerberos  Encryption of message whole or parts  Signing of message whole or parts  Unifying standard that brings together a number of standards efforts, defining how they are to be used in SOAP messaging  Eg: W3C XML encryption, c14n, and digital signatures, OASIS SAML, etc. © Toufic Boubez - Layer 7 Technologies <SOAP-ENV:Envelope> <SOAP-ENV:Header> <wsse:Security> <wsu:TimeStamp> Web Service Server Certificate <wsse:BinarySecurityToken> <xenc:EncryptedKey> Reference <ds:KeyInfo> Encrypt <xenc:EncryptedData> <xenc:DataReference> Web Service Client Certificate <ds:Signature> Copy of <ds:Reference> <ds:Reference> Sign <ds:KeyInfo> <SOAP-ENV:Body> <xenc:EncryptedData> © Toufic Boubez - Layer 7 Technologies 7
    • 24-10-2008 What’s Next: Dealing with Identity and Trust What’s Missing From WS-Security?  We now have a basic mechanism to secure SOAP messages on a one-by-one basis.  Key questions:  Where do the tokens come from?  What if I don’t want to propagate identities?  What I need additional information to make authorization decisions?  What if the message exchange pattern requires more than one request and response pair?  Missing:  Portable identity, entitlements, attributes  Trust, federation, token distribution  Sessions © Toufic Boubez - Layer 7 Technologies 8
    • 24-10-2008 The Two Sides of SOA  SOA brings new challenges:  The combination of loose coupling and distributed resources, both fundamental SOA tenets, are a double edged sword – along with the potential for much greater IT flexibility and business agility, they bring the potential for harder oversight.  New regulatory environment that requires much more stringent oversight, monitoring and enforcement of corporate and IT governance policies:  SOX, HIPAA, etc.  Cross industries: Financial, Health, etc.  Non-compliance is expensive; also involves personal responsibility for executives. © Toufic Boubez - Layer 7 Technologies Identity Requirements for Policy Compliance Monitoring  Identity: Who?  can access information;  has accessed information;  owns information;  is subject of information;  has performed action.  Audit:  Identity-based audit trail.  Policy:  Framework of identity centric corporate security and privacy rules.  Trust:  How to establish loosely coupled trust between disparate organizations? © Toufic Boubez - Layer 7 Technologies 9
    • 24-10-2008 The Federation Challenge in Web Services Islands of Blue’s Server Identity Blue’s Directory Green’s Server Directory Server Firewall Green’s Client Alex Scott Francis Organization Blue Need to share not only Michelle authentication and authorization Dimitri Organization information, but also identity Program Green attribute information X Big privacy and confidentiality issues… © Toufic Boubez - Layer 7 Technologies What Hasn’t Worked in the Past Issues • Online access through firewall mazes • Latency in replication • People leave, fired, etc Blue’s Directory Green’s Server Remote Directory Directory Server Firewall Access Organization Blue Directory Synchronization Michelle Dimitri Organization Program Green X © Toufic Boubez - Layer 7 Technologies 10
    • 24-10-2008 What We Really Need is Effective Separation of Concerns Authentication Blue’s Directory Green’s Server Directory Server Authorization Trust Organization Blue Core Requirements Michelle • Build dynamic trust relationships Dimitri • Transport the security context so that Organization authentication and authorization can be Program Green X distributed • Enforce privacy issues • Time out sessions/global logout © Toufic Boubez - Layer 7 Technologies The Mechanism: Global Trust of Local Tokens Blue’s Directory Green’s Server Identity Server Trust 2. Validate token here according to trust model Michelle Dimitri 1. Acquire trusted token with Program statement of authentication (and X possibly authorization, entitlements, attributes) in this security domain © Toufic Boubez - Layer 7 Technologies 11
    • 24-10-2008 The Standards: SAML, WS-Trust, WS-SecureConversation Next Steps in SOA Security  Portable, canonical assertions:  SAML  Token distribution:  WS-Trust  Sessions:  WS-SecureConversation © Toufic Boubez - Layer 7 Technologies 12
    • 24-10-2008 What is SAML?  Security Assertion Markup Language  “XML standard for exchanging authentication and authorization data between security domains” (Wikipedia)  Cross-platform, XML-based, vendor-neutral standards for:  Single Sign-On  Issuing and communicating trusted identity claims and associated proofs  Really multiple standards, assertions and various protocols and profiles © Toufic Boubez - Layer 7 Technologies SAML Assertions: What’s inside?  A SAML assertion can have:  Subject: who am I talking to (or about)?  Authentication Statements: how was the Subject authenticated?  Attribute Statements: what attributes does the Subject have?  Authorization Decision Statements: what is the Subject permitted to do?  Signature: who is making the statements about the Subject, and how can you decide whether to trust them?  Unfortunately they're all optional, but in practice SAML Assertions will conform fairly closely to a few stereotypes. © Toufic Boubez - Layer 7 Technologies 13
    • 24-10-2008 What is WS-Trust?  Specifies an abstract protocol for exchanging security tokens with a Security Token Service (STS)  Some examples of security tokens:  UsernameTokens (login plus password or digest)  SAML Assertions  Encrypted symmetric keys (or partial keys)  Security Context Tokens (WS-SecureConversation sessions)  WS-Trust itself provides no concrete examples; use cases have come from:  Informal but widespread consensus:  Issuing SAML Assertions  Other standards efforts:  WS-SecureConversation / WS-SecureExchange © Toufic Boubez - Layer 7 Technologies WS-Trust and SAML: Typical Use Case  Requester sends UsernameToken with username and password to Identity Provider STS in <RequestSecurityToken> message.  STS authenticates credentials, issues signed SAML Assertion containing AuthenticationStatement, sends it back in <RequestSecurityTokenResponse>  Requester caches SAML Assertion, includes it in SOAP Security Header of outbound messages  Recipient verifies assertion signature, validates that signer is a trusted SAML issuer  SAML Assertion can be re-used until it expires © Toufic Boubez - Layer 7 Technologies 14
    • 24-10-2008 <SOAP-ENV:Envelope> <SOAP-ENV:Header> <SAML:Assertion> Statement 1 Issuing Authority … signature covers assertion and binds Statement n statements to Subject’s public key <SubjectConfirmation> <KeyInfo> <ds:Signature> Issuing Authority <ds:Signature> The key used in Subject’s signature Subject signs across the message body is the analogue Subject its message of the one bound into the assertion. <SOAP-ENV:BODY> © Toufic Boubez - Layer 7 Technologies The Mechanism: Global Trust of Local Tokens Blue’s Directory Green’s Server Identity Server SAML Trust SAML 2. Validate token here according to trust model Michelle Dimitri 1. Acquire trusted token with Program statement of authentication (and X possibly authorization, entitlements, attributes) in this security domain © Toufic Boubez - Layer 7 Technologies 15
    • 24-10-2008 WS-Trust: Typical Token Validation Request <soapenv:Envelope> <soapenv:Body> <wst:RequestSecurityToken> <wst:Base> Incoming token <wsse:UsernameToken> <wsse:Username>testuser</wsse:Username> <wsse:Password Type="...#PasswordText">pass</wsse:Password> </wsse:UsernameToken> </wst:Base> <wst:Issuer> <wsa:Address>http://myemployer.example.com/</wsa:Address> </wst:Issuer> Issuer of Incoming token <wsp:AppliesTo> <wsa:EndpointReference> <wsa:Address>http://samlpart.com/sso</wsa:Address> </wsa:EndpointReference> Scope of intended use </wsp:AppliesTo> <wst:RequestType>...Validate</wst:RequestType> </wst:RequestSecurityToken> </soapenv:Body> </soapenv:Envelope> What the STS should do with Incoming token © Toufic Boubez - Layer 7 Technologies WS-Trust: Typical Token Response <soapenv:Envelope> <soapenv:Body> <wst:RequestSecurityTokenResponse> <wst:RequestedSecurityToken> <saml:Assertion> <ds:Signature/> </saml:Assertion> </wst:RequestedSecurityToken> Returned Token <wst:RequestedTokenReference> <wss:KeyIdentifier ValueType="saml:Assertion"> Assertion-uuidd0dad954-0101-e072-018a-b935cd071747 </wss:KeyIdentifier> </wst:RequestedTokenReference> <wst:Status> <wst:Code>http://schemas.xmlsoap.org/ws/2004/04/security/trust/status/valid</w WS-Security plumbing st:Code> </wst:Status> </wst:RequestSecurityTokenResponse> </soapenv:Body> </soapenv:Envelope> © Toufic Boubez - Layer 7 Technologies 16
    • 24-10-2008 WS-SecureConversation  WS-Security provides security on a message by message basis.  Frequently, there is a need to exchange multiple messages between consumer and provider in a single conversation.  A Security Context is a convenient mechanism to provide a form of a session, without the need to generate new keys for every message.  WS-SC provides a mechanism to generate and exchange a SecurityContextToken.  The SCT can be used until it expires.  SCT’s are requested and issued through specific WS-Trust bindings. © Toufic Boubez - Layer 7 Technologies What About Loose Coupling? © Toufic Boubez - Layer 7 Technologies 17
    • 24-10-2008 The Potential of Web Services – A Governance Nightmare? SOAP over http SOAP over http XML encryption AD based ACL Digital Signature Text logging Guaranteed QoS Inventory getLevel Non-repudiation audit logging update Procurement SOAP over https LDAP based ACL Text logging order SOAP over http XML encryption Digital Signature Guaranteed QoS Non-repudiation audit logging © Toufic Boubez - Layer 7 Technologies How to Introduce Flexibility into a System  Software engineering principles:  Decouple the variable part of an implementation from the invariant part.  Invariant is the business functionality of the Web service  Variable is the layers of policy  Introduce flexibility into the system through the use of policies:  Decouple the policy part of Web services from the business logic part. © Toufic Boubez - Layer 7 Technologies 18
    • 24-10-2008 A Simple Analogy: Audio Systems  Monolithic, proprietary  RCA Jack: standard design interfaces and data format; component  Fixed architecture and design capabilities  Flexible architecture  Vulnerable to  Future-proof technology change  Vendor-neutral  Single-source vendor  Competition drives  Expensive prices down © Toufic Boubez - Layer 7 Technologies One Step Further: Professional Sound Systems  Abstract out input  Abstract out requester devices and output origination points and devices. provider endpoints.  Syndicate a variety of  Syndicate a variety of inputs to a variety of services to a variety outputs. of consumers.  Complete control over  Complete control over input and output provider and parameters. consumer policies. © Toufic Boubez - Layer 7 Technologies 19
    • 24-10-2008 From Business Drivers To Web Services: Reusable Components Framework Business Drivers (Inputs) -Revenue/Profit Web Services Business Services -Market share -getInventoryBySKU -Get Inventory Levels -Agility -getInventoryByPC -Inventory Updates -Forecasting Business Services Web Services Business Service Types -Get Customer Account -removeSKUItems -Inventory -Inventory Updates -addSKUItems -CRM -Forecasting -HR Web Services … -Accounting Business Services… -… Registry (MetaData) Reusable Business Components Framework © Toufic Boubez - Layer 7 Technologies Corporate And Architecture Drivers: Runtime Policy Framework Corporate Policy Drivers (Inputs) Corporate Architectural Drivers (Inputs) -Governance -Flexibility and Reuse -Compliance -Platform Independence -Security -Integration with existing infrastructure -Security, Scalability, Availability, Performance Security SLA Reliability -WS-Security -Response Time -WS-RM -X509TokenProfile -Availability Platform -SAMLTokenProfile -IP Range, ToD -Load Balancing -XML Encryption -Throughput Limits -WS-Addressing -XML Signatures -Non-repudiation Transport Threat Protection Message X-Form -HTTP -Schema Validation -Versioning -TLS -Virus Scanning -Localization -JMS -Attachments -DS (ACORD, FIX) Registry (MetaData) Runtime Policy Framework © Toufic Boubez - Layer 7 Technologies 20
    • 24-10-2008 Joining The Two Frameworks: Policy Driven SOA Reusable Business Components Framework Reusable Business Components Framework Managed Communications Infrastructure Runtime Policy Framework Runtime Policy Framework © Toufic Boubez - Layer 7 Technologies Decoupling Policy in Practice: The Policy Enforcement Point WSDL Document Policy Enforcement Point Policy Document Web Services Web Services Policy Provider Consumer Registry © Toufic Boubez - Layer 7 Technologies 21
    • 24-10-2008 Decoupling Policy in Practice: The Policy Application Point Policy WSDL Application Document Point Policy Conforming SOAP Policy Request Enforcement Point Policy Document Web Services Web Services Policy Provider Consumer Registry Signed Policy Document © Toufic Boubez - Layer 7 Technologies PEPs in the Architecture Firewalls (Perimeter PEPs) Service Service Service External Service Endpoint Endpoint Endpoint PEP PEP PEP External Service Centralized Intermediary Intermediary PEP PEP PEP External Service Endpoint Endpoint Endpoint DMZ PEP PEP PEP External Service Service Service Service Courtesy: Anne Thomas Manes, Burton Group © Toufic Boubez - Layer 7 Technologies 22
    • 24-10-2008 Main WS-Policy Specifications  WS-Policy  Assertion framework to describe requirements and capabilities of a service, e.g. transport bindings, QoS requirements, etc.  Sometimes known as WS-PolicyFramework.  WS-PolicyAssertions  A set of common message policy assertions related to language preferences, versioning and predicates.  WS-SecurityPolicy  Assertions, using the WS-Policy format, relevant to WS- Security.  Model for other types of WS-*Policy to be defined by interest groups.  WS-PolicyAttachment  How to associate policy assertions to Web services descriptions in WSDL and UDDI © Layer 7 Technologies WS-Policy Example <wsp:Policy xmlns:wsse="..." xmlns:wssx="..."> <wsp:ExactlyOne> <wsp:All wsp:Usage="wsp:Required"> <wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType> </wsse:SecurityToken> <wssx:Privacy /> </wsp:All> <wsp:All wsp:Usage="wsp:Required"> <wsse:SecurityToken> <wsse:TokenType>wsse:UsernameToken</wsse:TokenType> </wsse:SecurityToken> <wssx:Audit /> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> © Layer 7 Technologies 23
    • 24-10-2008 Conclusions  Security, Identity are becoming increasingly important as organizations move to SOA  Cross-domain, distributed services  Increased regulations  Move from transport-based to message-based security necessitates a new set of standards:  WS-Security  SAML  WS-Trust  WS-Policy  Loose coupling necessitates separating business logic from policy infrastructure:  The emergence of Policy Enforcement Points © Toufic Boubez - Layer 7 Technologies Some References on WS-*  WS-Security:  http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=wss  WS-SecureExchange (WS-SX):  http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=ws-sx  W3C WS-Policy Workgroup  http://www.w3.org/TR/WS-Policy/ "Policy-It's More Than Just Security“, T. Boubez, S. Morrison, M. Hondo, XML Journal  http://www.sys-con.com/xml/article.cfm?id=772 © Toufic Boubez - Layer 7 Technologies 24
    • 24-10-2008 Thanks!  Thank you very much for making it through!  Email questions or comments or presentation requests to:  tboubez@layer7tech.com © Toufic Boubez - Layer 7 Technologies 25