[Tài liệu cũ] XML Web Services Security

Chia sẻ bởi Nguyễn Duy Diệu | Ngày 29/04/2019 | 151
Chia sẻ tài liệu: [Tài liệu cũ] XML Web Services Security thuộc Bài giảng khác

Nội dung tài liệu:

XML Web Services Security
March 27, 2003
IIDS Group, Vrije Universiteit

Yuri Demchenko, NLnet Labs

Outlines
Historical
XML Security
Web Services Security
OGSA Security

XML Web Services technology for IIDS - Discussion

Historical: How all this started (quoting Tim Berners-Lee)
Initial idea to create resource description language
Existing technologies: SGML + WAIS, Gopher + Library Catalogues
Problems: hyperlinks reference and semantic meaning binding
Past steps:
WWW and HTML
RDF and Metadata
XML and XML Signature
Next step: Semantic Web
Ongoing development:
Computer Grids -> Information Grids -> Semantic Grids

XML Basics: DTD, Schema, XML Protocol, etc.
DTD is document-oriented
Like HTML

Schema is data-oriented
XML Signature
SAML

Basic XML Protocol(s)
XML-RPC
SOAP

XForms, XLink, XML Query, XPath, XPointer, XSL and XSLT, Legal XML
XML Security vs Traditional (Network) security
Traditional Security:
Host-to-host or point-to-point security
Client/server oriented
Connection or connectionless oriented
Generically single/common trust domain/association

XML Security
Document oriented approach
Security tokens/assertions and policies can be associated with the document or its parts
Intended to be cross-domain
Potentially for virtual and dynamic trust domains (security associations)
XML Security - Components
XML Signature
XML Encryption
Security Assertion
SAML (Security Assertion Mark-up Language)
XrML (XML Right Mark-up Language)
XACML (XML Access Control Mark-up Language)
XKMS (XML Key Management Specification)

XML Signature: Features
Fundamental feature: the ability to sign only specific portions of the XML tree rather than the whole document.
XML document may have a long history when different component are authored by different parties at different times
Different parties may want to sign only those elements relevant to them
Important when keeping integrity of certain parts of an XML document is essential while leaving the possibility for other parts to be changed
Allows carrying security tokens/assertions on document/data rather than on user/client
Provides security features for XML based protocols
Provides basic functionality for state assertions

XML Signature structure
 
 

 
( 
()? 
 
 
)+ 

 
()? 
()* 
 
XML Web Services
A Web Service is a software system identified by URI, whose public interfaces and bindings are defied and described by XML. Other software systems may discover and interact with the Web Service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.

Service oriented architecture for application-to-application interaction
Describing Web services – WSDL
Exchanging messages – SOAP extensions
Publishing and Discovering WS descriptions - UDDI
Programming language-, programming model-, and system software-neutral
Standard based: XML/SOAP foundation
Industry initiatives (and development platforms)
Sun SunONE/J2EE (SunONE Studio)
Microsoft .NET (Visual Studio .NET)
IBM Dynamic e-Business (AlphaWorks)
XML Spy by Altova
XML WS - Service Oriented Architecture
WSDL based Service Description
SOAP based messaging over HTTP, SMTP, TCP, etc.
UDDI based Publishing/Discovery
Web services features – three stacks
Web Service Description Language (WSDL)
WSDL is an XML document format for describing Web service as a set of endpoints operating on messages containing either document-oriented or procedure-oriented (RPC) messages.
The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint

WSDL Example – TimeService.wsdl
http://www.Nanonull.com/TimeService/
http://www.Nanonull.com/TimeService/#message(getUTCTimeSoapIn)


Web Services Security Model
WS-Security model provides end-to-end security (as contrary to point-to-point) allowing intermediaries
A Web service can require that an incoming message prove a set of claims (e.g., name, key, permission, capability, etc.).
Set of required claims and related information is referred as a Policy.
A requester can send messages with proof of the required claims by associating security tokens with the messages.
Messages both demand a specific action and prove that their sender has the claim to demand the action.
When a requester does not have the required claims, the requester or someone on its behalf can try to obtain the necessary claims by contacting other Web services.
Security token services broker trust between different trust domains by issuing security tokens.
Web Services Security Model
Security token types
Username/password
X.509 PKC
SAML
XrML
XCBF

