Advanced Web Services incorporate standards like SOAP, WSDL, UDDI, as well as more complex security standards like WS-Security. They deal with asynchronous behavior and parallelism through standards like WS-ReliableMessaging. The Web Services Interoperability Organization (WS-I) promoted interoperability between web services specifications and joined the OASIS standards body. WS-Federation and related standards help establish trust relationships between security domains.

1. What is Advanced Web Servicels
Advanced Web Services acts as a catalyst, a trigger point to stimulate new
innovative ideas and solutions to improve the way things are done. Advanced
Web Services are Web services that use Web service standards beyond those
that are commonly used. Originally it meant Web services that go beyond the
basic Simple Object Access Protocol (SOAP), Web Services Description
Language (WSDL) and Universal Description, Discovery and Integration (UDDI)
capabilities. Now it is generally accepted that Advanced Web Services
incorporate and deal with complex security scenarios. Advanced Web
Services bundle basic Web service standards such as SOAP, UDDI and WSDL
capabilities, incorporate Web Services Interoperability (WS-I) and include
security standards like WS-Security, and then go beyond that by incorporating
more advanced and sometimes proprietary security features and interactions.
Using the aforementioned standards formerly meant that a Web service was
advanced, but because of wide acceptance of these standards, they have
become commonplace. Now, to be considered as a truly Advanced Web
Service, a Web app must deal with complex security interactions using new
standards such as WS-Federation and WSTrust, as well as deal with
Asynchronous and parallel behavior through WSReliableMessaging. These
advanced standards have been slow in acceptance because of the slow pace
of ratification and rolloul, and also because many existing applications and
their interactions do not require the capabilities of these new and more
advanced standards or they simply use other methods to achieve them.
Web Service Interoperability (WS-1) Organization
The Web Services Interoperability Organization (WS-I) was an industry
consortium created in 2002 and chartered to promote interoperability
amongst the stack of web services specifications. WS-I did not define
standards for web services; rather, it creates guidelines and tests for
interoperability. July 2010, WS-I joined the OASIS, standardization consortium
as a member section. [1] In December 2017 it was completed after having
reached its standardization objectives. The WS-I Standards are now

2. maintained directly by the relevant technical committees within OASIS. It was
governed by a Board of Directors consisting of the founding members (IBM,
Microsoft, BEA Systems, SAP, Oracle, Fujitsu, Hewlett-Packard, and Intel) and
two elected members (Sun Microsystems and webMethods). When it joined
OASIS, other organizations have joined the WS-I technical committee
including CA Technologies, JumpSoft and Booz Allen Hamilton.
WS Federation
A federation is a collection of realms (security domains) that have established
relationships for securely sharing resources. A Resource Provider in one
realm can provide authorized access to a resource it manages based on
claims about a principal (such as identity or other distinguishing attributes)
that are asserted by an Identity Provider (or any Security Token Service) in
another realm. A fundamental goal of WS-Federation is to simplify the
development of federated services through cross-realm communication and
management of Federation Services by re-using the WS-Trust Security Token
Service model and protocol. A variety of Federation Services (e.g.
Authentication, Authorization, Attribute and Pseudonym Services) can be
developed as variations of the base Security Token Service.
WS Federation Terms
• Authorities
Security Token Service (STS) - Web service that issues security tokens; makes
assertions based on evidence that it trusts to whoever trusts it. The Security
Token Service, STS, is a service that acts as a broker to establish trust
relationships between a service provider and a service requestor. The STS
issues signed security tokens which are used by service requestors (clients)
to authenticate themselves at the service providers. o Identity Provider (IP)
Entity that acts as an authentication service to end requestors (an extension
of a basic STS)

3. Security Token Service
The Security Token Service enables operations such as authentication,
authorization, identity validation, identity mapping, and security token
exchange. The STS model involves three main partics. • Service/Resource
Provider • Service Requestor (Client) . Security Token Service (STS)
WS Security
WS Security is a standard that addresses security when data is exchanged as
part of a Web service. This is a key feature in SOAP that makes it very popular
for creating web services. Security is an important feature in any web
application. Since almost all web applications are exposed to the internet,
there is always a chance of a security threat to web applications. Hence, when
developing web-based applications, it is always recommended to ensure that
application is designed and developed with security in mind. This is where
SOAP comes in action to overcome such obstacles by having the WS Security
specification in place. With this specification, all security related data is
defined in the SOAP header element. The header element can contain the
below-mentioned information 1. If the message within the SOAP body has
been signed with any security key, that key can be defined in the header
element. 2. If any element within the SOAP Body is encrypted, the header
would contain the necessary encryptions keys so that the message can be
decrypted when it reaches the destination.
In a multiple server environment, the above technique of SOAP authentication
helps in the following way. Since the SOAP body is encrypted, it will only be
able to be decrypted by the web server that hosts the web service. This is
because of how the SOAP protocol is designed. Suppose if the message is
passed to the database server in an HTTP request, it cannot be decrypted
because the database does not have right mechanisms to do so. Only when
the request actually reaches the Web server as a SOAP protocol

