Last week XML-family XML-Encryption XML-Encryption

Last week…

XML-family

XML-Encryption

XML-Encryption

Objective

XML-Encryption structure

Resulting Schema shorthand ? ? ? ? ? ? ? ? ? ?

Web service security: Part 2

Combining XML-Encryption with XML-Signature

Example Enc & Sig 1: Protecting Integrity of (1/2) Encrypted. Data for SSNo. Ciphered SSNo. Key (1) info belonging to Ciphered SSNo. Encrypted. Data for Key Encrypted Key to decrypt Ciphered SSNo. Key (2) info belonging to Encrypted Key Signed info refers to Encrypted Data for SSNo. Digest of Encrypted. Data for SSNo. Signature of Signed. Info Key (3) info to verify Signature

Example Enc & Sig 1: Protecting Integrity of (2/2) Reasonable Statement Iff: z. Confident keys are associated with sender & recipient z. AND private keys are not compromised Then: “This document was prepared by David Remy and can only be read by Jothy Rosenberg”

Sf. E: however. . . z & are detached z can be removed without being noticed z can even be replaced: "Signed by David Copperfield" z Need Policy: If encrypted, then also signed z BTW: what's the order of processing ? ?

Example Enc & Sig 2: Encryption follows Signing (1/3) The original Order Birdcage Fred L Jones VISA 43343456343566 10/08

Example Enc & Sig 2: Encryption follows Signing (2/3) The Order, signed by David Remy Birdcage . . . . . . O= My. Company, OU=Engineering, CN=David Remy

Example Enc & Sig 2: Encryption follows Signing (3/3) The signed order, is element Encrypted Birdcage . . . . . . O=His. Company, OU=Technology, CN=Jothy Rosenberg

Ef. S: however. . . z ++ Signature, w/t sensitive data, invisible z ++ Clear order of processing z -- Integrity of Encrypted. Data isn’t guaranteed

In conclusion z. Order of processing Sf. E z. Security Model: Sf. E or Ef. S

Order of processing Sf. E z. Problem: What to do 1 st, Decrypt or Validate Signature z. Solution: additional 'Decrypt Transform' element for XML-Signature

Security Model: Sf. E or Ef. S z. Depends on context, the specific situation z. Specify a Policy z. Consider multi-layered approach Sf. Ef. S

Summary

XML-family

SAML

Identity

Significance of Identity z Questions focus around Identity: z Who sent me this z Who is accessing my confidential network / information? z How do I know it is z Who is this request really the sender? from? z. . . z Who sais this information is correct?

Establishing and using Identity: establishing Identity (1/2) Trusted Third Party TTP Subject Identity (indiv. /entity) Refer Credentials

Establishing and using Identity: using Identity (2/2) Portable Assertion Trusted Third Party TTP Assertion: “Presenting Credentials when Subject initiates action” Portable Assertion: “Presenting Credentials when Subject initiates action in other Trust Domain” Authentication: Subject is who she claims to be. Subject Verify: Credentials are legitimately in possession of Subject Identity Credentials Authorization: Subject is allowed to perform action. Verify: Action is allowed by Credentials (rights been established under Referhave responsible for action) control of authority Trust domain NL Trust domain HU

Problem

Solution: open federated identity model

Federated Identity: Credentials: “Who is this subject” Assertion Statement: “I vouch that this is van Gogh” Travel. Agency. com Credentials Subject Trust Domain 1 Auth. & make travel order Book flight Bo ok Orde flig r car Chosen. Airline. com ht SAML: 1. Communicates Assertions: • Deferred Identity Decisions 2. SAML Fundaments: • Assertions: XML Schema • Protocols: XML Schema for Request/response pairs • Bindings: Ass. s on transport & messaging standards (currently: SOAP@HTTP(s) ) Trust Domain 2 Chosen. Hotels. com Chosen. Rentals. com Trust Domain 4 Trust Domain 3

Summary

Where are we?

SOAP

Objective & Characteristics

Transport of XML data z Where XML defines the content of a message. . . z SOAP defines how that data moves from A to B z Via a number of standard transport protocols, but. . . z Extensible to future needs (protocols & standards, functionality) z SOAP is for web services. . . z. . what Internet Inter. ORB Protocol (IIOP) is for CORBA. . z. . . and RMI is for Java z Allows Sender & Receiver to support common transport protocol

Simple Object Access Protocol z. It isn't Simple zit doesn't deal with Objects z. It's got more to do with transport than Access zfrom version 1. 1: SOAP is no longer an acronym zsometimes: Service-Oriented Architecture (or Application) Protocol

Characteristics z. SOAP = XML derivative z. Hence character oriented z. Hence easier debugging (meta-data describing what is being passed) z. Hence firewall friendly z. Treat XML messages as service request z. Separation between infrastructure & application processing of messages

Supported transport protocols z. Number of Transport protocols = 1 z. Technically, spec supports expansion to others (UDP, SMTP, JMS, etc. ) z. Spec Formal binding to HTTP

Structure

Provide transport envelope z Envelope = container to hold XML Data z Uniform container, then be carried by variety of transports z Applications refer to content z Transport refers to envelope

SOAP Header z. Information about SOAP envelope z. Manage the package z. Extensibility is located here z. SOAP Security (extensions) lives here

SOAP Body z. Information about SOAP Content z. Containts the message payload, i. e. XML Data z. Anything: full purchase order doc, RPC inc. method & parameters

