Skip to Content
Author's profile photo Brian O'Neill

Setting up ADFS 2.0 for OAuth2.0 with Netweaver Gateway

This document will walk you through how to set up ADFS (Active Directory Federation Services) to work with OAuth2 in Netweaver Gateway. We will be able to set everything up and test it without writing any code. A benefit of this approach is that you know that the issue is not in any new code. This guide was written using ADFS 2.0 and Netweaver Gateway 2.0 SP 7 running on Netweaver 7.4.

The scenario we are going to be recreating is the same as in the image below from Before beginning the steps in this blog post, I recommend you complete the netweaver gateway steps described in that link. If your STS (Security Token Service) is ADFS, this blog is for you!


Before we begin, make sure the following steps are completed:

ssl certificates have been set up on both servers (Gateway and ADFS)

ADFS must already be configured to work with active directory

You have already completed the steps in the configuration guide

Log on to your adfs server and open up ADFS 2.0 management

Expand the foloder for trust relationships

Select the folder for Relying party trusts

Click Add Relying Party Trust…

The Add Relying Party Trust Wizard will open, click the start button to begin


On the next screen, select the radio button for “Enter data about the relying party manually” and click Next


Enter a relevant display name and click Next. I chose Netweaver Gateway.


Ensure that the AD FS 2.0 profile radio button is selected and click Next.


You do not need to enter anything for the configure certificate or configure url screens. You can just click next through those. On the Configure Identifiers screen, enter the link used to obtain the oAuth2 token and click add. The link should be:


On the next screen you can choose to allow all users to access this service or deny all users. You response will depend on how much you want to restrict access for oAuth services. Since users will be logged in when accessing your backend data, the sap roles should be sufficient control, so I recommend selecting the permit all users to access this relying party radiobutton.


Lastly, review the settings and click next to add Netweaver Gateway as a relying party trust.

Then select your newly created relying party trust and click Edit Claim Rules…

You exact setting for the claim rules will depend on your system, but SAP is very specific on how the username is passed.

For example:

This works: <NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”>oneillb</NameID>

This does not: <NameID>oneillb</NameID>

In order to get the format to come through correctly, I found that you need to have two transform rules. The first one pulls the value and the second one sets the format. Additionally, the outgoing claim type must be different between the first and second rule.

Here is an example for pulling a username (you may want to use email instead). This may be slightly different depending on your active directory configuration.

When creating the first rule, select the template for Send LDAP Attributes as Claims and click next.


I called my first rule Load username to Common Name. For me, the attribute was SAM-Account-Name and I used common Name as the outgoing claim type.


For the next rule, select the rule template Transform an Incoming Claim.


This is where you select the common name type that we set up in the previous rule and transform it to an unspecified Name ID. Note: This did not work for me when going from a Name ID to a Name ID, so make sure you are going from Common Name to Name ID.


Your two rules should look like my screenshot below and be in the same order.


We are now ready to test! We are going to test this using curl, but you could do the same function with custom code. I like using curl so we can quickly test and adjust until it works!

So First you need to create your request. Create the below xml request in a text editor such as textWrangler or notepad ++ (not MS word) and savethe document as request.txt. Items that you need to change are in red.

<?xml version=”1.0″ encoding=”utf-8″?>

<s:Envelope xmlns:s=”” xmlns:a=”” xmlns:u=”“>


                        <a:Action s:mustUnderstand=”1″></a:Action>

                        <a:To s:mustUnderstand=”1″></a:To>

                        <o:Security s:mustUnderstand=”1″ xmlns:o=”” >


                                                <o:Username>YourUsername </o:Username>

                                                <o:Password Type=”“>YourPassword </o:Password>





                        <trust:RequestSecurityToken xmlns:trust=”“>

                                    <wsp:AppliesTo xmlns:wsp=”“>











Now lets send that request to our ADFS server with the following curl command:

curl –data @request.txt -H “Content-Type:application/soap+xml”  –verbose -o “output.txt”

Now you can open output.txt and see the result. You should see a NameID formatted like this: <NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”>username</NameID> Or similar formatting if you are using email instead. If you format the result for easier xml reading make sure you undo that before continuing.

Remove everything outside of the <assertion></assertion> tags and save the file.

Now base64 encode the assertion and replace your xml with the encoded result This can be done using the website

Next you need to url encode the base64 encoded assertion. You can do this through the website

Now, append the following before the encoded assertion:

client_id=YourClientID&scope=YourScope &grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=YourAssertion

Save this as output.txt

