Putting it all together.
A quick reminder of the steps to accomplish:
And finally was ready to test this “ubiquitous” authorisation flow (initially using postman). But all I was getting was an 401 error (=logon error). Please goto troubleshooting section below for detailed explanation.
And while contemplating my bad luck I happened to come across the following community post. The answer provided by Wolfgang Janzen is spot-on!
When I read through it I said to myself – this is it. The missing S_SCOPE object must be the culprit!
Let’s get it done!
At this stage we shall deviate from the SFSF/ECP documentation as we shall be generating the saml assertion programmatically! (sub-step 1a and 1b below.)
Why ? This is because:
- the ABAP server is not exposed to the public internet thus SFSF built-in destination service (the one from the SFSF security center) is not an option.
- the client application has no SFSF EC tie-in thus SFSF built-in destination service cannot be used either
On the other hand, SAP BTP destination service can help generate the saml bearer assertion in either use case (even if the server or application have no public internet exposure)! Please refer to the sibling blog if this is of interest as well.
3. OAuth 2.0 Access Token Response
After successful authentication and authorization check for the OAuth client and the resource owner the token endpoint inside the AS ABAP will send an OAuth 2.0 bearer access token back.
4. OData Service Request and Response
The OAuth client uses the access token in the HTTP bearer authorization header to access the OData service (ZUI_TRAVELPROCESSORMMY).
The main troubleshooting note is 1688545 – OAuth 2.0 Server in AS ABAP Troubleshooting.
And the transaction SA38 with SEC_TRACE_ANALYZER is your friend.