Single Sign-On with an External Security Token Service

Use

The Security Token Service (STS) allows you to use Single Sign-On in heterogeneous system landscapes. It acts as a token broker. Its task is to exchange the security token with which a user of the consumer authenticated himself or herself at the STS for a security token that the 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 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 consumer to the 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 Consumer Key for Confirming Signature (Authentication Only)
Which system negotiates the key?	Consumer or STS provides a key, or STS and consumer each contribute key material	Consumer or STS provides a key, or STS and consumer each contribute key material	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 consumer to the provider	Endorsing signature of messages from the consumer to the provider, no message encryption	Endorsing signature of messages from the consumer to the provider with private key from key pair; no message encryption
Are messages from the consumer to the provider encrypted with the key?	Yes	No Note Encryption must be ensured using a trust relationship between the consumer and the provider; the connection is protected either with SSL or symmetrically.	No Note Encryption must be ensured using a trust relationship between the consumer and the provider; the connection is protected either with SSL or symmetrically.
Which systems know the encryption key for messages from the consumer to the provider?	All: STS, consumer, and provider	Only consumer and provider, since the key is negotiated outside the actual HoK scenario (SSL or symmetric)	Only consumer and 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 provider.
Consumer initially authenticates itself with the STS.
Consumer and STS negotiate keys.
STS issues a SAML token. The negotiated key is contained in the SAML assertion. It is encrypted using the public key of the provider.
The STS encrypts the SAML token with the public key of the provider.
After the provider has received the message from the consumer:
1. It decrypts the SAML assertion
2. It checks the STS signature (with its certificate) and then trusts the key
3. It checks the consumer signature with the decrypted key known to all systems involved. The signature is either an endorsing signature or, in the first scenario, a message signature. In the first scenario, the provider decrypts the message.