Skip to Content
Technical Articles

Using OAuth 2.0 to access SAP Cloud Platform Business Rules

One of the most widely used authorization protocols for securely accessing REST APIs in cloud environment is OAuth 2.0. SAP Cloud Platform Business Rules now supports OAuth 2.0 authentication protocol to access its runtime and design-time APIs. It is indeed good news for those who did not intend to use Basic Authorization to invoke business rules in their application. Now, with few simple security and destination configurations you can enable OAuth 2.0 authorization to be used while accessing any business rules APIs.

In this blog, I will explain how you can use OAuth 2.0 authorization to access business rules APIs.
To begin with,

  1. Register OAuth client in SAP Cloud Platform

  Follow this official guide to register a new client

  • Goto sub-account of your SAP Cloud Platform Cockpit
  • In the left panel, click on Security –> OAuth option
  • On the right web page, switch to Clients tab

 

  • Click on Register New Client button
    • Fill the details as shown in the screenshot below
      • Name: <Any name of your choice>
      • Subscription: From the options choose the one with:
        • <subaccount-technical-name>/bpmrulesruntime
          (if you want to access runtime API)
        • <subaccount-technical-name>/bpmrulesrepository
          (if you want to access design-time API)
      • ID: This is your client-id that will be used for authorization
      • Authorization Grant: Client Credentials
      • Secret: Enter any password
        (This will be your client-secret that will be used to access APIs)
      • Token Lifetime: Keep it default to 60 minutes or you can change it based on your requirement

  • Save the newly created client
  1. Add the oauth_client user to respective business rules roles

Assign the necessary role of the business rules service to this named user created via registering the new client: oauth_client_<clientID>

  • Goto sub-account of your SAP Cloud Platform Cockpit
  • In the left panel, click on Services
  • On the right webpage, search for business rules service
  • Click on the tile to configure business rules service

 

  • From the options in the bottom of the page, select Configure Business Rules Runtime if you have created client for bpmrulesruntime or else select Configure Business Rules Repository.
  • From the left panel, select Roles
  • Assign oauth_client_<clientID> (where clientID is the ID of the OAuth client that you created in Step1) user to RuleSuperUser role as shown in the screenshot below.

 

  1. Create destinations to access APIs

To access APIs via OAuth 2.0 client credentials type, we will create two destinations. One destination will be used to fetch the access token (as the client credential has the token lifetime, which means that a token can be used until the given lifetime which could be for example: 60 minutes) and another destination will be used to access the actual runtime/repository APIs.

In the example shown below, I already had a destination named BUSINESS_RULES of Basic Authentication type which I was using to access business rules runtime APIs until OAuth 2.0 was released. Now, I created 2 new destinations BUSINESS_RULES_UAA and BUSINESS_RULES_OAUTH to access the token and APIs respectively.

Note: You may also choose to replace your basic authentication destination (for example BUSINESS_RULES in this screenshot) so that your application logic need not change and you can easily shift from Basic Auth to OAuth 2.0

Let us see what parameters you need to provide for this.

  • Get Access Token URL
    • In the cockpit, open Security –> OAuth
    • In the page on the right, you will see a tab called Branding
    • From the OAuth URLs, the url for Token Endpoint is the to get the access token, as shown

 

  • Create Destination for token endpoint
    • In the cockpit, open Connectivity –> Destinations
    • In the page on the right, click on New Destination to create a new destination with the following parameters value:
      • Name: any destination name of your choice
      • Type: HTTP
      • URL: Token endpoint as copied above
      • Proxy Type: Internet
      • Authentication: BasicAuthentication
      • User: client-id of your oAuth client
      • Password: Secret of your OAuth client

  • Save the destination
  • Create/Update destination to access APIs
    • You may choose to create a new destination or update the existing BasicAuth destination with the following values:

  • Authentication: NoAuthentication
  • Additional Properties:
    • bpm.oauth.token.destination: <destination-name-for-token-endpoint>

(When you add the new property in additional properties section, you may not find this property in the drop-down. Simply copy/paste the given key and value in the textbox)

 

  • Save the destination

If you want to consume business rules APIs in any existing cloud services that support destination based connectivity like SAP Cloud Platform Workflow – then all you need to do is use this destination (with NoAuthentication) like BUSINESS_RULES in example above.

  1. Consume API via OAuth 2.0 authorization protocol
    • There is no need for XSRF token if you are using OAuth 2.0 authentication protocol. All you need is to first get the access token as shown:
      • URL: Token endpoint URL
      • Method: POST
      • Username: OAuth client id
      • Password: OAuth client secret

 

  • The access token that you get will be used to call the APIs as shown.

The only difference from basic authorization is the header where you use the authorization header as: Bearer <access-token>.

Rest everything remains the same. For example: In this screenshot from postman, I am invoking business rules of ShoppingCartPromotionRules project having DiscountRuleservice with given headers and body. For more information, read the blog

 


Using a secure authentication system is vital to ensure the security of an application interface accessed over cloud computing platforms. OAuth 2.0 has become the basic security protocol for any native application development using REST APIs. With OAuth 2.0 protocol support, we have closed the gap of insecurely accessing business rules APIs using Basic Authentication method. In this blog I have explained how to use Client Credential grant-type, I will soon publish another blog with other grant type like Authorization Grant.

12 Comments
You must be Logged on to comment or reply to a post.
  • Is there anything extra I might need to do to “activate” oauth on my subaccount (Neo trial)?

    I’ve followed all steps here but I’m getting http 403 when trying to access the business rules service endpoint with the Bearer token. And one of the headers in the response says “X-CSRF-Token required”.

    • If you follow my blog as-is there is nothing else required. You may want to clear the cache and try again. If you using OAuth token correctly then X-CSRF message should not be coming.

  • Hi Archana, thanks for sharing.

    Following your blog as-is everything works well when I am using postman client, but when I try to call destination from my controller.js it doesn´t work. I always receive http response code 405.

    Then, I have tried to first call endpoint to get a token. I can call  endpoint server but I always get a empty response.

    Could you help me please ?

    Thanks

    • Hello Sandro,

      2 things:

      • When you call the destination from UI5 code, you need to appropriately configure neo-app.json. Once you have done it, then it should be straight forward.
      • Token is not needed if you using OAuth 2.0

      Hope you using this blog for Business Rules in Neo?

      • Hello Archana,

        How I was getting an error I have tried to do this step-by-step to easily find the problem.
        Then, first I am calling destination to fetch the access token (BUSINESS_RULES_UAA) and
        after that, I am getting token from response and calling destination to access API (BUSINESS_RULES_OAUTH) with this token in the header.
        This way I found my problem was an empty response from BUSINESS_RULES_UAA with a CORS message in log:
        Response to preflight request does not pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

        After I adjust neo-app.json it turns to work as expected.

        Thanks a lot.