Upload
caelan
View
39
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Last week…. XML-family. XML-Encryption. XML-Encryption. Objective. XML-Encryption structure. Resulting Schema shorthand. ? ? ? ? ? - PowerPoint PPT Presentation
Citation preview
Last week…
Web Services XML-family
SOAP Web Service Security framework
Web Services&
Security18-1-2006 - v22
By Jothy Rosenberg, David L. Remy Sams Publishing, 2004 ISBN : 0-672-32651-5
Securing Web Services with WS-Security
XML-family
XML-Encryption
XML-Encryption
Objective
XML-Encryption structure
Resulting Schema shorthand
<EncryptedData Id? Type? MimeType? Encoding?><EncryptionMethod/>?<ds:KeyInfo>
<EncryptedKey>?<AgreementMethod>?<ds:KeyName>?<ds:RetrievalMethod>?<ds:*>?
</ds:KeyInfo>?<CipherData>
<CipherValue>? <CipherReference URI?>?
</CipherData><EncryptionProperties>?
</EncryptedData>
Web service security:Part 2
Combining XML-Encryption with XML-Signature
EncryptedData for SSNo.
Key (1) info belonging to Ciphered SSNo.
Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(1/2)
Ciphered SSNo.
EncryptedData 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 EncryptedData for SSNo.
Signature of SignedInfo
Key (3) info to verify Signature
Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(2/2)
Reasonable Statement
Iff:Confident keys are associated with sender & recipientAND private keys are not compromised
Then:“This document was prepared by David Remy and can only be read by Jothy Rosenberg”
SfE: however...
<Signature> & <EncryptedData> are detached
<Signature> can be removed without being noticed
<Signature> can even be replaced: "Signed by David Copperfield"
Need Policy: If encrypted, then also signed
BTW: what's the order of processing ??
Example Enc & Sig 2: Encryption follows Signing (1/3)
<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <FirstName>Fred</FirstName> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CreditCardType>VISA</CreditCardType> <CreditCardNumber>43343456343566</CreditCardNumber> <CreditCardExpiration>10/08</CreditCardExpiration> </CreditCard> </Customer></Order>
The original Order
Example Enc & Sig 2: Encryption follows Signing (2/3)
<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <Name . . . /> <CreditCard . . . /> <Signature> <SignedInfo> <CanonicalizationMethod Algorigthm=". . ." /> <SignatureMethod Algorithm=". . ." /> <Reference URI="#customer"> <Transform Algorithm=".../#envelopedSignature" /> <DigestMethod Algorithm=". . ." /> <DigestValue>. . .</DigestValue> </Reference> </SignedInfo> <SignatureValue>. . . </SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>O=MyCompany,OU=Engineering,CN=David Remy</X509SubjectName> </X509Data> </KeyInfo> </Signature> </Customer></Order>
The Order, signed by David Remy
Example Enc & Sig 2: Encryption follows Signing (3/3)
<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <EncryptedData id="encryptedData1" Type="Element"> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . . </CipherValue> </CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . .</CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject>O=HisCompany,OU=Technology,CN=Jothy Rosenberg</X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData></Order>
The signed order, <Customer> is element Encrypted
EfS: however...
++ Signature, w/t sensitive data, invisible
++ Clear order of processing
-- Integrity of EncryptedData isn’t guaranteed
In conclusion
Order of processing SfESecurity Model: SfE or EfS
Order of processing SfE
Problem: What to do 1st, Decrypt or Validate Signature
Solution: additional 'Decrypt Transform' element for XML-Signature
Security Model: SfE or EfS
Depends on context, the specific situation
Specify a PolicyConsider multi-layered approach
SfEfS
Summary
XML-family
SAML
Identity
Significance of Identity
Questions focus around Identity:
Who is accessing my network / information?
Who is this request from?
Who sais this information is correct?
Who sent me this confidential information?
How do I know it is really the sender?
...
Establishing and using Identity: establishing Identity (1/2)
Subject(indiv./entity)
Trusted Third Party TTP
Credentials
Refer
Identity
Trust domain HUTrust domain NL
Establishing and using Identity: using Identity (2/2)
Trusted Third Party TTP
Refer
IdentitySubject Credentials
Assertion:“Presenting Credentials when
Subject initiates action”
Authentication: Subject is who she claims to be.
Verify: Credentials are legitimately in possession of Subject
Authorization: Subject is allowed to perform action.
Verify: Action is allowed by Credentials (rights have been established under control of authority responsible for action)
Portable AssertionPortable Assertion:
“Presenting Credentials when Subject initiates action in other
Trust Domain”
Problem
Solution: open federated identity model
Order car
Book flight
Federated Identity:
SubjectTravelAgency.com
Trust Domain 1Trust Domain 1
ChosenAirline.comTrust Domain 2Trust Domain 2
ChosenRentals.comTrust Domain 3Trust Domain 3
ChosenHotels.comTrust Domain 4Trust Domain 4
Auth. & make travel order
Credentials
Book flight
SAML: 1. Communicates Assertions:
• Deferred Identity Decisions2. SAML Fundaments:
• Assertions: XML Schema• Protocols: XML Schema for
Request/response pairs• Bindings: Ass.s on transport &
messaging standards (currently: SOAP@HTTP(s) )
Assertion Statement:“I vouch that this is van Gogh”
Credentials:“Who is this subject”
Summary
Where are we?
Web Services XML-family
SOAP Web Service Security framework
Web Services&
Security18-1-2006 - v22
By Jothy Rosenberg, David L. Remy Sams Publishing, 2004 ISBN : 0-672-32651-5
Securing Web Services with WS-Security
SOAP
Objective & Characteristics
Transport of XML data
Where XML defines the content of a message ...
SOAP defines how that data moves from A to B
Via a number of standard transport protocols, but ...
Extensible to future needs (protocols & standards, functionality)
SOAP is for web services...
.... what Internet Inter-ORB Protocol (IIOP) is for CORBA ....
... and RMI is for Java Allows Sender &
Receiver to support common transport protocol
Simple Object Access Protocol
It isn't Simpleit doesn't deal with ObjectsIt's got more to do with transport
than Accessfrom version 1.1: SOAP is no longer
an acronymsometimes: Service-Oriented
Architecture (or Application) Protocol
Characteristics
SOAP = XML derivativeHence character orientedHence easier debugging (meta-data
describing what is being passed)Hence firewall friendlyTreat XML messages as service
requestSeparation between infrastructure &
application processing of messages
Supported transport protocols
Number of Transport protocols = 1Technically, spec supports expansion
to others (UDP, SMTP, JMS, etc.)Spec Formal binding to HTTP
Structure
Provide transport envelope
Envelope = container to hold XML Data
Uniform container, then be carried by variety of transports
Applications refer to content
Transport refers to envelope
SOAP Header
Information about SOAP envelopeManage the packageExtensibility is located hereSOAP Security (extensions) lives
here
SOAP Body
Information about SOAP ContentContaints the message payload, i.e.
XML DataAnything: full purchase order doc,
RPC inc. method & parameters
SOAP binding & encoding
Binding Style :: How to bind XML-
elements on physical remote methods & parameters
Binding style: RPC versus Document
RPC/Encoded: remote invocated procedures, synchronous, design-time binding
Encoding Type :: How to encode
original objects: Serialization of original object onto hierarchical XML-structure
Encoding type: SOAP encoded versus Literal
Document/Literal: document processing, asynchronous, run-time binding
SOAP processing
SOAP Processors are part of application servers
SOAP runtime system acts upon Headers & Bodies
SOAP intermediaries act only upon Headers
Security: authenticate identities, encrypt or decrypt, validate signatures & call-out TTP authorities, ...
WS-Security
WS-Security
Objective
contrasts (& complements) transport-based security
Secure pipe between 2 directly connected endpoints
Endpoints usually Application Server
Secure IN the pipe, not outside
What about, for instance, logging?
Comparing Transport vs Message based security
Comparing Transport vs Message based security
Transport based: ... Point-to-point ... Mature,
straightforward impl. ... Not granular: entire
payload, entire session
... transport dependent
Message based: ... End-to-
intermediary-to-end ... new, relatively
complex, many options
... Very granular: part of payload, single message
... Transport independent
Characteristics
As flexible as XMLEach message carries own security
strategyFlexibility is strength AND weaknessWS-Security = SOAP securityWS-Security = part of Web Service
Security framework
WS-Security structure
WS-Security: What does it do?
Takes XML Security (XML-Enc & XML-Sig)
Links that with tokens (X509, Kerberos, SAML)
Binds that to SOAPDoing so, defines SOAP security
header
Doing so, defines SOAP security header
Security TokensXML-EncryptionXML-Signature
3 Building blocks
(1/3) Security Tokens
(2/3) XML-Encryption
(3/3) XML-Signature
(1/3) Security Tokens
Information used for authentication & authorization (i.e. username / password, X.509 Certificate, ...)
<UsernameToken><BinaryToken><XML tokens>
<UsernameToken>
<Username><Password> in
clear (over SSL) -> Don't!
Use PasswordType = PasswordDigest instead:
...Time stamp
... Nonce... Password Hash... Requires clear-
text password on both sides
<BinaryToken>
Support few classes of binary credentials
X.509 certificates... needs Signature proving
possession PrivKeyKerberos tickets
<XML tokens>
n XML token = n wrapping top-elements
SAML Assertion: <saml:Assertion>eXtensible Rights Markup Language
(XrML)XML Common Biometric Format
(XCBF)... and new tokens will be developed
WS-Security: SecurityTokens in SOAP
<Envelope> <Header> <wsse:Security> SecurityToken
<ds:Signature> <ds:SignedInfo> <ds:Reference URI=“#MsgBody”> <ds:DigestValue>…</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>…</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> ReferenceToSecurityToken </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </Header> <Body Id=MsgBody> </Body></Envelope>
Username / password
Binary token
XML Token
Tokens have different syntax, hence distinct TokenReference
Announcement
SAML Assertion: <saml:Assertion>
Goal is to confirm that:
... sender, or ... third party,
vouching for the sender,
... has proof of sender's identity
Hence: <holder-of-key> or <sender-vouches>
(2/3) XML-Encryption
Hide selective information in SOAP messages
Security header holds <Encryptedkey> element
containing <ReferenceList> pointing to specific message parts
Encrypted attachments: SOAP w/t Attachments (SwA) not yet recommendation status
Example: Wrapped Symmetrical Key XML Encryption
(3/3) XML-Signature
Goal 1: To provide message integrityGoal 2: To verify a security token
credential
Goal 1: To provide message integrity
<Envelope> <Header> <wsse:Security> SecurityToken
<ds:Signature> <ds:SignedInfo> <ds:Reference URI=“#MsgBody”> <ds:DigestValue>…</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>…</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> ReferenceToSecurityToken </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </Header> <Body Id=MsgBody> </Body></Envelope>
Username / password
Binary token
XML Token
Tokens have different syntax, hence distinct TokenReference
Announcement
Goal 2: To verify a security token credential
Reminder: SignatureValue is calulated over <SignedInfo>-block
... containing <reference> and ...
...Digest of reference. Problem: that is always
<SecurityTokenReference> rather than token itself
WS-Security therefore will follow token reference ("STR Dereference Transform" strategy)
Summary
Summary
Where are we?
Web Services XML-family
SOAP Web Service Security framework
Web Services&
Security18-1-2006 - v22
By Jothy Rosenberg, David L. Remy Sams Publishing, 2004 ISBN : 0-672-32651-5
Securing Web Services with WS-Security
Web Service Security framework
Foundation: WS-Security
XML-SignatureXML-EncryptionSAML-AssertionsBinds to SOAP:
secure interactionSecure XML
leftovers
Secure XML leftovers
XKMSXACMLXrML
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.
XrML
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
Foundation: WS-Security
related WS* standards on topLandscape of web services
Web Service Security framework
19-1-2006 - v5
related WS* standards on top
WS-Policy framework
WS-TrustWS-PrivacyWS-Federation
framework
WS-Policy framework
Where WS-Security implements security,
the WS-Policy framework is used to describe what has been implemented:
... What security token is required?
... Encryption is required.
... What part of the message must be encrypted? Signed? Whole body or a part?
... numerous options to agree upon
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, WS-SecureConversation)
There are numerous ways of integrating different trust domains (or realms) when utilizing the WS-Security, 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
Foundation: WS-Security
related WS* standards on topLandscape of web services
Web Service Security framework
19-1-2006 - v5
Landscape of web services
XML-landscape WS*-landscape
WS-Security landscape
Cliff hanger
Understanding XML-Signature & XML-Encryption & SOAP
Understanding WS-Security
Cliff hanger19-1-2006 - v3
Principles
Understand purpose of major <element>s
Reading, not writing
Basic understanding of XML grammar
Principles
Understand its purpose
Know its compounding structure
Recognise differences between various usage scenarios
What do you need to know to pass your exam
Invitation
Enjoyed Web services and/or Security?
Consider applying with TNO …
… doing your master’s thesis