Skip to Content

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 http://wiki.scn.sap.com/wiki/display/Security/Leave+Request+Approvals+on+Android+-+OAuth+2.0+powered. 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!

Android_OAuth2.0_Demo.png

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

Screenshot_1_20_14__2_21_PM.png

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

Screenshot_1_20_14__2_22_PM.png

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

Screenshot_1_20_14__2_23_PM.png

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

Screenshot_1_20_14__2_24_PM.png

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: https://yourGatewayServer.com/sap/bc/sec/oauth2/token

Screenshot_1_20_14__2_29_PM.png

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.

Screenshot_1_20_14__4_43_PM.png

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.

Screenshot_1_20_14__5_05_PM.png

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.

Screenshot_1_20_14__5_04_PM.png

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

Microsoft_Word.png

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.

Screenshot_1_20_14__5_14_PM.png

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

Screenshot_1_20_14__5_15_PM.png

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=”http://www.w3.org/2003/05/soap-envelope” xmlns:a=”http://www.w3.org/2005/08/addressing” xmlns:u=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd“>

            <s:Header>

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

http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</a:Action>

                        <a:To s:mustUnderstand=”1″>https://YourADFSServer.com/adfs/services/trust/13/UsernameMixed</a:To>

                        <o:Security s:mustUnderstand=”1″ xmlns:o=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd” >

                                    <o:UsernameToken>

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

                                                <o:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText“>YourPassword </o:Password>

                                    </o:UsernameToken>

                        </o:Security>

            </s:Header>

            <s:Body>

                        <trust:RequestSecurityToken xmlns:trust=”http://docs.oasis-open.org/ws-sx/ws-trust/200512“>

                                    <wsp:AppliesTo xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy“>

                                                <a:EndpointReference>

                                                            <a:Address>https://YourNetweaverGatewayServer.com/sap/bc/sec/oauth2/token</a:Address>

                                                </a:EndpointReference>

                                    </wsp:AppliesTo>

                                    <trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>

                                    <trust:RequestType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>

                                    <trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>

                        </trust:RequestSecurityToken>

            </s:Body>

</s:Envelope>

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

curl https://YourADFSServer.com/adfs/services/trust/13/usernamemixed –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 http://www.base64encode.org

Next you need to url encode the base64 encoded assertion. You can do this through the website http://meyerweb.com/eric/tools/dencoder/

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 http://wiki.scn.sap.com/wiki/display/Security/OAuth+2.0+Client+Registration+for+the+SAML+Bearer+Grant+Type

curl “https://YourNetweaverGatewayServer.com/sap/bc/sec/oauth2/token” –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 “https://YourNetweaverGatewayServer.com/sap/opu/odata/sap/YourService /?$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!

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. SAP ALL

    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.

    (0) 
    1. Brian O'Neill Post author

      Hi,

      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 https://service.sap.com/sap/support/notes/1797103

      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

      (0) 
      1. SAP ALL

        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.

        (0) 
        1. Brian O'Neill Post author

          Hi,

          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

          (0) 

Leave a Reply