XML Security Standards — Overview for the Non - Events
Download
Report
Transcript XML Security Standards — Overview for the Non - Events
Web Services Security Standards
Overview for the Non-Specialist
Hal Lockhart
Office of the CTO
BEA Systems
Topics
Web Services Security Introduction
Preliminary work at W3C
WS-Security
SAML
WS-Trust
WS-SecureConversation
WS-SecurityPolicy
WS-Federation
Interdependencies
Information Security Definition
Technologies and procedures intended to implement
organizational policy in spite of human efforts to the
contrary.
Suggested by Authorization
Applies to all security services
Protection against accidents is incidental
Suggests four areas of attention
Information Security Areas
Policy determination
Expression: code, permissions, ACLs, Language
Evaluation: semantics, architecture, performance
Policy enforcement
Maintain integrity of Trusted Computing Base (TCB)
Enforce variable policy
Security Services
Authentication – confirm asserted identity
Authorization – permit or deny a request
Integrity – prevent undetected modification of
data
Confidentiality – prevent unauthorized
reading of data
Audit – preserve evidence for accountability
Administration – control configuration
Others …
Web Services Security
Standards for Interoperability
Consistent with XML, SOAP, WSDL, WS-Policy
Authentication methods already exist
Need to support multiple infrastructure types
Between systems, not internal behavior
Authentication, Integrity, Confidentiality, Key
Exchange
Passwords, X.509, Kerberos, SAML, etc.
Most of WSS is not about stronger security
Better scaling, easier deployment
W3C Security Recommendations
Widespread use of XML – need for integrity &
confidentiality
XML Digital Signature WG (1999 to 2002)
XML Encryption WG (2001 and 2002)
Defines rules to sign XML and record parameters and
signature value
Support all technologies in common use
Key problem: Immaterial changes to XML documents
Solution: Canonicalization
Defines rules to encrypt XML and record parameters
Support all technologies in common use
Key problem: Encrypted data not Schema-valid
Solution: None
Follow-on work currently at W3C
WS-Security Overview
Basic SOAP Message Protection
Signatures, Encryption, Timestamps
Multiple token types
Username, X.509, Kerberos, SAML, REL
Token References
Security Tokens
Abstraction of the common elements of
information objects which represent identities
In some cases, Tokens can be utilized w/o
knowledge of specific Token format
Doesn’t work in all cases
Claims, Key, Issuer, Validity etc.
Passwords are not the same as keys
Generally WSS uses Tokens to indicate keys
Claims are passed along for Authorization
WS-Security General Approach
Security element in SOAP header
Can contain Tokens, Token References,
Timestamp, Signatures, Encryptions
Physical order of elements determines
processing order of signatures and
encryptions
Signed and encrypted data can appear
anywhere in envelope
A toolkit, not a protocol
SAML in Web Services Security
SAML provides a very flexible, XML token
Use of browser profiles not required
SAML Assertions may or may not contain
Keys
Real world names or pseudonyms
Attributes
Viewed as easy and cheap to generate
WS-Trust
Defines generic Security Token Service (STS)
Issue, renew, cancel, validate Tokens
Support for many different configurations and
trust relationships
Only defines generic elements
Other specifications intended to extend and
specify the details,
WS-SecureConversation, WS-Federation
WS-Secure Conversation
Builds on WS-Security and WS-Trust
Allows establishment of secure session
More efficient and secure than using long term
secrets directly
Like SSL/TLS except at SOAP layer
Useful in conjunction with reliable messaging
Adds two new Token types
Security Context Token (holds session info, including keys)
Derived Key Token (enables key derivation)
Two party and three party flows
Also a toolkit, but less so
Key Agreement Scenarios
Unilateral
Mutual
Third Party
WS-Security Policy
Allows Web Service to express Security Policies
Builds on WS-Policy
Uses nested policy to provide scope
Defines various groups of policy assertions
What needs to be protected
What tokens to use
Algorithms, reference types, etc.
Correspond to features of WSS, Secure Conversation, Trust,
etc.
Expressed in WSDL per WS-PolicyAttachment
Constrains content and layout of security header
Defines a number of Assertion types
WS-SecurityPolicy Assertion Types
Protection assertions
Token assertions
Transport, Symmetric, Asymmetric Bindings
Can apply to response as well as request
Supporting Token assertions
Types of tokens, in band or out of band
Binding assertions
What parts of msgs need to be protected – Confidentiality,
Integrity
Additional signatures, e.g. Endorsements
Protocol assertions
Other properties, e.g. Algorithms, Timestamps, Reference
types
WS-Federation
Builds on WS-Trust
Web SSO alternative to SAML profiles
Uses WS-Trust to issue tokens, including
SAML
More generic, less access to SAML-specific
features
Federation Metadata
Reference Tokens
Authorization Tokens
Extends WS-SecurityPolicy
Related Standards
Web Single Signon and Signoff
SAML Web Browser Profiles
WS-Federation (passive requestors)
Authorization Policy – XACML
Digital Signature Services (DSS)
Create & verify signatures, signed timestamps
Key OASIS Technical Committees
Security Services (2001-present)
WS-Security (2003-2006)
Core spec + Token Profiles
Now Closed
WS-SX (2006-present)
SAML
WS-Trust, WS-SecureConversation, WS-SecurityPolicy
WS-Federation (2007)
XACML (2001-present)
DSS (closed) DS-SX (2007)
Digital Signature Services
Security Standards Interdependencies
WS-Federation
WS-SecurityPolicy
WS-SecureConversation
WS-Trust
WSS
DSS
XACML
SAML
XML Digital Signature
XML Encryption
Questions?