WS Security Scenarios
All are built on SOAP based security tokens exchange
Direct Trust using username/password (using SSL/TLS)
Direct Trust using security token
Security token acquisition
Issued security token
Enforcing business policy
Web clients
Mobile clients (gateway services)
Enabling Federations
Using trust chaining, security token exchange, credentials exchange
Supporting delegation
Access control
Auditing
Web Services Security Architecture
WS-Security: describes how to attach signature and encryption headers to SOAP messages. In addition, it describes how to attach security tokens, including binary security tokens such as X.509 certificates, SAML, Kerberos tickets and others, to messages.

Core Specification - Web Services Security: SOAP Message Security
http://www.oasis-open.org/committees/download.php/1043/WSS-SOAPMessageSecurity-11-0303.pdf
Web Service Security – others specifications
WS-Policy: will describe the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms, privacy rules)
WS-Trust: will describe a framework for trust models that enables Web services to securely interoperate
WS-Privacy: will describe a model for how Web services and requesters state privacy preferences and organizational privacy practice statements

WS-SecureConversation: will describe how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys
WS-Federation: will describe how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities
WS-Authorization: will describe how to manage authorization data and authorization policies
WS Security: SOAP Message Security
SOAP Message Security must support a wide variety of security models.

Key driving requirements for the specification:
Multiple security tokens for authentication or authorization
Multiple trust domains
Multiple encryption technologies
End-to-end message-level security and not just transport-level security
Primary security concerns
Protection against interception – confidentiality
XML Encryption
Protection against illegal modification – integrity
XML Signature
Security consideration – Auditing
Timestamping and message expiration
Sequence number and Messages correlation
SOAP Message Security Model
Describe abstract message security model in terms of security tokens combined with digital signatures as proof of possession of the security token (key).

Security token asserts claims and signatures provide mechanism for proving the sender’s knowledge of key
A claim can be either endorsed or unendorsed by a trusted authority
An X.509 Cert, claiming the binding between one’s identity and public key, is an example of a endorsed/signed security token
An unendorsed claim can be trusted if there is trust relations between the sender and the receiver (usually based on historical relations/communications context)
Proof-of-Possession (e.g. username/password) – special type of unendorsed claim

WS-Security SOAP message structure
URI: http://schemas.xmlsoap.org/ws/2002/04/secext

Namespaces used in WSSL:
SOAP S http://www.w3.org/2001/12/soap-envelope
XML Digital Sign ds http://www.w3.org/2000/09/xmldsig#
XML Encryption xenc http://www.w3.org/2001/04/xmlenc#
XML/SOAP Routing m http://schemas.xmlsoap.org/rp
WSSL wsse
http://schemas.xmlsoap.org/ws/2002/04/secext
Security element
Header block targets specific receiver SOAP Actor
Multiple header blocks are allowed targeted at different Actors
New header block are added/appended to existing ones

SecurityTokenReference Model
Usage and processing models for the element.
Local Reference – A security token, that is included in the message in the header, is associated with an XML Signature.
Remote Reference – A security token, that is not included in the message but may be available at a specific URI, is associated with an XML Signature.
Key Identifier – A security token, which is associated with an XML Signature and identified using a known value that is the result of a well-known function of the security token (defined by the token format or profile).
Key Name – A security token is associated with an XML Signature and identified using a known value that represents a "name" assertion within the security token (defined by the token format or profile).
Format- Specific References – A security token is associated with an XML Signature and identified using a mechanism specific to the token
Non-Signature References – A message may contain XML that does not represent an XML signature, but may reference a security token (which may or may not be included in the message).
Computer Grids
Originated from Distributing Supercomputing
To become “pluggable” computing resource
Computer Grids -> Information Grids -> Semantic Grids

Current de-facto standard – Globus Toolkits
Open Grid Services Architecture was boosted by developing XML Web Services – 2002
Commercial Grids are starting
Open Grid Services Architecture (OGSA)
WSDL extensions to describe specifics of Grid Services
Defines new portType - GridService
Provides mechanism to create Virtual Organisation
Provides mechanism to create transient services - Factories
Provides soft-state registration of GSH - Registry
Grid services can maintain internal state for the lifetime of the service. The existence of state distinguishes one instance of a service from another that provides the same interface.
OGSA services can be created and destroyed dynamically
Grid Service is assigned globally (persistent) unique name, the Grid service handle (GSH)
Grid services may be upgraded during their lifetime and referenced by Grid (dynamic) service reference (GSR)


