WS-security part 2 by z8OBCl

VIEWS: 2 PAGES: 82

									Last week…
     XML-family                                       Web Services


                      Web Services
                           &
                        Security
                          18-1-2006 - v 22
                                                        Web Service
     SOAP                                             Security framework




          Securing Web Services with WS-Security
               By Jothy Rosenberg, David L. Remy
               Sams Publishing, 2004
               ISBN : 0-672-32651-5
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
Example Enc & Sig 1:
Protecting Integrity of <EncryptedData>(1/2)
                                            EncryptedData for SSNo.
                                                Ciphered SSNo.

                                             Key (1) info belonging to
                                                 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:
zConfident keys are associated with sender & recipient
zAND private keys are not compromised

Then:
“This document was prepared by David Remy and can only
be read by Jothy Rosenberg”
SfE: however...

                  z <Signature> &
                    <EncryptedData> are
                    detached
                  z <Signature> can be
                    removed without being
                    noticed
                  z <Signature> 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)


<Order>                                                The original 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>
 Example Enc & Sig 2:
  Encryption follows Signing (2/3)


<Order>                                                The Order, signed by David Remy
  <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>
 Example Enc & Sig 2:
  Encryption follows Signing (3/3)


<Order>                                                The signed order,
  <LineItem sku="82394" quantity="1">
    <ProductName>Birdcage</ProductName>                <Customer> is element Encrypted
  </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>
EfS: however...

                  z ++ Signature, w/t
                    sensitive data,
                    invisible
                  z ++ Clear order of
                    processing
                  z -- Integrity of
                    EncryptedData isn’t
                    guaranteed
In conclusion

z Order of processing SfE
z Security Model: SfE or EfS
Order of processing SfE

z Problem: What to do 1st, Decrypt or
  Validate Signature
z Solution: additional 'Decrypt Transform'
  element for XML-Signature
Security Model: SfE or EfS

z Depends on context, the specific situation
z Specify a Policy
z Consider multi-layered approach SfEfS
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?
  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   Credentials
(indiv./entity)



                       Refer
Establishing and using Identity:
 using Identity (2/2)
                                Portable Assertion
          Trusted Third Party TTP
                          Assertion:                                    Portable Assertion:
                   “Presenting Credentials when                    “Presenting Credentials when
                      Subject initiates action”                    Subject initiates action in other
                                                                           Trust Domain”
                      Authentication: Subject is
                       who she claims to be.
                    Verify: Credentials are legitimately in
                    possession of Subject
Subject          Identity           Credentials
                      Authorization: Subject is
                     allowed to perform action.
                   Verify: Action is allowed by Credentials
                   (rights have been established under
                   Refer 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”



                                                    TravelAgency.com
          Credentials
                                                       Trust Domain 1
   Subject
                        Auth. & make travel order
                          Book flight



                                                                        ChosenAirline.com
                                                                            Trust Domain 2



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:               ChosenHotels.com    ChosenRentals.com
                                                       Trust Domain 4       Trust Domain 3
      SOAP@HTTP(s) )
Summary
Where are we?

       XML-family                                       Web Services


                        Web Services
                             &
                          Security
                            18-1-2006 - v 22
                                                          Web Service
       SOAP                                             Security framework




            Securing Web Services with WS-Security
                 By Jothy Rosenberg, David L. Remy
                 Sams Publishing, 2004
                 ISBN : 0-672-32651-5
SOAP
Objective &
Characteristics
Transport of XML data

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

z It isn't Simple
z it doesn't deal with Objects
z It's got more to do with transport than
  Access
z from version 1.1: SOAP is no longer an
  acronym
z sometimes: 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 Encoding Type ::
z How to bind XML-            z How to encode original
  elements on physical          objects: Serialization of
  remote methods &              original object onto
  parameters                    hierarchical XML-
z Binding style: RPC versus     structure
  Document                    z Encoding type: SOAP
z RPC/Encoded: remote           encoded versus Literal
  invocated procedures,       z Document/Literal:
  synchronous, design-time      document processing,
  binding                       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 Message based:
z ... Mature,                z ... End-to-intermediary-
  straightforward impl.        to-end