4. In a multiple server environment, the above technique of SOAP authentication
helps in the following way. Since the SOAP body is encrypted, it will only be
able to be decrypted by the web server that hosts the web service. This is
because of how the SOAP protocol is designed Suppose if the message is
passed to the database server in an HTTP request, it cannot be decrypted
because the database does not have right mechanisms to do so. Only when
the request actually reaches the Web server as a SOAP protocol Web Service
Security Standards
Below are the steps which take place in the above workflow 1. A request can
be sent from the Web service client to Security Token Service s service can be
an intermediate web service which is specifically built to supply
usernames/passwords or certificates to the actual SOAP web service. 2. The
security token is then passed to the Web service client. 3. The Web service
client then called the web service, but this time, ensuring that the security
token is embedded in the SOAP message. 4. The Web service then
understands the SOAP message with the authentication token and can then
contact the Security Token service to see if the security token is authentic or
not. WS Trust WS-Trust is a specification and OASIS standard that uses
secure messaging mechanisms of WS-Security to deal with issuing, validating,
and renewing security tokens. WS-Trust is an extension of WS-Security for
security token exchange to enable the issuance and dissemination of
credentials within different trust domains, and thus manage trust
relationships. The goal of WS-Trust is to enable applications to construct
trusted SOAP message exchanges Using these extensions, applications can
engage in secure communication designed to work with the general Web
Services framework, including WSDL descriptions, UDDI business Services
and binding Templates, and SOAP messages
How WS Trust Works WS-Trust specifies protocol mechanisms for requesting,
issuing, renewing. validating, canceling security tokens independent from the
application type. It also defines formats for messages used to request tokens,

5. and responses to those messages. The request message is called Request
Security Token (RST), and the response message is called Request Security
Token Response (RSTR). The WS-Trust standard specifies that Security Token
Service (STS) can be used by both web service clients and providers to
perform operations on standard security tokens. On the web service client
side, which can be a web application or rich desktop application, the SIS
converts whatever security token th into a standard SAML security token
containing the user's identity, which is s with the web services provider. On the
web service provider side, the STS validates tokens and can generate a new
local token for consumption by other applications. Oluth SAMLIX SAML2
OpenToken WAM Session
WS-ReliableMessaging WS-Reliable Messaging describes a protocol that
allows SOAP messages to be reliably delivered between distributed
applications in the presence of software component, system, or network
failures. Web service reliable messaging is a framework that enables an
application running on one application server to reliably invoke a web service
running on another application server, assuming that both servers implement
the WSReliableMessaging specification. Reliable is defined as the ability to
guarantee message delivery between the two endpoints (web service and
client) in the presence of software component, system, or network failures.
Transport Types for Reliable Messaging Asynchronous For buffered web
services: transport . Most robust usage mode, but requires the most
overhead. Automatically retries message delivery. Survives network outages.
Enables restart of the source or destination endpoint. Uses non-anonymous
ReplyTo. Employs asynchronous client transport enabling a single thread to
service Multiple requests, absorbing load more efficiently. For more
information. Web service clients can use asynchronous or synchronous
invocation Semantics to invoke the web service. For more information.

6. Transport Types for Reliable Messaging Asynchronous For buffered web
services: transport . Most robust usage mode, but requires the most
overhead. Automatically retries message delivery. Survives network outages. •
Enables restart of the source or destination endpoint. • Uses non-anonymous
ReplyTo. Employs asynchronous client transport enabling a single thread to
service Multiple requests, absorbing load more efficiently. For more
information. Web service clients can use asynchronous or synchronous
invocation Semantics to invoke the web service. For more information.
For non-buffered web services: • Less overhead than asynchronous, buffered
usage mode. Persists sequence state only. Uses non-anonymous Reply To.
Web service clients can use asynchronous or synchronous invocation
semantics to invoke the web service. For more information. Synchronous
transport Offers the least overhead and simplest programming model. Uses
anonymous Reply To. Web service clients can use asynchronous or
synchronous invocation semantics to invoke the web service. If a web service
client invokes a buffered web service using synchronous transport, one of
following will result: - If this is the first request of the sequence, the
destination sequence will be set to be non-buffered as though the web service
configuration was set as non-buffered). - If this is not the first request of the
sequence (that is, the client sent a request using asynchronous transport
previously), then the request is rejected and a fault returned.