Security Issues in Grid computing - Specifics
General issues:
Traditional systems are user/client/host centric
Grid computing is data centric
Traditional systems:
Protect system from its users
Protect data of one user from compromise
In Grid systems:
Protect applications and data from system where computation execute
Stronger/mutual authentication needed (for users and code)
Ensure that resources and data not provided by a attacker
Protect local execution from remote systems
Different admin domains/Security policies
Security Issues in Grid computing - Components
Authentication
Password based
Kerberos based (authentication and key distribution protocol)
SSL authentication
PKI/Cert based
Authorisation
Integrity and confidentiality
Cryptography
Assurance
Accounting
Audit

Authentication
Traditional systems:
Authenticate user/client to protect system
Grid systems:
Mutual authentication required
Ensure that resources and data not provided by a attacker
Delegation of Identity
Process that grants one principal the authority to act as another individual
Assume another’s identity to perform certain functions
E.g., in Globus: use gridmap file on a particular resource to map authenticated user user onto another’s account, with corresponding privileges
Data origin authentication
Authorisation
Traditional systems:
Determine whether a particular operation is allowed based on authenticated identity of requester and local information
Grid systems:
Determine whether access to resource/operation is allowed
Access control list associated with resources, principal or authorised programs
Distributed Authorisation
Distributed maintenance of authorisation information
One approach: Embed attributes in certificates
Restricted proxy: authorisation certificate that grants authority to perform operation on behalf of grantor
Alternative: separate authorisation server

Assurance, Accounting, Audit
Assurance
When service is requested, to assure that candidate service provider meets requirements
Accounting
Means of tracking, limiting or changing for consumption of resources
Audit
Record operations performed by systems and associate actions with principals
Find out what went wrong: typical role of Intrusion Detection Systems
OGSA Security
Built upon WS Security
OGSA Security Roadmap - Specifications (1)
Naming
OGSA Identity Specification
OGSA Target/Action Naming Specification
OGSA Attribute and Group Naming Specification
Transient Service Identity Acquisition Specification
Translating between Security Realms
Identity Mapping Service Specification
Generic Name Mapping Specification
Policy Mapping Service Specification
Credential Mapping Service Specification
Authentication Mechanism Agnostic
Certificate Validation Service Specification
OGSA-Kerberos Services Specifications
Pluggable Session Security
GSSAPI-SecureConversation Specification
OGSA Security Roadmap - Specifications (2)
Pluggable Authorization Service
OGSA-Authorization Service Specification
Authorization Policy Management
Coarse-grained Authorization Policy Management Specification
Fine-grained Authorization Policy Management Specifications
Trust Policy Management
OGSA Trust Service Specification
Privacy Policy Management
Privacy Policy Framework Specification
VO Policy Management
VO Policy Service Specification
Delegation
Identity Assertion Profile Specification
Capability Assertion Profile Specification
OGSA Security Roadmap - Specifications (3)
Firewall "Friendly"
OGSA Firewall Interoperability Specification
Security Policy Expression and Exchange
Grid Service Reference and Service Data Security Policy Decoration Specification
Secure Service Operation
Secure Service’s Policy and Processing Specification
Service Data Access Control Specification
Audit and Secure Logging
OGSA Audit Service Specification
OGSA Audit Policy Management Specification

Trust establishment process (1)
1. Binding an entity identity to a Distinguished Name (“DN” - the subject name in an X.509 identity certificate)
Trust in this step is accomplished through the (published and audited) policy based identity verification procedures of the Certification Authority that issues the identity certificates
2. Binding a public key to the DN (generating an X.509 certificate)
Trust in this step is accomplished through the (published and audited) policy based operational procedures of the issuing Certification Authority (“CA”).
3. Assurance that the public key that is presented actually represents the user
Trust in this step comes from the cryptography and protocols of Public Key Infrastructure.
4. Assurance that a message tied to the entity DN could only have originated with that entity:
Trust that a message signed by a private key could only have been signed by the private key corresponding to the public key (and therefore the named entity via X.509 certs) comes from public key cryptography
Trust in this step is also through user key management (the mechanism by which the user limits the use of its identity), which is assured by user education, care in dealing with one’s cyber environment, and shared understanding as to the significance of the private key.
Trust establishment process (2)
5. Mutual authentication, whereby two ends of a communication channel agree on each other’s identity
Trust in this step is through the cryptographic techniques and protocols of the Transport Level Security (“TLS”) standard.
6. Delegation of identity to remote Grid systems
Trust in this step is through the cryptographic techniques and protocols for generating, managing, and using proxy certificates that are directly derived from the CA issued identity certificates.

