Skip to end of metadata
Go to start of metadata

This page describes how to configure your SAML product to issue valid assertions for the SAML Bearer Assertion flow scenario. 

The SAML assertion asserts the resource owner's identity. Basically there are two ways to obtain an assertion:

  1. Obtain the assertion from a Security Token Service or Identity Provider. In general every WS-Trust respectively SAML 2.0 compatbile product can be used. In this case you need to configure your Security Token Service to be able to issue SAML Assertions for the particular ABAP system.
  2. Let the OAuth 2.0 enabled application create the SAML assertion itself.

In any case the SAML Assertion is subject to certain requirements in order to be processed properly by the AS ABAP.

  • SAML version 2.0 is required, subjection confirmation method is bearer
  • The NameID element of the Subject must be used to express the user's identity. Based on the given format (e.g. E-Mail, Unspecified) the AS ABAP will derive the correct SAP user ID from it. Refer to the SAP documentation for a complete list of all the NameIDs supported.
  • Either the AudienceRestriction or the Recipient element of the assertion must point to an OAuth 2.0 token endpoint URL, (e.g. https://asabap_host:port/sap/bc/sec/oauth2/token)
  • The assertion must be signed by the Security Token Service/Identity Provider/other- SAML issuer key whose certificate is imported into the SAML2 transaction as primary or secondary signing certificate for a trusted partner. See Registration of an OAuth 2.0 Trusted Identity Provider
  • Optional: If activated in the OAuth 2.0 client configuration (transaction SOAUTH2) the SAML attribute client_id must be set and equal the client_id form parameter of the access token request.

    • The SAML assertion will be bound to the access token request. This measure prevents that the SAML assertion could be used by another OAuth 2.0 client. A potential attacker would additionally need valid client credentials in order to make use of the assertion. 
    • The function to make the client_id check optional is available since SAP_BASIS 731 SP6.

See an example assertion which makes use of the client_id feature and states the SAP user ID directly using the NameID format unspecified .

<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion ID="_2c74223a-442b-48ff-8843-012d82c2f539" IssueInstant="2013-03-25T15:07:30.369Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="">
	<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">DemoAppIDP</saml2:Issuer>
	<ds:Signature xmlns:ds="">
			<ds:CanonicalizationMethod Algorithm=""/>
			<ds:SignatureMethod Algorithm=""/>
			<ds:Reference URI="#_2c74223a-442b-48ff-8843-012d82c2f539">
					<ds:Transform Algorithm=""/>
					<ds:Transform Algorithm="">
						<ec:InclusiveNamespaces PrefixList="xs" xmlns:ec=""/>
				<ds:DigestMethod Algorithm=""/>
	<saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
		<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">manager</saml2:NameID>
		<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
			<saml2:SubjectConfirmationData NotOnOrAfter="2013-03-25T19:07:30.545Z" Recipient=""/>
	<saml2:Conditions NotBefore="2013-03-25T15:07:30.369Z" NotOnOrAfter="2013-03-25T19:07:30.545Z" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
	<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
		<saml2:Attribute Name="client_id">
			<saml2:AttributeValue xmlns:xs="" xmlns:xsi="" xsi:type="xs:anyType">LEAVEAPP</saml2:AttributeValue>
	<saml2:AuthnStatement AuthnInstant="2013-03-25T15:07:30.561Z" SessionNotOnOrAfter="2013-03-25T15:07:30.576Z" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">