UNIT-5�XML AND SECURITY

BY

E.M.Roopa Devi

Kongu Engineering College

Meta data management

• It includes the description information about a Web service necessary to construct a message body and message headers so that a service requester can invoke a service.
• The provider of the service publishes the metadata
• Requester can discover it and use it to construct messages that can be successfully processed by the provider.

Metadata specifications include:

• XML Schema
• WSDL
• WS-Addressing
• WS-Policy
• WS-Metadata Exchange

Acquiring Metadata

• It’s possible that a requester will obtain the metadata it needs using WS-Metadata Exchange or another similar mechanism that queries the WSDL and associated policy files directly

​

• WS-MetadataExchange uses a feature of WS-Addressing called “actions” to access the metadata published by a service provider.

XML SECURITY

• XML based security technologies are also often important for protecting the XML data before and after it’s included in a SOAP message.

​

• These technologies include:
1. XML Signature
2. XML Encryption

​

​

XML Signature

• It is designed to provide integrity, using a variety of encryption and signature mechanisms.
• It is used to ensure that service providers can determine whether or not documents have been altered in transit and that they are received once and only once.

XML Encryption

• Designed to provide confidentiality, using a variety of supported encryption algorithms, of part or all of an XML document to ensure that the contents of a document cannot be intercepted and read by unauthorized persons.

​

• XML Encryption and XML Signature can be used to protect Web services metadata as well as data.

SAML

• SAML-Security Assertion Markup Language
• SAML can be used on its own for exchanging authorization information.
• It is an XML-based open-standard for transferring identity data between two parties:
• an identity provider (IdP) — Performs authentication and passes the user's identity and authorization level to the service provider.
• a service provider (SP) — Trusts the identity provider and authorizes the given user to access the requested resource

XACML

• XACML stands for "eXtensible Access Control Markup Language”
• It is an XML-based language for access control that has been standardized by the Technical Committee of the OASIS consortium. 
•  It describes both an access control policy language, request/response language and reference architecture.

XKMS�

• XKMS stands for XML Key Management Specification

​

• It is a specification of XML application/protocol that allows a simple client to obtain key information (values, certificates, and management or trust data) from a Web Service.

​

Security

​

• Security concerns apply at every level of the Web services specification stack and require a variety of mechanisms to guard against the numerous challenges and threats that are a part of distributed computing.

​

• The mechanisms may have to be used in combination to guard against a particular threat or combination of threats.

​

​

​

​

WS-Security

• WS-Security is designed as a kind of open framework that can carry any token type.
• It was developed to provide message-level security on an end-to-end basis for Web services messages.
• WS-Security headers include the ability to carry strong authentication formats such as Kerberos tickets and X.509 certificates and can use XML Encryption and XML Signature technologies for further protecting the message contents.

• Additional specifications from IBM, Microsoft, Verisign, and others further extend and complement WS-Security, including:

​

• WS-SecurityPolicy
• WS-Trust
• WS-SecureConversation
• WS-Federation

​

​

• WS-SecurityPolicy—Defines security assertions detailing a Web service’s requirements so that the service requester can meet them.

​

• WS-Trust—Defines how to establish overall trust of the security system by acquiring any needed security tokens (such as Kerberos tickets) from trusted sources.

​

• WS-SecureConversation—Defines how to establish and maintain a persistent context for a secure session over which multiple Web service invocations might be sent without requiring expensive authentication each time.

​

• WS-Federation—Defines how to bridge multiple security domains into a federated session so that a Web service only has to be authenticated once to access Web services deployed in multiple security domains.

Advanced messaging

• Messaging includes SOAP and its various message exchange patterns (MEP).
• Reliable messaging is the mechanism that guarantees that one or more messages were received the appropriate number of times.
• Reliable messaging specifications include:
• WS-Reliability
• WS-Reliable Messaging (from IBM and Microsoft)

• Reliable messaging is a protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering

​

• It also supports the concept of bridging two proprietary messaging protocols over the Internet

​

• It automates recovery from certain transport-level error conditions that the application would otherwise have to deal with on its own.

Transaction Processing

• Transactions allow multiple operations, usually on persistent data, to succeed or fail as a unit, such as processing an order or transferring funds.

​

• One of the most important aspects of transaction processing technologies is their ability to recover an application to a known state following an operating system or hard-ware failure.

​

• For example, if any failure occurs before a funds transfer operation is completed (that is, both the debit and credit operations), transactions ensure the bank account balances are what they were before the funds transfer operation started.

• Web services transaction specifications extend the concept of the transaction coordinator
• adapt the familiar two-phase commit protocol for Web services
• define new extended transaction protocols for more loosely coupled Web services and orchestration flows
• Transaction coordinators currently exist in most execution environments, including J2EE, the .NET Framework, and CORBA
• Web services specifications define extensions for coordinators for compensation-based protocols and long-running coordinator-coordinator protocols that bridge software domains.

​

Coordination

• It is a general mechanism for determining a consistent, predefined outcome for composite Web service applications.

​

• The coordinator model includes two major phases:
• acquisition phase
• second phase

• Acquisition phase - Web services that are participating in the composite are enrolled with the coordinator for a specific protocol (such as two-phase commit, compensation, or business process)

​

• Second phase in which the coordinator drives the agreed-upon protocol to completion following the end of the execution of the set of services in the composite.

​

• When a failure occurs, the coordinator is responsible for driving the recovery protocol

Transaction specifications

• WS-Transactions family from BEA, IBM, and Microsoft:
• WS-Atomic Transactions
• WS-Business Activity
• WS-Coordination
• WS-Composite Application Framework (WS-CAF) from OASIS:
• WS-Context
• WS-Coordination Framework
• WS-Transaction Management

​

SOA in mobile

• Integrating mobile devices into an SOA presents specific challenges because the mobile devices may not always be connected to a network.

​

• Mobile devices may also move through network connectivity zones, picking up new IP addresses when they reconnect.

​

• “Mobilized” software is emerging to integrate mobile devices quickly and easily into the service-oriented enterprise.

Occasionally connected architecture for mobile devices

• The SOAP messages in a mobile software solution are transported from the mobile client to the server using a store-and-forward asynchronous protocol that allows the mobile client to keep working even when a network connection isn’t available

​

• When the connection is available, transactions flow to the server-side SOA-based application directly using the messaging transport

​

• When a connection isn’t available, transactions are stored locally so that they can be transmitted when a connection becomes available