SOAP binding & encoding z Binding Style : : z How to bind XMLelements on physical remote methods & parameters z Binding style: RPC versus Document z RPC/Encoded: remote invocated procedures, synchronous, design-time binding z Encoding Type : : z How to encode original objects: Serialization of original object onto hierarchical XMLstructure z Encoding type: SOAP encoded versus Literal z Document/Literal: document processing, asynchronous, run-time binding

SOAP processing z. SOAP Processors are part of application servers z. SOAP runtime system acts upon Headers & Bodies z. SOAP intermediaries act only upon Headers z. Security: authenticate identities, encrypt or decrypt, validate signatures & call-out TTP authorities, . . .

WS-Security

WS-Security

Objective

contrasts (& complements) transport-based security z Secure pipe between 2 directly connected endpoints z Endpoints usually Application Server z Secure IN the pipe, not outside z What about, for instance, logging? z Comparing Transport vs Message based security

Comparing Transport vs Message based security z Transport based: z. . . Point-to-point z. . . Mature, straightforward impl. z. . . Not granular: entire payload, entire session z. . . transport dependent z Message based: z. . . End-to-intermediary-to -end z. . . new, relatively complex, many options z. . . Very granular: part of payload, single message z. . . Transport independent

Characteristics z. As flexible as XML z. Each message carries own security strategy z. Flexibility is strength AND weakness z. WS-Security = SOAP security z. WS-Security = part of Web Service Security framework

WS-Security structure

WS-Security: What does it do? z. Takes XML Security (XML-Enc & XML-Sig) z. Links that with tokens (X 509, Kerberos, SAML) z. Binds that to SOAP z. Doing so, defines SOAP security header

Doing so, defines SOAP security header z. Security Tokens z. XML-Encryption z. XML-Signature

3 Building blocks z (1/3) Security Tokens z (2/3) XML-Encryption z (3/3) XML-Signature

(1/3) Security Tokens z. Information used for authentication & authorization (i. e. username / password, X. 509 Certificate, . . . ) z z z

z z in clear (over SSL) -> Don't! z Use Password. Type = Password. Digest instead: z. . . Time stamp z. . . Nonce z. . . Password Hash z. . . Requires clear-text password on both sides

z. Support few classes of binary credentials z. X. 509 certificates z. . . needs Signature proving possession Priv. Key z. Kerberos tickets

zn XML token = n wrapping top-elements z. SAML Assertion: ze. Xtensible Rights Markup Language (Xr. ML) z. XML Common Biometric Format (XCBF) z. . . and new tokens will be developed

WS-Security: Security. Tokens in SOAP Username / password

SAML Assertion: z Goal is to confirm that: z. . . sender, or z. . . third party, vouching for the sender, z. . . has proof of sender's identity z Hence: or

(2/3) XML-Encryption z Hide selective information in SOAP messages z Security header holds element z containing pointing to specific message parts z Encrypted attachments: SOAP w/t Attachments (Sw. A) not yet recommendation status z Example: Wrapped Symmetrical Key XML Encryption

(3/3) XML-Signature z. Goal 1: To provide message integrity z. Goal 2: To verify a security token credential

Goal 1: To provide message integrity Username / password

Goal 2: To verify a security token credential z Reminder: Signature. Value is calulated over block z. . . containing and. . . z. . . Digest of reference. z Problem: that is always rather than token itself z WS-Security therefore will follow token reference ("STR Dereference Transform" strategy)

Summary

Summary

Where are we?

Web Service Security framework

Foundation: WS-Security z XML-Signature z XML-Encryption z SAML-Assertions z Binds to SOAP: secure interaction z Secure XML leftovers

Secure XML leftovers z. XKMS z. XACML z. Xr. ML

XKMS Used for distributing and registering public keys: Support the registration of a key pair by a key pair holder; Delegates the processing of Key Information associated with an XML signature, XML encryption, or other public key. Can be used as alternate for SAML when participants don't have single trust agreement established.

XACML The XACML (extensible access control markup language) specification consists of two related vocabularies: one for access control and one that defines a vocabulary for request and response exchanges. Through these languages, the creation of fine-grained security policies is made possible.

Xr. ML Extensible Rights Markup Language is a grammar for expressing rights and conditions associated with digital content, services, or any digital resource. Can be used as WS-Security token.

Web Service Security framework

related WS* standards on top z WS-Policy framework z WS-Trust z WS-Privacy z WS-Federation framework

WS-Policy framework z Where WS-Security implements security, z the WS-Policy framework is used to describe what has been implemented: z. . . What security token is required? z. . . Encryption is required. z. . . What part of the message must be encrypted? Signed? Whole body or a part? z. . . numerous options to agree upon z Both for server AND client (!)

WS-Trust This specification establishes a standard trust model used to unite existing trust models, so that the validity of exchanged security tokens can be verified. WS-Trust provides a communications process for requesting the involvement of third-party trust authorities to assist with this verification.

WS-Privacy Organizations can use WS-Privacy to communicate their privacy policies and check to see whether requestors intend to comply to these policies. WS-Privacy works in conjunction with WS-Policy and WS-Trust.

WS-Federation framework (WS-Federation, WS-Authorization, WSSecure. Conversation) There are numerous ways of integrating different trust domains (or realms) when utilizing the WSSecurity, WS-Policy, and WS-Trust standards. The WS-Federation specification provides a series of standards and security models for achieving a federation — an environment where a level of trust has been established between disparate trust domains.

Web Service Security framework

Landscape of web services WS-Security landscape XML-landscape WS*-landscape

Cliff hanger

Invitation Enjoyed Web services and/or Security? … doing your master’s thesis Consider applying with TNO …