Now we want to send that base64 encoded assertion to our SAP Netweaver Gateway server in order to get an oAuth2 token. You can do this with the below curl operation. The User:Password is the username and password created as the oAuth client system user described at

curl “” –data @output.txt -k –user “USER:PASSWORD(base64encoded)” -H “Content-Type:application/x-www-form-urlencoded” –verbose -o “sapOut.txt”

The response from Netweaver gateway should look like the below. The access token is encrypted and will be used when calling your webservice

{ “access_token”:”TOKEN“,”token_type”:”Bearer”,”expires_in”:”3600″,”scope”:”YourScope” }

Your can now (finally!) call your webservice with this token in a curl command like the below:

curl “ /?$format=json” -k -H “Authorization: Bearer YourToken” –verbose -o “sapOut2.txt”

You should hopefully see the resulting data in the sapOut2.txt file!

If so, congratulations everything works and your ready to create an app that can do all of the steps that you were doing in curl!

My next post is going to be about what I would love to see changed about this oAuth2 implementation.

If you found this useful, please leave a comment about how you are or planning to use oAuth. Also, please let me know if you notice anything that I am doing wrong or could be doing differently. Thanks!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Very good post.

      Author's profile photo Former Member
      Former Member

      This is 95% what I'm trying to do, but instead of with a NW Gateway server would like to use a NW 7.02 SP7 system that hosts web services.

      In your description of specifying the RP Trust identifier URL (xxx/sap/bc/sec/oauth2/token), how would that differ for designating our NW 7.02 system as a WS-Provider?

      We have a Tomcat java app that we will configure to authenticate against the ADFS 2.0 STS.  That java app will then make various web service calls back to SAP ERP (running on NW 7.02 SP7).  It's the piece that we are getting hung up on.

      Author's profile photo Brian O'Neill
      Brian O'Neill
      Blog Post Author


      Did you install the gateway add-ons to your NW 7.02 server?

      One reason I like using the gateway server as a seperate hub is that we were able to upgrade to 7.4 while still connecting to a 7.02 ECC server.

      Take a look at this note

      Based on that note, it sounds like you need at least 7.31 to use oAuth.

      Please let me know what you end up doing.

      -Brian O'Neill

      Author's profile photo Former Member
      Former Member

      We're trying to utilize the native SAML capabilities of NW7.02, which already supports WS-Security that would enable us to authenticate with an external token from a trusted STS.

      Author's profile photo Brian O'Neill
      Brian O'Neill
      Blog Post Author


      Since you are not using oAuth, can you just call the service and pass SAML assertion in the header?

      In my example we call xxx/sap/bc/sec/oauth2/token to get the oAuth authorization token. Then we pass that token in the header when calling our services. I would imagine that you would just pass the SAML assertion in the header in your example.

      -Brian O'Neill

      Author's profile photo Former Member
      Former Member

      Thanks Brian O'Neill, your blog helped me along the way. I just completed this setup. Some of my findings below:

      • The example XML can’t be copy-pasted as is, the quotes need to be manually replaced in notepad or such, otherwise you’ll get a 500 error from ADFS
      • The user name in the XML has to be in the fully qualified format, e.g. <domain>\user or user@domain
      • Not specifically called out but the identifier on ADFS has to match to the token end-point in SAP
      • The SAML assertion in ADFS is encrypted by default, SAP is able to decrypt it though so no need to change ADFS configuration
      • SAP doesn’t currently support hardware terminated SSL, the code to parse clientProtocol is missing in CL_OAUTH2_S_TOKEN_ENDPOINT
      • Unless you use the exact same client_id in ADFS and SAP, which will be in that case restricted to 12 characters, you have to uncheck Requires attribute “client_id” in SOAUTH2
      • Every scope in Gateway needs an access token, you probably want to rethink how you design your services, basically you should have all the required services in one Gateway service rather than calling multiple services (meaning multiple scopes, meaning multiple tokens)
      Author's profile photo Nagesh Rao
      Nagesh Rao

      Same access token can be used to access all the scopes. In tcode - SOAUTH2, Under General Settings  - check the attribute "Scope parameter may be omitted". This in turn returns an access token which is valid for all the scopes that are defined.




      Author's profile photo Thorsten Schulz
      Thorsten Schulz

      Thanks Brian O'Neill,

      i get an an 500 internal Server Error from adfs: 

      Any suggestions?

      <s:Textxml:lang=”en-US”>An error occurred when verifying security for the message.</s:Text>
      Author's profile photo Thorsten Schulz
      Thorsten Schulz

      Does anybody tried this with Azure AD as IDP?