There are different ways how to authenticate within a REST call in Process Integration. Especially when calling a REST API it is more and more common to use OAuth 2.0. Unfortunately the standard REST adapter so far only supports some types of OAuth 2.0 – but not client credentials grant type with an API token.

I have found several great blog posts that have already covered certain aspects of OAuth 2.0 like this one: oAuth Authentication with SAP Process Integration

However I wanted to have both the OAuth 2.0 access token lookup and the actual REST call combined in a single service call. This can be realized with a simple UDF mapping that calls a HTTP receiver lookup channel with method POST and some extra header fields to request the token.The lookup itself was described many times already, like in this post here:
Webservice Calls From a User Defined Function

This token can then be inserted dynamically in the HTTP header of the actual REST receiver channel. The handling of dynamic header fields in the REST adapter is also described here: PI REST Adapter – Define custom http header elements

Access token lookup request: The request for the access token could be defined in different ways. This example shows the grant type client credentials (see RFC6749) and includes a base64 encoded string containing a client id and a client secret. The payload of the message is simply “grant_type=client_credentials”.

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <BASE64_ENCODED_STRING>
grant_type=client_credentials

The expected response of this request will be the access token, here in JSON format.

{
 "scope":"",
 "expired":false,
 "access_token":"<ACCESS_TOKEN>",
 "token_type":"bearer",
 "expires_in":3599
}

REST Call Authorization header: When sending the access token in the “Authorization” request header we have to use the “Bearer” authentication scheme to transmit the access token (as described in RFC6750).

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer <ACCESSTOKEN>

This is how I have implemented it:

1. Data Types
Define a data type that includes the required parameters for your REST call plus a token field that we will fill in the UDF mapping.

2. Mapping with UDF and parameters
In the graphical message mapping you can do a 1:1 mapping for the REST parameter fields. Then you need to include a UDF to fill the token field.

Unfortunately I was not able to use a channel parameter, because for some reason it does not support HTTP channels. But with two string parameters for “service” and “channel” (and optionally “party) it was possible to hand over the HTTP channel for the token lookup dynamically.
Don’t forget to define and bind the used parameters also in the operation mapping.

	String token = "";
	StringBuffer sb = new StringBuffer();

	// 1. Get a system accessor for a channel. 
	String party = ""; // emtpy values cannot be passed from Directory to the mapping parameters.
	Channel HTTPchannel = LookupService.getChannel(party,service,channel); 
    SystemAccessor accessor = LookupService.getSystemAccessor(HTTPchannel);  
	getTrace().addInfo("Parameters for Token Lookup - Service: "+service+", Channel: "+channel); 
    try{ 
      // 2. Create a payload according to the data type.
      //   Use service.getBinaryPayload() for binary payload,
      //   or service.getTextPayload() for text payloads.
		InputStream inputStream;
		String reqString ="grant_type=client_credentials";
		getTrace().addDebugMessage("Request: "+reqString);
		inputStream = (InputStream) new ByteArrayInputStream(reqString.getBytes());
      com.sap.aii.mapping.lookup.Payload payload = LookupService.getXmlPayload(inputStream); 
      // 3. Execute lookup.
      com.sap.aii.mapping.lookup.Payload result = accessor.call(payload);
     // 4. Parse result, could be better realized with a real JSON parser
		byte[] b = new byte[4096];
		for (int n; (n = result.getContent().read(b)) != -1;){
				sb.append(new String(b,0,n));
		}
	  getTrace().addDebugMessage("Response: "+sb);
		int i =sb.indexOf("\"access_token\":\"")+16;
		int j = sb.indexOf("\"token_type\"");
		token = sb.substring(i,j - 2);
		getTrace().addInfo("Token: "+token);

	}
	catch (Exception e){
		e.printStackTrace();
	}
    finally{
       
        // 5. close the accessor in order to free resources.
        if (accessor!=null) accessor.close();
    }
	return token;

3. HTTP Receiver Channel for OAuth 2.0 Token Lookup
Create a HTTP receiver channel with your target URL and proxy if required. Make sure that you have selected method POST. Also include the Content-Type and Authorization header fields with the base64 value of <CLIENT ID>:<CLIENT SECRET>. This could probably also be done in a more dynamic way, but I wanted to keep things simple here.

4. REST Receiver Channel for API call
Create a REST receiver channel with your target URL and request parameters as required by your call. The channel sets the Authorization header field from the UDF.

5. Integrated Configuration Object with parameters
You also need to fill the mapping parameters here.

Well, this is just one way to implement OAuth 2.0 authentication but I like this one because it is rather simple. I hope this blog is helpful for you.

To report this post you need to login first.

6 Comments

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

  1. Vadim Klimov

    Hello David,

     

    Thank you for informative blog and such illustrative example – very helpful input and handy solution, very much appreciated!

    The only thing I would like to draw your attention to, is limitations of Mapping Lookup API usage. In particular, it works well when communication channel which is looked up and executed (for example by means of SystemAccessor, as it is in the described case), runs on PO’s Central Advanced Adapter Engine (cAAE). In case of running the channel on non-central Advanced Adapter Engine (ncAAE), lookup using LookupService and correspondingly SystemAccessor fails. As a result, if mapping with the lookup inside cannot be run on cAAE and has to be executed on ncAAE, feasible workaround is to implement lookup without utilization of Lookup API, but purely by means of generic custom development (which respectively causes increased development efforts and potential increase of maintenance efforts if lookup configuration needs to be changed, and finally technical debt).

    In SAP JavaDocs, there is very light hint on this – for example, in SystemAccessor, it is stated: “Accessor for a communication with a remote system. The communication is established via adapters of the Integration Server.“, which may be interpreted as only communication channels running on cAAE (of Integration Server) make sense here.

    The last time I faced this limitation, was when assessing options for lookup implementation in PO release 7.4, but I assume the same restriction may remain in release 7.5.

     

    Regards,

    Vadim

    (0) 
  2. Ravi Gupta

    Hi David,

    I have to use NTLM authentication having user id + password + domain name. I have tried different combination of base 54 encoded strings of these 3 values as mentioned below:

     

    Authorization NTLM base64 encoded string

    But I am still getting authorization issue. Can you suggest how your approach works in this case.

     

    (0) 

Leave a Reply