Authenticating Web Service Requests

Web services open business systems by offering access to business functionality to SAP and non SAP clients using Web services. When calling such services, the web service consumer (i.e. a web application running inside a portal, invoking web service requests on a business system) must usually authenticate itself, so the business application can control access to its data and track changed to the data for auditing reasons.

Let's take an example. In step one, the user authenticates at a system like a portal. The portal application needs to make a web service call to the business system. In many scenarios, the web service call will be done using a technical user (i.e. the application in the portal uses the same username/password to make calls to the business system). In such a case, the business system can only do limited auditing, as the information about the user executing the service call is lost.  

To prevent loosing the information, single sign on between the web service consumer and web service provider is needed. In the past, vendors have implemented proprietary mechanisms like Windows integrated authentication, IBM LPTA tokens, SAP Logon Tickets or SAP Authentication Assertion Tickets, making service invocation using single sign technically challenging.  A solution to cross vendor single sign on is using the WS-* standards and SAML or X.509. SAML allows for a standardized exchange of security information related to users between servers over SOAP by using standard XML-based structures.

 The basic entity of security information is known as 'assertion'. An assertion is a statement made by a trusted authority. Three types of assertion types are known: 

•  Authentication: It presents a fact that the user was authenticated at a particular time and with a particular authentication method. It is analogous to the SAP Logon Ticket technology.  
• Attribute: Using this assertion type, a trusted authority can vouch user's attributes like roles or other attributes specific to the user.  
• AuthorizationDecision: It presents a fact that the user is authorized to access a particular resource.  

SAP systems use the Authentication statement to identify the user issuing the request. Attribute and AuthorizationDecision statements are not supported.

Authentication using SAML Sender Vouches

SAML sender vouches is used for passing the user identity between two systems, i.e. between a portal and a backend system.
 

In the first step a user authenticates at a portal, and in step 2 the portal makes a call to the backend system stating user information in an SAML assertion. As there is a trust relationship between WS consumer on the portal and WS provider, the SAML assertion can be used for authentication.
SAML Sender-Vouches assumes direct trust between a web service consumer system and web service provider system. The consumer system confirms a subject in a SAML assertion (the sender vouches) and secures this information with an XML Signature over SOAP Body, SOAP Headers and the SAML assertion. More information is available in the documentation at http://help.sap.com/saphelp_nw70/helpdata/EN/47/2300de9a0b2debe10000000a1553f7/frameset.htm

Sender-Vouches is suited for system to system communications. It is not suited for passing identity from a desktop application like an office application to a backend system for the following reasons:

1.  A trust relationship between each web service consumer and the backend must be established.
2.  Each consumer must use an own key for signing the assertions.

For such scenarios the SAML assertion is to be issued by a central authority, as described in the next section.

Authentication using SAML Holder of Key

SAML holder of key is used when a central authority for issuing SAML token is required, i.e. when the ws consumer is embedded in a desktop application. The WS consumer first makes a call to a central authority called Security Token Service (STS). The STs issues a token, passes the token to the WS consumer and sends it as authentication token to the WS provider.

 Think of a SAML Holder of Key token like a passport. Passports have the following characteristics:

1. It contains a hand written signature proving ownership
2. It is issued by a trusted authority
3. The passport contains information about the owner

Translating this to the XML-world it means:

1. It contains a key used for signing. This key is used to bind the assertion to message by signing i.e. XML Body and Headers.
2. The SAML assertion itself contains an XML Signature identifying the issuing authority.
3. Similar like the SAML Sender Vouches Assertion, it contains information about the user identity.

In the WS-* world, SAML tokens are issued by a service called Security Token Service (STS). The STS is a distinguished web service as defined by the WS Trust specification that issues, exchanges and validates security tokens. As the STS is usually capable of accepting multiple types of tokens, it serves two purposes:

1. Brokering different types of tokens, i.e. a web services consumer authenticating with a Kerberos Token at the STS obtains a SAML token. In this way it is an integration component between IT silos.
2. Centralizing trust and authentication using a star shaped trust relationship. Provider and consumer systems trust a central STS, therefore no direct trust between consumer and provider systems is required. Instead a consumer authenticates at the STS and the STS issues a token trusted by a provider system.
   

Invoking SAP Web Services using SAML from other WS-* implementations

• Single Sign on using SAML with Apache Axis2 (Web Service Runtime)
• Single Sign on using SAML with Sun Metro 2.0 (Web Service Runtime)
• Single Sign on using SAML with IBM DataPower (XML Appliance)
• Single Sign on using SAML SV Oracle SOA Suite 10.1.3.4
• Single Sign on for Web Services from .Net