![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](https://image.slidesharecdn.com/whatisadvancedwebservicels-220519105834-da20ef44/85/What-is-Advanced-Web-Servicels-pdf-1-320.jpg)
What is Advanced Web Servicels.pdf
- 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.