Remote Authentication, Delegation, and Secure Communication in GRID
Remote authentication is accomplished by techniques that verify a cryptographic identity in a way that establishes trust in an unbroken chain from the relying party back to a named human, system, or service identity. This is accomplished in a sequence of trusted steps, each one of which is essential in order to get from accepting a remote user on a Grid resource back to a named entity.
Delegation involves generating and sending a proxy certificate and its private key to a remote Grid system so that remote system may act on behalf of the user. This is the essence of the single sing-on provided by the Grid: A user / entity proves its identity once, and then delegates its authority to remote systems for subsequent processing steps.
A secure communication channel is derived from the Public Key Infrastructure process and the IETF Transport Level Security protocol.
Globus Grid Security Infrastructure (GSI)
Operational solution providing security infrastructure for Globus Toolkits
Targeted problems:
Thousands of users – thousands of Certs – many of CAs (with different policies)
Grid-wide user group and roles are needed
No grid-wide logging or auditing
Need for anonymous users
Intended to evolve into OGSA Security

GSI Components
Proxy Certificate Profile
Provides proxy credentials to allow for single sign-on and to provide delegated credentials for use by agent and servers
Online Credential Retrieval to create and manage proxy certificates
Impersonation certificate and restricted delegation certificate
Proxy Certificate Profile
Impersonation – used for Single-Sign-On and Delegation
Unrestricted Impersonation
Restricted Impersonation defined by policy
Proxy with Unique Name
Allows using in conjunction with Attribute Cert
Used when proxy identity is referenced to 3rd party, or interact with VO policy

Proxy Certificate (PC) properties:
It is signed by either an X.509 End Entity Certificate (EEC), or by another PC. This EEC or PC is referred to as the Proxy Issuer (PI).
It can sign only another PC. It cannot sign an EEC.
It has its own public and private key pair, distinct from any other EEC or PC.
It has an identity derived from the identity of the EEC that signed the PC.
Although its identity is derived from the EEC`s identity, it is also unique.
It contains a new X.509 extension to identify it as a PC and to place policies on the use of the PC. This new extension, along with other X.509 fields and extensions, are used to enable proper path validation and use of the PC.
Reference: PKC vs AC: Purposes
X.509 PKC binds an identity and a public key
AC is a component of X.509 Role-based PMI
AC contains no public key
AC may contain attributes that specify group membership, role, security clearance, or other authorisation information associated with the AC holder
Analogy: PKC is like passport, and AC is like entry visa
PKC is used for Authentication and AC is used for Authorisation
AC may be included into Authentication message
PKC relies on Certification Authority and AC requires Attribute Authority (AA)





PKC vs AC: Certificates structure
X.509 PKC
Version
Serial number
Signature
Issuer
Validity
Subject
Subject Public key info
Issuer unique identifier
Extensions
AC
Version
Holder
Issuer
Signature
Serial number
Validity
Attributes
Issuer unique ID
Extensions
X.509 PKC Fields and Extensions – RFC 3280
X.509 PKC Fields
Serial Number
Subject
Subject Public Key
Issuer Unique ID
Subject Unique ID
X.509 PKC Extensions
Standard Extensions
Authority Key Identifier
Subject Key Identifier
Key Usage
Extended Key Usage
CRL Distribution List
Private Key Usage Period
Certificate Policies
Policy Mappings
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
X.509 PKC Fields
Private Extensions
Authority Information Access
Subject Information Access
Custom Extensions
AC Attribute Types and AC Extensions
AC Attribute Types
Service Authentication Information
Access Identity
Charging Identity
Group
Role
Clearance
Profile of AC

AC Extensions
Audit Identity
To protect privacy and provide anonymity
May be traceable via AC issuer
AC Targeting
Authority Key Identifier
Authority Information Access
CRL Distribution Points
Other Technologies to look for IIDS
SIP (Session Initiation Protocol) based technologies
Instant Messaging and Presence Protocol – SIP based

XML Web Services technologies for IIDS


Discussion
* Một số tài liệu cũ có thể bị lỗi font khi hiển thị do dùng bộ mã không phải Unikey ...
Người chia sẻ: Nguyễn Duy Diệu
Dung lượng: | Lượt tài: 4
Loại file:
Nguồn : Chưa rõ
(Tài liệu chưa được thẩm định)
Tải tài liệu