Authentication for Web Services

With Web services, you can operate standards-based communication between systems that is independent of the technology platform. A Web service (WS) is a standalone, modular function that can be published and located, and which can be accessed over a network using open standards. For a caller or sender, a Web service is a "black box" that requires input and delivers a result.

You can use authentication nd security for consuming and providing Web services either at HTTP transport level or at SOAP message level. To do this, you can use standard HTTP authentication mechanisms, such as HTTP standard authentication with user ID and password, and standard WS mechanisms to allow authentication at the higher SOAP message level. Authentication at SOAP message level is suited to the specific authentication requirements for WS access and allows you to use strong SOAP message authentication mechanisms, such as XML signatures, for incoming and outgoing WS connections.

The AS ABAP and AS Java WS frameworks allow you to use authentication mechanisms that are based on the WS-Security standard produced by the Organization for the Advancement of Structured Information Standards (OASIS). You can configure the use of authentication for consuming and providing Web services at the HTTP transport level and the SOAP message level for the SAP NetWeaver application platform.

The figure shows that the solutions for authentication and Single Sign-On supported by SAP provide secure access with the following levels of security:

• Authenticate a hard-coded service user for access to a service

  A hard-coded service user and its password are set up in the consumer. The provider authenticates the user ID of the service user for access to the service application. The security of this approach is low and the user ID and data are not protected while they are transported over the network, meaning that they could easily be captured and used to cause damage. The security risk for the provider is also increased by the fact that the service user requires authorizations. Its authorization profiles and roles must be sufficiently extensive to meet the requirements of all of the users who use this service user on the consumer side.

• Authenticate a consumer application with a client certificate

  For reasons of scalability, with this approach you can use the same client certificate to authenticate all service applications of the consumer of an application server, where the System-key key pair of the application server is used. This approach provides more security and functions when sending the encrypted authentication data and the message over the network. This approach is based on asymmetrical cryptographic key pairs and the trust relationship between the consumer and the provider.

• Propagate a user ID of a user authenticated by the consumer

  This approach offers a high level of security. The provider can permit a user call of a service on the basis of an identity of a user authenticated by the consumer. The consumer wraps this identity, for example, in a SAML ticket, signs the ticket, and sends it to the provider. The provider checks the token signature to determine whether it comes from a trustworthy partner. It then unpacks the ID contained in the token and permits the execution of service functions by this user. In this way, the user ID was propagated from the consumer to the provider. This approach also allows the user's activities to be logged in a way assigned to the user (auditability). SAP NetWeaver supports the SAML token profile and therefore offers interoperability with and the use of service applications with non-SAP applications. The authentication data is propagated in a format with built-in protection of integrity. You can also use the confidentiality protection of the underlying transport protocol or work with XML encryption at SOAP level.

To use a Web service, a WS consumer initiates a transaction with a WS provider using the Simple Object Access Protocol (SOAP). The WS consumer can be a system that is configured to consume a specific Web service of the WS provider. The SOAP transaction request can be made over the Internet using the HTTP protocol.

When authenticating at HTTP transport level, the authentication data is transported in the HTTP header for the WS message. If you use this transport level for authentication, you can use a number of authentication and SSO mechanisms that are supported for Web-based access, such as logon tickets, for WS authentication. With AS ABAP and AS Java, you can also use authentication at HTTP level with user name and password and SSO with X.509 certificates, for which the configured mechanisms use the corresponding authentication infrastructures for Web-based access.

However, Web Service messages can be passed through any number of connections and, potentially, a large number of intermediary systems. Point-to-point or connection-oriented authentication at the HTTP transport level might be insufficient or inappropriate for supporting this decoupled interaction.

SAP NetWeaver therefore also allows you to use authentication at SOAP message level or at document level, where the authentication data is transported in the SOAP header of the WS message. The authentication mechanisms supported by SAP NetWeaver at document level are based on the WS-Security standard and allow you to use WS authentication and SSO in accordance with the specific security requirements for WS connections.

You can use the configuration tools of the underlying SAP NetWeaver technology stacks to configure the use of supported mechanisms for WS authentication. These available configuration options allow you to use authentication to provide and consume Web services both at HTTP transport level and at SOAP document level.

More information about relevant security aspects of using supported WS authentication mechanisms:

• Authentication at HTTP Transport Level

• Authentication at SOAP Document Level

Recommended WS Security Scenarios