Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

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!

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

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="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+Gran...

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!

9 Comments
Labels in this area