Single Sign-On with an External Security Token Service

The Security Token Service (STS) allows you to use Single Sign-On (SSO) in heterogeneous system landscapes. It acts as a token broker. Its task is to exchange the security token with which a WS consumer user authenticated himself or herself at the STS for a security token that the WS provider can evaluate.

In a homogenous, purely ABAP system landscape, no token exchange is necessary. In this case, the STS can still enable Single Sign-On. Alternatively, you can set up Single Sign-On in homogenous landscapes with authentication assertion tickets, for example.

The WS consumer authenticates itself with the STS, and, if authentication is successful, receives a security token containing a short-lived key. SAP supports three SAML-based variants of this SSO method. The differences between these variants are in the creation and use of this key, and in the securing of the message from the WS consumer to WS provider. The table and list below are intended to help you decide which variant to use, by showing the differences and similarities of the different scenarios:

Differences Between the Scenarios

	STS Scenario with Symmetric Key for Message Protection (Signature, Encryption, and Authentication)	STS Scenario with Symmetric Key for Confirming Signature (Authentication Only)	STS Scenario with Asymmetric WS Consumer Key for Endorsing Signature (Authentication Only)
Security Requirements	Encryption, Signature, and Fully-Automated Key Provision	Signature only, encryption between WS consumer and WS provider, not shared with STS. The prerequisite for this is that there is an encryption certificate on the WS provider that is known to the STS. The STS also requires the public key of the WS provider.	Signature only, encryption between WS consumer and WS provider, not shared with STS
Which system negotiates the key?	WS consumer or STS provides a key, or STS and WS consumer each contribute key material	WS consumer or STS provides a key, or STS and WS consumer each contribute key material	WS consumer generates a key pair and sends the public key to the STS
What is the purpose of the key?	Signature and encryption (Protection Key) of messages from WS consumer to WS provider	Endorsing signature of messages from WS consumer to WS provider, no message encryption	Endorsing signature of messages from WS consumer to WS provider with private key from key pair; no message encryption
Are messages from the WS consumer to the WS provider encrypted with the key?	Yes	No Note Encryption must be ensured using a trust relationship between the WS consumer and the WS provider; the connection is protected either with SSL or symmetrically. End of the note.	No Note Encryption must be ensured using a trust relationship between the WS consumer and the WS provider; the connection is protected either with SSL or symmetrically. End of the note.
Which systems know the encryption key for messages from the WS consumer to the WS provider?	All: STS; WS consumer, and WS provider	Only WS consumer and WS provider, since the key is negotiated outside the actual HoK scenario (SSL or symmetric)	Only WS consumer and WS provider, since the key is negotiated outside the actual HoK scenario (SSL or symmetric)

Similarities of the Scenarios

Prerequisite for setting up the scenarios: trust relationship between the STS and the WS provider.
WS consumer initially authenticates itself with the STS.
WS consumer and STS negotiate keys.
STS issues a SAML token. The negotiated key is contained in the SAML token. It is encrypted using the public key of the WS provider.
The STS encrypts the SAML token with the public key of the WS provider.
After the WS provider has received the message from the WS consuemer:
1. It decrypts the SAML assertion
2. It checks the STS signature (with its certificate) and then trusts the key
3. It checks the WS consumer signature with the decrypted key known to all involved. The signature is either an endorsing signature or, in the first scenario, a message signature. In the first scenario, the WS provider decrypts the message.