z ... Not granular: entire   z ... new, relatively
  payload, entire session      complex, many options
z ... transport dependent    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 (X509, 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 <UsernameToken>
z <BinaryToken>
z <XML tokens>
<UsernameToken>

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

z Support few classes of binary credentials
z X.509 certificates
z ... needs Signature proving possession
  PrivKey
z Kerberos tickets
<XML tokens>

z n XML token = n wrapping top-elements
z SAML Assertion: <saml:Assertion>
z eXtensible Rights Markup Language
  (XrML)
z XML Common Biometric Format (XCBF)
z ... and new tokens will be developed
WS-Security:
SecurityTokens in SOAP
                                                           Username / password
<Envelope>
  <Header>
    <wsse:Security>                                            Binary token
      SecurityToken

      <ds:Signature>
        <ds:SignedInfo>
          <ds:Reference URI=“#MsgBody”>
             <ds:DigestValue>…</ds:DigestValue>
                                                                XML Token
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>…</ds:SignatureValue>
        <ds:KeyInfo>
          <wsse:SecurityTokenReference>
            ReferenceToSecurityToken
          </wsse:SecurityTokenReference>           Tokens have different syntax,
        </ds:KeyInfo>                              hence distinct TokenReference
      </ds:Signature>
    </wsse:Security>                                      Announcement
  </Header>
  <Body Id=MsgBody>
  </Body>
</Envelope>
SAML Assertion:
<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: <holder-of-key>
  or <sender-vouches>
(2/3) XML-Encryption
z Hide selective information
  in SOAP messages
z Security header holds
  <Encryptedkey>
  element
z containing
  <ReferenceList> pointing
  to specific message parts
z Encrypted attachments:
  SOAP w/t Attachments
  (SwA) 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
<Envelope>
  <Header>
    <wsse:Security>                                            Binary token
      SecurityToken

      <ds:Signature>
        <ds:SignedInfo>
          <ds:Reference URI=“#MsgBody”>
             <ds:DigestValue>…</ds:DigestValue>
                                                                XML Token
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>…</ds:SignatureValue>
        <ds:KeyInfo>
          <wsse:SecurityTokenReference>
            ReferenceToSecurityToken
          </wsse:SecurityTokenReference>           Tokens have different syntax,
        </ds:KeyInfo>                              hence distinct TokenReference
      </ds:Signature>
    </wsse:Security>                                      Announcement
  </Header>
  <Body Id=MsgBody>
  </Body>
</Envelope>
Goal 2: To verify a security
token credential

z Reminder: SignatureValue is
  calulated over <SignedInfo>-
  block
z ... containing <reference> and
  ...
z ...Digest of reference.
z Problem: that is always
  <SecurityTokenReference>
  rather than token itself
z WS-Security therefore will
  follow token reference ("STR
  Dereference Transform"
  strategy)
Summary
Summary
Where are we?
     XML-family                                       Web Services


                      Web Services
                           &
                        Security
                          18-1-2006 - v 22
                                                        Web Service
     SOAP                                             Security framework




          Securing Web Services with WS-Security
               By Jothy Rosenberg, David L. Remy
               Sams Publishing, 2004
               ISBN : 0-672-32651-5
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 XrML
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


Landscape of web services                          related WS* standards on top



                              Web Service
                            Security framework
                                 19-1-2006 - v 5


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


Landscape of web services                          related WS* standards on top



                              Web Service
                            Security framework
                                 19-1-2006 - v 5


                                                    Foundation: WS-Security
 Landscape of web services
WS-Security landscape




                        XML-landscape   WS*-landscape
                        Cliff hanger
 What do you need to know to pass
 your exam

                                                          Principles
                   Understanding XML-Signature &
                                                          Understand purpose of major <element>s
                   XML-Encryption & SOAP
                                                      Reading, not w riting
                                                          Basic understanding of XML grammar




Cliff hanger
 19-1-2006 - v 3                                      Principles
                                                      Understand its purpose
                    Understanding WS-Security
                                                      Know its compounding structure
                                                   Recognise differences betw een various
                                                   usage scenarios
                          Invitation
Enjoyed Web services and/or Security?




                                                 … doing your master’s thesis

                  Consider applying with TNO …

								
To top