Your SlideShare is downloading. ×
0
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Lecture13
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lecture13

590

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
590
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Web Service Modeling Ontology Primer W3C Member Submission 3 June 2005 http://www.w3.org/Submission/WSMO-primer/#S21
  • The scenario we have
  • Digital signature technologies existed prior to XML Signature: PKCS#7 Signature (PKCS: a family of Public Key Cryptography Standard by RSA) With PKCS it was possible to sign an XML document, but: It was not possible to sign just part of an XML document It was not possible to represent the signature in a standardized XML format
  • X-KISS allows a client to delegate part or all of the tasks required to process XML Signature <ds:KeyInfo> elements to an XKMS service. A key objective of the protocol design is to minimize the complexity of applications using XML Signature. By becoming a client of the XKMS service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships (which may be based upon a different specification such as X.509/PKIX, SPKI or PGP).
  • Transcript

    • 1. Security for Web Services and Service Oriented Architectures Bhavani Thuraisingham The University of Texas at Dallas Lecture #13 February 18 and 20, 2008
    • 2. Acknowledgement <ul><li>Professors Elisa Bertino and Lorenzo Martino; Purdue University for much of the information and charts on web services security standards and digital identity management </li></ul><ul><ul><ul><li>[email_address] </li></ul></ul></ul><ul><ul><ul><li>[email_address] </li></ul></ul></ul><ul><li>Others: </li></ul><ul><ul><li>Dr. Frederica Pacci; University of Milan for ideas obtianed when serving on her thesis committee on reserach in web services security </li></ul></ul><ul><ul><li>Prof. I-Ling Yen and Wei-She; University of Texas at Dallas for collaboration on web services security and the delegation model </li></ul></ul><ul><ul><li>Book by Thomas Erl on Service Oriented Architectures, Prentice Hall, 2005 </li></ul></ul>
    • 3. Objective and Scope <ul><li>The objective of this course is to provide an overview of the significant developments in SOA and Web Services Security Standards as well as directions for future developments </li></ul><ul><li>Current work on SOA security is focusing mainly on access control as well as confidentiality and integrity. </li></ul><ul><li>Solutions proposed for systems to address intrusion detection, denial of service and infrastructure attacks, insider threat analysis including data mining techniques for security applications are beyond the scope of this course. </li></ul>
    • 4. Outline <ul><li>SOA and Web services: Overview </li></ul><ul><li>SOA and Web services security: Overview </li></ul><ul><li>WS-Security and WS-* Security </li></ul>
    • 5. Service Oriented Architecture (SOA) http://en.wikipedia.org/wiki/Service-oriented_architecture <ul><li>Service Oriented Architecture ( SOA ) is an architectural style that guides all aspects of creating and using business processes, packaged as services , throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications </li></ul><ul><li>SOA represents a model in which functionality is decomposed into distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications </li></ul><ul><li>These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </li></ul><ul><li>SOA concepts makes software development flexible and extensible </li></ul><ul><li>Service oriented analysis is becoming key to modeling and analyzing software </li></ul><ul><li>The concepts of Service Oriented Architecture are often seen as built upon, and the evolution of, the older concepts of distributed computing and modular programming </li></ul><ul><li>While object-orientation views the world as a collection of objects, service orientation views the world as a collection of services </li></ul><ul><li>SOA is technology independent; however it is commonly realized using web services </li></ul>
    • 6. Web service definition <ul><li>“ A Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” </li></ul><ul><li>Source: http://www.w3.org/TR/ws-arch/ </li></ul>
    • 7. SOA Service requestor Service providers UDDI Publish Services Query Request Answer Response
    • 8. Web Services (WS) Framework <ul><li>An abstract (vendor neutral) existence defined by standards organizations and implemented by ( proprietary) technology platforms </li></ul><ul><li>Core building blocks that include web sercices, service descriptions and messages </li></ul><ul><li>A communication agreement centered around service descriptions and WSDL </li></ul><ul><li>A messaging framework comprised of SOAP technology concepts </li></ul><ul><li>A service description registration and discovery architecture sometimes realized through UDDI </li></ul><ul><li>A well defined architecture that supports messaging patterns and compositions </li></ul><ul><li>A second generation of web services extensions ( also known as WS-* specifications ) continually broadening its underlying feature-set </li></ul><ul><li>Concepts in WS-* include: Message Exchange Patterns (MEP), Service Activity, Coordination, Atomic Transaction, Business Activities, Orchestration (WS-BPEL), Choreography (WS-CDL) </li></ul><ul><li>Reference: Service Oriented Architecture, Thomas Erl, Prentice Hall, 2005 </li></ul>
    • 9. Web services &amp; E-business <ul><li> Web services are a key component for agile e-business </li></ul> Web services security is a fundamental issue In tra -Enterprise Co-operation Enterprise Resource Planning Collaborative Business Stable C collaborate ive processes Distributed Processes (inhouse) Single Database Virtual Enterprise Transient C collaborate ive processes
    • 10. Standardization bodies related to Web Services
    • 11. SOA Security <ul><li>Our approach is to implement SOA through web services; therefore SOA security essentially is about web services security </li></ul><ul><li>Three core specifications </li></ul><ul><ul><li>WS-Security , XML-Signature, XML-Encryption </li></ul></ul><ul><ul><li>WS*-Security is the second generation of technologies for SOA security </li></ul></ul><ul><li>Single sign-on (SSO) is a form of centralized security mechanism that complements the WS-Security extensions </li></ul><ul><li>Related specifications for SOA security </li></ul><ul><ul><li>WS-Security, WS-SecurityPolicy, WS-Trust, WS-SecureConversation, WS-Federation, XACML, Extensibe Rights Markup Language, XML Key Management, XML, Signature, SAML, .NET Passport, Secure Socket Layer, WS-I Basic Security Profile </li></ul></ul>
    • 12. Basic Components of SOA Security <ul><li>Identification </li></ul><ul><ul><li>For service requestor to acces a secure service provider it must first provide information that expresses its origin or owner. This is referred to as making a claim </li></ul></ul><ul><li>Authentiaction </li></ul><ul><ul><li>A message being delivered to a receipient must prove that the message is in fact from the sender that it claims </li></ul></ul><ul><li>Authorization </li></ul><ul><ul><li>Once authenticated, the receipient of a message may need to determine what the requestor is alowed to do </li></ul></ul><ul><li>Singe sign on </li></ul><ul><ul><li>It is supported by SAML, . NET Passport and XACML </li></ul></ul><ul><li>Confidentiality and Integrity </li></ul><ul><ul><li>Confidentiality is concerned with protecting the privacy of the message content, Integrity ensures that the message has not been altered </li></ul></ul><ul><li>Transport level and Message level security </li></ul><ul><ul><li>Transport level securiy is provided by SSL (securing HTTP), message level confidentiality and integrity are provied by XML-Encryption and XML-Signature. </li></ul></ul>
    • 13. Web Services Security: Requirements and Standards <ul><li>Securing Web services mainly requires to: </li></ul><ul><ul><li>provide facilities for securing the integrity and confidentiality of the messages and </li></ul></ul><ul><ul><li>ensure that the service acts only on requests in messages that express the claims required by policies </li></ul></ul><ul><li>Role of Standards </li></ul><ul><ul><li>Providing a Web Services Security Framework that is an integral part of the Web Services Architecture </li></ul></ul><ul><ul><li>The framework is a layered and composable set of standard specifications </li></ul></ul>
    • 14. WS-* security Standards framework
    • 15. WS-* security standards implementations <ul><li>Microsoft .NET Framework 2.0 / WSE3.0 </li></ul><ul><ul><li>WS-Security (OASIS 2004 standard), WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation and WS-Addressing </li></ul></ul><ul><li>SUN Web Services Interoperability Technology (WSIT) </li></ul><ul><li>IBM WebSphere </li></ul><ul><li>Open Software: The Apache Software Foundation Web Services Project ( http://ws.apache.org/) </li></ul>
    • 16. Securing the network traffic: SSL/TLS and IPsec <ul><li>Secure Socket Layer SSL and Transport Layer Security are used to provide transport level security for web services applications. </li></ul><ul><ul><li>Security features: </li></ul></ul><ul><ul><ul><li>authentication </li></ul></ul></ul><ul><ul><ul><li>data integrity </li></ul></ul></ul><ul><ul><ul><li>data confidentiality </li></ul></ul></ul><ul><li>SSL/TLS enables point-to-point secure sessions. </li></ul><ul><li>IP security (IPsec) security features </li></ul><ul><ul><li>secure sessions with host authentication </li></ul></ul><ul><ul><li>data integrity </li></ul></ul><ul><ul><li>data confidentiality </li></ul></ul>
    • 17. IPSec security services <ul><li>IPsec provides the following security services: </li></ul><ul><ul><li>Encrypting traffic (so that it can not be read in its transmission) </li></ul></ul><ul><ul><li>Integrity validation (ensuring that traffic has not been modified along its path) </li></ul></ul><ul><ul><li>Authenticating the Peers (both ends are sure they are communicating with the trusted entity the traffic is intended for) </li></ul></ul><ul><ul><li>Anti-Replay (Protect against session replay) </li></ul></ul><ul><li>Network level security policies </li></ul><ul><ul><li>Firewall filtering rules </li></ul></ul><ul><ul><li>IPsec Security policy: </li></ul></ul><ul><ul><ul><li>The manager defines policies describing the security services that must be enforced on a given traffic </li></ul></ul></ul><ul><ul><ul><li>Each policy describes the action(s) and the mode, algorithms and protocols to apply when an IPsec processing is required </li></ul></ul></ul>
    • 18. XML Encryption <ul><li>XML Encryption Syntax and Processing </li></ul><ul><li>10 December 2002 </li></ul><ul><li>Status W3C Recommendation </li></ul><ul><li>Core standard </li></ul><ul><li>Goals: </li></ul><ul><li>provide confidentiality for applications that exchange structured data by </li></ul><ul><ul><li>Representing in a standard way digitally encrypted resources </li></ul></ul><ul><ul><li>separating encryption information from encrypted data, and supporting reference mechanisms for addressing encryption information from encrypted data sections and vice-versa </li></ul></ul><ul><ul><li>providing a mechanism for conveying encryption key information to a recipient </li></ul></ul><ul><ul><li>providing for the encryption of a part or totality of an XML document </li></ul></ul>
    • 19. XML Signature <ul><li>XML-Signature Syntax and Processing </li></ul><ul><li>12 February 2002 </li></ul><ul><li>Status: W3C Recommendation </li></ul><ul><li>Core standard: XML Signature is a building block for many web services security standards (e.g. XKMS and WS-Security) </li></ul><ul><li>Goals: </li></ul><ul><ul><li>represent a digital signature as an XML element </li></ul></ul><ul><ul><li>Processing rules for creating this XML element </li></ul></ul><ul><ul><li>The signed data items can be of different types and granularity (XML documents, XML Elements, files containing any type of digital data) </li></ul></ul>
    • 20. Securing SOAP messages Web Services Security: SOAP Message Security 1.1 (WS-Security 2004) Status: Approved OASIS Standard Specification 1 February 2006 <ul><li>Goals: </li></ul><ul><ul><li>Provide single SOAP message integrity and confidentiality </li></ul></ul><ul><ul><ul><li>Using existing digital signature, encryption, and security token mechanisms </li></ul></ul></ul><ul><ul><li>Provide mechanisms for associating security tokens with message content (header and body blocks) </li></ul></ul><ul><ul><li>Extensibility (i.e. support multiple security token format) </li></ul></ul>the recipient can trust the content of the message and its sender <ul><li>Security Token - a representation of security-related information (e.g. X.509 certificate, Kerberos tickets and authenticators, mobile device security tokens from SIM cards, username, etc.). </li></ul><ul><li>Signed Security Token - a security token that contains a set of related claims (assertions) cryptographically endorsed by an issuer. </li></ul><ul><ul><li>Examples: X.509 certificates and Kerberos tickets. </li></ul></ul>
    • 21. What is WS-Security? <ul><li>WS-Security enhances SOAP messaging to provide quality of protection through: </li></ul><ul><ul><li>message integrity, </li></ul></ul><ul><ul><li>message confidentiality, and </li></ul></ul><ul><ul><li>single message authentication. </li></ul></ul><ul><li>These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. </li></ul><ul><li>WS-Security also provides a general-purpose, extensible mechanism for associating security tokens with messages: </li></ul><ul><ul><li>No specific type of security token is required </li></ul></ul><ul><ul><li>support for multiple security token formats </li></ul></ul><ul><li>WS-Security describes how to encode binary security tokens( X.509 certificates and Kerberos tickets) </li></ul>
    • 22. WS-Security mechanisms and considerations <ul><li>Mechanism(s) </li></ul><ul><ul><li>Mechanisms for message integrity: digital signatures and certificates </li></ul></ul><ul><ul><li>Mechanism for confidentiality: encryption (XML Encryption) </li></ul></ul><ul><li>Digital signatures alone do not provide message authentication. To prevent replay attack (one can record a signed message and resend it), digital signatures must be combined with timestamps or sequence numbers to ensure the uniqueness of the message. </li></ul><ul><li>When digital signatures are used for verifying the identity of the sending party, the sender must prove the possession of the private key. One way to achieve this is to use a challenge-response type of protocol. </li></ul><ul><li>The combination of signing and encryption over a common data item may introduce some cryptographic vulnerability: </li></ul><ul><ul><li>For example, encrypting digitally signed data, while leaving the digital signature in the clear, may allow plain text guessing attacks </li></ul></ul>
    • 23. WS-Security request example 1 &lt;soap:Envelope&gt; 2 &lt;soap:Header&gt; 3 &lt;ws:Security&gt; 4 &lt;ws:BinarySecurityToken id=&amp;quot;X509token&amp;quot; ValueType=&amp;quot;X.509&amp;quot;&gt; 5 sdfOIDFKLSoidefsdflk … 6 &lt;/ws:BinarySecurityToken&gt; 7 &lt;ds:Signature&gt; 8 &lt;ds:Reference&gt; 9 &lt;ds:Ref URI=&amp;quot;#PO&amp;quot;/&gt; 10 &lt;/ds:Reference&gt; 11 &lt;ds:SignatureValue&gt;akjsdflaksf&lt;/ds:SignatureValue&gt; 12 &lt;ds:KeyInfo&gt; 13 &lt;ws:BinarySecurityTokenReference URI=&amp;quot;#X509token&amp;quot;/&gt; 14 &lt;/ds:KeyInfo&gt; 15 &lt;/ds:Signature&gt; 16 &lt;/ws:Security&gt; 17 &lt;/soap:Header&gt; 18 &lt;soap:Body&gt; 19 &lt;po:PurchaseOrder ID=&amp;quot;PO&amp;quot;/&gt; 20 &lt;/soap:Body&gt; 21 &lt;/soap:Envelope&gt;
    • 24. WS-SecureConversation <ul><li>Conversations focus on the public processes in which the participants of a Web service engage; WSCL is Web Services Conversation Language. </li></ul><ul><li>Web Services Secure Conversation Language (WS-SecureConversation) February 2005 </li></ul><ul><ul><li>Status: revised public draft release provided for review and evaluation only </li></ul></ul><ul><li>Main goal: provide secure communication across one or more messages. </li></ul><ul><ul><li>Extends WS-Security mechanisms </li></ul></ul><ul><ul><li>Allows to authenticate a series of SOAP messages (conversation) </li></ul></ul><ul><ul><ul><li>by establishing and sharing between two endpoints a security context for a message conversation using a series of derived keys to increase security. </li></ul></ul></ul><ul><li>The security context is defined as a new token type that is obtained using a binding of WS-Trust </li></ul><ul><ul><li>This allows for exchange in a potentially more efficient way keys or new key material </li></ul></ul><ul><li>Security Context </li></ul><ul><ul><li>A security context is an abstract concept that refers to an established authentication state and negotiated key(s) that may have additional security-related properties. </li></ul></ul><ul><ul><li>A security context token (SCT) is a representation of that security context abstract concept, which allows a context to be named by a URI and used with WS-Security. </li></ul></ul>
    • 25. Security policies for Web Services <ul><li>The concept of Policy: Guiding principles and procedures </li></ul><ul><li>Security policy might mean different things to different people: </li></ul><ul><ul><li>Firewall filtering rules </li></ul></ul><ul><ul><li>Access control policy </li></ul></ul><ul><ul><li>Privacy policy </li></ul></ul><ul><li>Standards for Web Services Policies </li></ul><ul><ul><li>WS-Policy </li></ul></ul><ul><ul><li>XACML </li></ul></ul><ul><ul><li>XACML profile for Web Services </li></ul></ul><ul><ul><li>Approaches: “specialized” models &amp; languages vs. one-size-fits-all framework </li></ul></ul>
    • 26. WS-Policy <ul><li>Web Services Policy 1.2 - Framework (WS-Policy) W3C Member Submission 25 April 2006 </li></ul><ul><li>Status : public draft release for review and evaluation only </li></ul><ul><li>Main goal : The WS-Policy and WS-PolicyAttachment aim to offer mechanisms to represent the capabilities and requirements of Web services as Policies </li></ul><ul><li>Policy view in WS-Policy : </li></ul><ul><ul><li>A policy is used to convey conditions on an interaction between two Web service endpoints. </li></ul></ul><ul><ul><li>The provider of a Web service exposes a policy to convey conditions under which it provides the service. </li></ul></ul><ul><ul><li>A requester might use this policy to decide whether or not to use the service. </li></ul></ul>
    • 27. WS-Policy <ul><li>WS-Policy: </li></ul><ul><ul><li>is an extensible model for expressing all types of domain-specific policy models: transport-level security, resource usage policy, even end-to-end business-process level policy. It Define basic policy, policy statement, and policy assertion models. WSPolicy is also able to incorporate other policy models such as SAML and XACML </li></ul></ul><ul><li>WS-PolicyAssertions: </li></ul><ul><ul><li>Defines a few generic policy assertions </li></ul></ul><ul><li>WS-Policy Attachment: </li></ul><ul><ul><li>Defines how to associate a policy with a service, either by directly embedding it in the WSDL definition or by indirectly associating it through UDDI </li></ul></ul><ul><li>WS-SecurityPolicy: </li></ul><ul><ul><li>Defines security policy assertions corresponding to the security claims defined by WS-Security: message integrity assertion, message confidentiality assertion, and message security token assertion </li></ul></ul><ul><li>The only policy assertions standardized so far are those defined in WS-SecurityPolicy (specific assertions that describe how messages are secured) and WS-PolicyAssertions. </li></ul>
    • 28. WS-Policy: Policy model <ul><li>Policy : </li></ul><ul><ul><li>A potentially empty collection of policy alternatives. Alternatives are not ordered </li></ul></ul><ul><li>Policy Alternative: </li></ul><ul><ul><li>A potentially empty collection of policy assertions. </li></ul></ul><ul><ul><li>An alternative with zero assertions indicates no behaviors.. </li></ul></ul><ul><ul><li>Alternatives are mutually exclusive (exclusive OR) </li></ul></ul><ul><li>Policy Assertion: </li></ul><ul><ul><li>Identifies a a requirement (or capability) of a policy subject. </li></ul></ul><ul><ul><li>Assertions indicate domain-specific (e.g., security, transactions) semantics and are expected to be defined in separate, domain-specific specifications </li></ul></ul>
    • 29. WS-Policy example &lt;wsp:Policy&gt; &lt;wsp:ExactlyOne&gt; &lt;wsse:SecurityToken&gt; &lt;wsse:TokenType&gt;wsse:Kerberosv5TGT &lt;/wsse:TokenType&gt; &lt;/wsse:SecurityToken&gt; &lt;wsse:SecurityToken&gt; &lt;wsse:TokenType&gt;wsse:X509v3 &lt;/wsse:TokenType&gt; &lt;/wsse:SecurityToken&gt; &lt;/wsp:ExactlyOne&gt; &lt;/wsp:Policy&gt; Which security token we want to use among the various tokens such as Kerberos and X509
    • 30. XACML <ul><li>eXtensible Access Control Markup Language 2 (XACML) Version 2.0 OASIS Standard, 1 Feb 2005 </li></ul><ul><li>Status : approved OASIS Standard within the OASIS Access 12 Control TC. </li></ul><ul><li>XACML is a general-purpose access control policy language for managing access to resources </li></ul><ul><li>It describes both a policy language and an access control decision request/response language </li></ul><ul><li>Fine access control grained control </li></ul><ul><li>Access control based on subject and object attributes </li></ul><ul><li>Consistent with and building upon SAML </li></ul>
    • 31. XACML – Key Aspects <ul><li>General-purpose authorization policy model and XML-based specification language </li></ul><ul><li>XACML is independent of SAML specification </li></ul><ul><li>Triple-based policy syntax: &lt;Object, Subject, Action&gt; </li></ul><ul><li>Negative authorization is supported </li></ul><ul><li>Input/output to the XACML policy processor is clearly defined as XACML context data structure </li></ul><ul><li>Input data is referred by XACML-specific attribute designator as well as XPath expression </li></ul><ul><li>Extension points: function, identifier, data type, rule-combining algorithm, policy-combining algorithm, etc. </li></ul><ul><li>A policy consists of multiple rules </li></ul><ul><li>A set of policies is combined by a higher level policy (PolicySet element) </li></ul>
    • 32. XACML data flow model Source: oasis-access_control-xacml-2.0-core-spec-os
    • 33. XACML Protocol XACML Request/ Response Policy Enforcement Point (PEP) Policy Decision Point (PDP) Policy Access Point (PAP) Policy Information Point (PIP)
    • 34. XACML Protocol <ul><li>When a client makes a resource request upon a server, the PEP is charged with AC </li></ul><ul><li>In order to enforce AC policies, the PEP will formalize the attributes describing the requester at the PIP and delegate the authorization decision to the PDP </li></ul><ul><li>Applicable policies are located in a policy store, managed by the PAP, and evaluated at the PDP, which then returns the authorization decision </li></ul><ul><li>Using this information, the PEP can deliver the appropriate response to the client </li></ul><ul><li>XACML Request </li></ul><ul><ul><li>Subject </li></ul></ul><ul><ul><li>Object </li></ul></ul><ul><ul><li>Action </li></ul></ul><ul><li>XACML Response </li></ul><ul><ul><li>Permit </li></ul></ul><ul><ul><li>Permit with Obligations </li></ul></ul><ul><ul><li>Deny </li></ul></ul><ul><ul><li>NotApplicable (the PDP cannot locate a policy whose target matches the required resource) </li></ul></ul><ul><ul><li>Indeterminate (an error occurred or some required value was missing) </li></ul></ul>
    • 35. XACML Protocol <ul><li>The Policy Administration Point (PAP) creates security policies and stores these policies in the appropriate repository. </li></ul><ul><li>The Policy Enforcement Point (PEP) performs access control by making decision requests and enforcing authorization decisions. </li></ul><ul><li>The Policy Information Point (PIP) serves as the source of attribute values, or the data required for policy evaluation. </li></ul><ul><li>The Policy Decision Point (PDP) evaluates the applicable policy and renders an authorization decision. </li></ul><ul><li>Note: The PEP and PDP might both be contained within the same application, or might be distributed across different servers </li></ul>
    • 36. Policies and PolicySet <ul><li>The key top-level element is the &lt;PolicySet&gt; which aggregates other &lt;PolicySet&gt; elements or &lt;Policy&gt; elements </li></ul><ul><li>The &lt;Policy&gt; element is composed principally of &lt;Target&gt;, &lt;RuleSet&gt; and &lt;Obligation&gt; elements and is evaluated at the PDP to yield and access decision. </li></ul><ul><li>Since multiple policies may be found applicable to an access decision, (and since a single policy can contain multiple Rules) Combining Algorithms are used to reconcile multiple outcomes into a single decision </li></ul><ul><li>The &lt;Target&gt; element is used to associate a requested resource with an applicable Policy. It contains conditions that the requesting Subject, Resource, or Action must meet for a Policy Set, Policy, or Rule to be applicable to the resource. </li></ul><ul><li>The Target includes a build-in scheme for efficient indexing/lookup of Policies. </li></ul><ul><li>Rules provide the conditions which test the relevant attributes within a Policy. Any number of Rule elements may be used each of which generates a true or false outcome. Combining these outcomes yields a single decision for the Policy, which may be &amp;quot;Permit&amp;quot;, &amp;quot;Deny&amp;quot;, &amp;quot;Indeterminate&amp;quot;, or a &amp;quot;NotApplicable&amp;quot; decision. </li></ul>
    • 37. Policies and Policy Sets <ul><li>Policy </li></ul><ul><ul><li>Smallest element PDP can evaluate </li></ul></ul><ul><ul><li>Contains: Description, Defaults, Target, Rules, Obligations, Rule Combining Algorithm </li></ul></ul><ul><li>Policy Set </li></ul><ul><ul><li>Allows Policies and Policy Sets to be combined </li></ul></ul><ul><ul><li>Use not required </li></ul></ul><ul><ul><li>Contains: Description, Defaults, Target, Policies, Policy Sets, Policy References, Policy Set References, Obligations, Policy Combining Algorithm </li></ul></ul><ul><li>Combining Algorithms: Deny-overrides, Permit-overrides, First-applicable, Only-one-applicable </li></ul>
    • 38. Overview of the Policy Element &lt;Rule RuleId=“R2” Effect=“Deny”&gt; &lt;Target&gt; &lt;Resources&gt; &lt;Subjects&gt; &lt;Actions&gt; &lt;Condition&gt; &lt;/Rule&gt; &lt;Policy&gt; &lt;Target&gt; &lt;Resources&gt; &lt;Subjects&gt; &lt;Actions&gt; &lt;RuleSet ruleCombiningAlgId = “DenyOverrides”&gt; &lt;Rule ruleId=“R1”&gt; &lt;Rule ruleId=“R2”&gt; … &lt;Obligations&gt; &lt;RuleSet&gt; &lt;/Policy&gt; &lt;Rule RuleId=“R1” Effect=“Permit”&gt; &lt;Target&gt; &lt;Resources&gt; &lt;Subjects&gt; &lt;Actions&gt; &lt;Condition&gt; &lt;/Rule&gt;
    • 39. XACML policy <ul><li>A Policy has four main components: </li></ul><ul><ul><li>A target </li></ul></ul><ul><ul><li>A rule-combining algorithm identifier </li></ul></ul><ul><ul><li>A set of rules </li></ul></ul><ul><ul><li>Obligations </li></ul></ul><ul><li>The Rule is the elementary unit of a policy </li></ul><ul><li>Main components of a rule: </li></ul><ul><ul><li>A target </li></ul></ul><ul><ul><li>An effect: permit or deny </li></ul></ul><ul><ul><li>A condition </li></ul></ul><ul><li>Policy Language </li></ul><ul><ul><li>A policy target specifies a set of: </li></ul></ul><ul><ul><ul><li>Resources </li></ul></ul></ul><ul><ul><ul><li>Subjects </li></ul></ul></ul><ul><ul><ul><li>Actions </li></ul></ul></ul><ul><ul><ul><li>Environment </li></ul></ul></ul><ul><ul><li>to which it applies </li></ul></ul>
    • 40. XACML Profile for Web-Services <ul><li>OASIS XACML Profile for Web-Services XACML Working draft 04, 29 Sep 2003 </li></ul><ul><li>Status : working draft </li></ul><ul><li>Main goal : extending XACML to deal with the specific characteristics of Web services </li></ul><ul><li>Two main extensions to XACML: </li></ul><ul><ul><li>define in a precise way the various aspects to which a security policy applies to, for example for distinguishing the security policy that must be applied to the message level from the access control policy applied to a Web service or to an operation of the Web service </li></ul></ul><ul><ul><li>use of the policy combination mechanisms defined in XACML in order to combine the preference/requirements policy of the Web service client with the access control policy of the Web service provider </li></ul></ul><ul><li>Note: XACML profile is not getting as much attention as it used to </li></ul>
    • 41. Security Assertion Markup Language (SAML) <ul><li>Developed by the OASIS XML-Based Security Services Technical Committee (SSTC) </li></ul><ul><li>Status : SAML V2.0 OASIS Standard specification set was approved on 15 March 2005 </li></ul><ul><li>Main goal : authentication and authorization </li></ul><ul><ul><li>promote interoperability between disparate authentication and authorization systems </li></ul></ul><ul><li>How: </li></ul><ul><ul><li>defining an XML-based framework for communicating security and identity information (e.g., authentication, entitlements, and attribute) between computing entities </li></ul></ul><ul><ul><li>using available different security infrastructures (e.g., PKI, Kerberos, LDAP, etc) </li></ul></ul>
    • 42. SAML basic concepts <ul><li>Assertions: The core concept </li></ul><ul><li>SAML Authority : a system entity that makes SAML assertions (also called Identity Provider – IdP – and Asserting Party ) </li></ul><ul><li>Service Provider : a system entity making use of SAML assertions </li></ul><ul><li>Relying Party : a system entity that uses received assertions (named also SAML requester) </li></ul><ul><li>SAML Bindings: Bindings describe exactly how the SAML protocol maps onto the transport protocols. </li></ul>
    • 43. SAML assertions <ul><li>An assertion is constituted by one or more statements made by a SAML authority </li></ul><ul><li>Different kinds of assertion statement that can be created by a SAML authority: </li></ul><ul><ul><li>Authentication: The specified subject was authenticated by a particular means at a particular time. </li></ul></ul><ul><ul><li>Attribute: The specified subject is associated with the supplied attributes. </li></ul></ul><ul><ul><li>Authorization decision statements: the specified subject is entitled to do a specified action </li></ul></ul>“ Martino authenticated with a password at 9:00am” “ Bill is an account manager with a $1000 spending limit per one-day travel” “ John Doe” is permitted to buy a specified item
    • 44. SAML entities SAML Requester a system entity that uses received assertions Service Providers a system entity making use of SAML assertions SAML Authority makes SAML assertions
    • 45. SAML profiles <ul><li>Defines constraints and/or extensions of the core protocols and assertions in support of the usage of SAML for a particular application. </li></ul><ul><li>Achieve interoperability. </li></ul><ul><li>Stipulates how particular statements are communicated using appropriate protocol messages over specified bindings. </li></ul><ul><li>E.g. Web Browser SSO Profile specifies how SAML authentication assertions are communicated using the Authentication Query and Response messages over a number of different bindings in order to enable Single Sign-On for a browser user </li></ul><ul><li>By agreeing to support a particular SAML profile (as opposed to the complete specification set), parties who wish to exchange SAML messages have a much simpler job of achieving interoperability. </li></ul>
    • 46. SAML and XACML Source: Security Assertion Markup Language (SAML) V2.0 Technical Overview Working Draft 08, 12 September 2005
    • 47. SAML &amp; Federated Identity <ul><li>SAML addresses one key aspect of identity management: how identity information can be communicated from one domain to another </li></ul><ul><li>SAML 2.0 will be the basis on which Liberty Alliance builds additional federated identity applications (such as web service-enabled permissions-based attribute sharing). </li></ul>
    • 48. <ul><li>XML Key Management Specification (XKMS 2.0) Version 2.0 5 April 2004 </li></ul><ul><li>Status: W3C Candidate Recommendation </li></ul><ul><li>XKMS provides a Web-based interface to existing public key infrastructure (PKI) </li></ul><ul><li>XKMS specifies protocols for: </li></ul><ul><ul><li>Distributing </li></ul></ul><ul><ul><li>Registering public keys </li></ul></ul><ul><li>The protocol is suitable for use in conjunction with the standard for XML Signatures [XML-SIG] and companion standard for XML Encryption [XML-ENC]. </li></ul><ul><li>The XML Key Management Specification (XKMS) defines two services: </li></ul><ul><ul><li>the XML Key Information Service Specification (X-KISS) and </li></ul></ul><ul><ul><li>the XML Key Registration Service Specification (X-KRSS). </li></ul></ul>Standards for security management: XKMS (XML Key Management Standard)
    • 49. XKMS services XML Key Information Service (X-KISS) XML Key Registration Service (X-KRSS) BOB XKMS protocol <ul><ul><li>- locate a public key </li></ul></ul><ul><ul><li>- validate a public key </li></ul></ul><ul><ul><li>- register </li></ul></ul><ul><ul><li>- reissue </li></ul></ul><ul><ul><li>- revoke </li></ul></ul><ul><ul><li>- recover </li></ul></ul>ALICE
    • 50. Standards for security management: WS-TRUST <ul><li>Security (confidentiality &amp; integrity) is achieved through encryption, digital signatures and certificates </li></ul><ul><li>Ultimately, security depends on the secure management of cryptographic keys and security tokens: </li></ul><ul><ul><li>Key/security token issuance </li></ul></ul><ul><ul><li>Key/security token transmission </li></ul></ul><ul><ul><li>Key/security token storage </li></ul></ul><ul><ul><li>Key/security token exchange </li></ul></ul>
    • 51. WS-Trust <ul><li>Web Services Trust Language (WS-Trust) February 2005 </li></ul><ul><li>Status : Initial public draft release provided for review and evaluation only </li></ul><ul><li>Main goal : to enable the issuance and dissemination of credentials among different trust domains </li></ul><ul><li>WS-Trust defines extensions to WS-Security that provide: </li></ul><ul><ul><li>Methods for issuing, renewing, and validating security tokens. </li></ul></ul><ul><ul><li>Ways to establish, assess the presence of, and broker trust relationships. </li></ul></ul><ul><li>Motivation: The recipient of a WS-Security-protected SOAP message has three potential issues with the security token contained within the Security header: </li></ul><ul><ul><li>Format: the format or syntax of the token is not known to the recipient </li></ul></ul><ul><ul><li>Trust -- the recipient may be unable to build a chain-of-trust from its own trust anchors (e.g. its X.509 Certificate Authority, a local Kerberos KDC, or a SAML Authority) to the issuer or signer of the token </li></ul></ul><ul><ul><li>Namespace -- the recipient may be unable to directly comprehend the set of claims within the token because of syntactical differences </li></ul></ul>
    • 52. WS-Trust: trust model
    • 53. WS-Trust: example Firewall STS Service Client The Client uses X.509 certificate The Provider understands Kerberos certificate WS-Security SOAP msg NO previouos trust relationship  SOAP Gateway Provider Web service
    • 54. WS-* Security standards and security <ul><li>WS-* security standard specifications address interoperability aspects </li></ul><ul><li>Each standard specification provides a specific section describing security threats that are not addressed by that specification </li></ul><ul><li>When using implementations of the specifications, the above warnings must be carefully analyzed </li></ul>
    • 55. WS-* Security standards and interoperability <ul><li>Theory: </li></ul><ul><ul><li>The framework mandates for a layered approach </li></ul></ul><ul><ul><li>every upper layer standard could/should re-use and extend the specification of lower-layer standards. </li></ul></ul><ul><li>Practice: </li></ul><ul><ul><li>Specifications issued by different bodies are not always compatible, but </li></ul></ul><ul><ul><li>Adherence to profiles improves interoperability </li></ul></ul><ul><ul><li>Implementations of different vendors are not always interoperable </li></ul></ul>
    • 56. WS-* Security standards and performance <ul><li>XML induces overhead </li></ul><ul><li>Efficient ways of packaging and transmitting binary data in SOAP messages are needed: </li></ul><ul><ul><li>XML-binary Optimized Packaging (XOP) </li></ul></ul><ul><ul><li>SOAP Message Transmission Optimization Mechanism (MTOM) </li></ul></ul><ul><ul><li>Resource Representation SOAP Header Block (RRSHB) </li></ul></ul><ul><li>Processing of WS-* security compliant messages require encryption/decryption and eventually signature management capabilities </li></ul><ul><li>XML accelerators and the XML firewalls try to solve those problems </li></ul>
    • 57. XML Accelerators and Firewalls <ul><li>Accelerators: A customized hardware and software performing the following processing tasks: </li></ul><ul><ul><li>XML/SOAP parsing, </li></ul></ul><ul><ul><li>XML schema validation, </li></ul></ul><ul><ul><li>XPath processing and XSLT transformation functions </li></ul></ul><ul><li>Firewalls: Also known as XML gateways: </li></ul><ul><ul><li>Perform functions of a XML accelerator </li></ul></ul><ul><ul><li>Support WS-Security standard </li></ul></ul><ul><ul><li>Additional functionalities: </li></ul></ul><ul><ul><ul><li>content or metadata-based XML/SOAP filtering functions </li></ul></ul></ul><ul><ul><ul><li>XML messages encryption/decryption at the message or element level </li></ul></ul></ul><ul><ul><ul><li>XML signatures’ verification and XML message signing according to XML Encryption standard </li></ul></ul></ul><ul><ul><ul><li>Authentication and authorization functions (that in some XML appliance can be based on local or on off-board repositories) </li></ul></ul></ul>
    • 58. Summary Points <ul><li>SOA concept based on service orientation is now a significant method for software development and promotes extensibility and flexibility; Service oriented analysis has now become a standard way to model software </li></ul><ul><li>Web Services is just one way to realize SOA </li></ul><ul><li>Security for SOA is crucial as SOA is being used in numerous sectors; since web services realize SOA, web services security is critical </li></ul><ul><li>SOA and SOA Security Standards are being developed by W3C and OASIS; WS-Security, WS*-Security Framework, and XACML are some of the key standards </li></ul><ul><li>SOA security currently focuses mainly on access control. SOA-specific techniques to address intrusion detection, denial of service and insider threat analysis need attention </li></ul>
    • 59. Questions <ul><li>Describe in detail the various components of WS-Security </li></ul><ul><li>Describe in detail the various components of WS-* Security </li></ul><ul><li>Describe in detail the key points in SAML and XACML </li></ul><ul><li>Define a hypothetical application for assured information sharing among coalition partners (e.g., Army, Navy, Air Force; or Hospitals, Insurance companies and Doctors’ offices) </li></ul><ul><ul><li>Examine the interactions between the coalition (e.g., data flow, process flow) </li></ul></ul><ul><ul><li>Specify web services to implement the interactions </li></ul></ul><ul><ul><li>Specify sample policies using XACML and SAML for the coalition environment </li></ul></ul><ul><ul><li>Design a system for implementing the policies </li></ul></ul>
    • 60. Contact Information <ul><li>Dr. Bhavani Thuraisingham </li></ul><ul><li>Professor of Computer Science and Director of the Cyber Security Research Center </li></ul><ul><li>The University of Texas at Dallas </li></ul><ul><li>[email_address] </li></ul><ul><li>Dr. Elisa Bertino </li></ul><ul><li>Professor of Computer Science and Reserach Director, CERIAS </li></ul><ul><li>Purdue University </li></ul><ul><li>[email_address] </li></ul>

    ×