How to Store and Retrieve OAUTH Tokens in SAP PO ?

[former_member607993]

Hello Experts,

Here is the scenario wherein I may please require your valuable inputs/ suggestions:

" From WS client the new access token and refresh token is sent, SAP PO polls every 20 mins using Sender REST Polling (token expires every 30 mins) an and the received tokens needs to be stored

Polling output look alike:

{

"access_token": "w05ssdc5-f441-492b-978f-82db88a21ccb2",

"refresh_token": "115s3dc5-f441-492b-978f-82db88a21ccb2",

"scope": "givenName mail nonce openid profile sn uid",

"token_type": "Bearer",

"expires_in": 1799

}

Now vitally I wanted to store the tokens in SAP PO and then retrieve it to call for actual business Interfaces.

This will help me to avoid doing multiple API authentication calls(there is a API Limit as well) to do the actual business interfaces run and Instead simply retrieve the tokens from lookup table or some property or brm or any.

Achieved through value mapping and NWA application property but seems to have limitations in terms of security and delta cache issues. There is no ECC or any database systems to even do a look ups.

Looking forward for a Better solution. Many Thanks!

Regards,

Rajesh PS

[former_member610899]

Hi Rajesh,

I have a similar requirement Could you please suggest if you were able to close it succesfully .

[former_member607993 · Accepted solution]

Worked out successfully saving tokens in file server, value mapping, Message ID mapper custom module solution.

Finally ended up with an OAuth standard solution which works as expected and good indeed . This is implemented in SAP PO 7.4 SPS16 Patch 15.

https://blogs.sap.com/2020/02/29/oauth-2.0-standard-solution-with-grant-type-as-password-in-sap-po-7...

[orlanmartinezdu · Accepted solution]

Hi Rajesh,

Did your solution worked using only standard Rest Sender polling? Without any extra config done in SAP PO?

Regards,

Fred

[frank_hinrichsen2]

I have a similar challenge as discussed in this post. This post is from 2019, I hoped that there would be an update on this topic, and maybe that the REST adapter built in "Use Oauth Token Caching" was improved in the meantime.

My scenario

I have 2 channels using the same clientID and clientSecret, with different scopes(one is READ and one WRITE) and off course different REST URL setting. Both Channels is setup to use "Use Oauth Token Caching"

On top of that, we have multiple cluster nodes running.

My understanding/hope was that the two channels could share the cached token across channels, nodes etc. But my logs shows that this is probably not the case. Reading this post does not give me more hope either.

Requirement

Due to security reasons, our API management tool is about to introduce a max limit/threshold of token end-point calls for each client.

As it is now, SAP PO’s as a client will be reach this threshold very fast.

I need a solution with better reusage of the token and thereby bring down the number of Token API calls.

Proposal of Solution

Reading this post I see multiple proposals on how to do this in 2019, but where are we today with this?

Any solution proposals.

[philippeaddor]

Hi Rajesh,

This is a good question. I actually thought that the REST Receiver adapter caches the token by itself (there is a checkbox for it). Are you not using this adapter or does it not fulfill your requirement?

I had a similar requirement but for a SOAP API where I had to pass the token in the SOAP Header. I wrote a UDF which fetched the token in the first request and stores it in the value mapping cache together with a timestamp. In the subsequent requests it loads and compares the timestamp with the current time and only fetches a new token in case the cached token has expired (validity in minutes can be configured as module parameter). I didn't deem the VM store a security risk since access to the VM cache monitor is restricted to PO admins and the scenario does not contain confidential data. But maybe one could also consider encrypting the stored token?

Anyway, you are looking for another approach. So maybe this helps in case you don't know it yet: I recently came across a very interesting article about this topic that seems to use an internal PO class called MessageIDMapper which was so far unknown to me. The solution makes use of these methods to store the token to PO internal tables. Maybe that helps.

Philippe

[former_member607993]

Hi Philippe,

Please throw some light about this topic that uses internal PO class called MessageIDMapper.

Thanks - Rajesh PS

[philippeaddor]

Sorry, forgot to paste the link. Here it is: http://www.learntips.net/api-token-via-http-lookup-in-adapter-module/

[philippeaddor]

By the way, the Value Mapping Cache updates are possible without creating change lists. I will have to review my solution and write up how exactly I did it, since I don't remember the details.

[former_member607993]

Philippe Addor,

Coming to OAUTH token cache, which I'm familiar already is a pretty good one. But for example if there are 90+ interfaces which does call to 'xyz' application using OAUTH 2.0 to retrieve new tokens every time for each interface. This again ends up with multiple API service calls to 'xyz' application.

Coming to value mapping there seems to be cache and security issues. Every time it updates the cache and Activates the change list with aysn-sync bridge hops and also token needs to be well secured and what if a delta cache is done in Production.

I actually ended up storing and retrieving the tokens in a PO file system over secured which is suggested by evgeniy.kolmakov.

Also there is another approach to do this which is to persist custom values in SAP PO Data dictionary suggested by anandvithal, But need to test this thoroughly by storing and retrieving tokens.

https://blogs.sap.com/2016/01/18/how-to-persist-custom-data-in-sap-pi-java-table/#

https://blogs.sap.com/2016/01/18/how-to-persist-custom-data-in-sap-pi-java-table-part-2/

https://blogs.sap.com/2016/01/18/how-to-persist-custom-data-in-sap-pi-java-table-part-3/

Thanks - Rajesh PS

[philippeaddor]

rajeshps , regarding oauth token cache: what if you use the same channel for all 90+ interfaces (using dynamic compilation of the URL). Wouldn't it then cache the token for calls across interfaces and hence solve your problem?

As mentioned above, the VM updates and token lookups can be done during messages processing and also the VM can be updated without the need to create change lists. Basically I used the standard PO web service called "ValueMappingReplication" to do so.

I don't have a problem with a cache refresh, since in this case the script would simply fetch a new token during the next call, when it doesn't find an existing token in the cache. However, there is the problem that parallel calls (in different adapter threads) are often fetching several tokens at the same time, because they don't know that another thread is already doing so).

So in the end I like the approach using a file as you did, as it's much simpler and apparently avoids all the issues with the other solutions. The one described in the link above (using MessageIDMapper) still sounds interesting to me, but probably would face similar issues as mentioned for the VM solution.

[former_member607993]

Hello Philippe Addor, Evgeniy Kolmakov

I walked through the below blogs it is pretty competent.

Basically for every Interface it calls the 'MessageIDMapper' to retrieve the stored tokens but I hope it doesn't create any new tokens for each interface which is configured with Module Module (Custom_AF_Modules/AddDynamicConfigurationBean).

https://blogs.sap.com/2016/08/23/setting-dynamic-configuration-attributes-using-custom-adapter-modul...

https://blogs.sap.com/2017/07/05/api-token-via-http-lookup-in-adapter-module/

martin.buselmeier

[former_member190293]

I've used MessageIDMapper class recently. It works fine. No cache issues found.

Regards, Evgeniy.

[former_member607993]

Hello Philippe Addor,

This particular 'value mapping replication' updates the cache at run time in Integration server, in case of Production it does seems to be a fair one. Every time it Updates the cache which is underlying changes(change list GUID) in Production.

https://archive.sap.com/kmuuid2/e07dd2ae-f783-2c10-9aa6-ca69f67dd20f/Value%20Mapping%20Replication%2...

https://help.sap.com/doc/saphelp_nw73/7.3.16/en-US/4a/3626a9d5e92ab1e10000000a42189c/frameset.htm

[philippeaddor]

Hi Rajesh,

I don't know where you see the fact about change lists in the links you've posted above. I have this in productive use and I don't see any change lists after updating the cache values using the web service. The only problem I see are the several token refreshes due to parallel processing (in different thread/nodes).

Regarding your point "I hope it doesn't create any new tokens for each interface": No it probably doesn't if you configure the key, as described in the module configuration description of parameter dc.keyValueStore.key:

"This parameter is optional and by default initialized with the Channel-ID. It is possible to make several channels use the same storage by using the parameter."

Let us know when you have built a satisfactory solution.

Regards,

Philippe

[former_member607993]

Thanks much for your valuable replies. Philippe Addor and Evgeniy Kolmakov.

Currently the refresh and access tokens are stored in PI file server path and retrieved from same property file in a secured way.

Let me also try this Message ID mapper sounds to be super interesting:-)

Thanks all once again...!

[philippeaddor]

Hi Rajesh

I can't really answer the first two questions since I didn't go for this solution. Did you check the content of table XI_AF_SVC_ID_MAP after using the MessageID mapper? It should be possible to see it in NWA's open SQL browser, but I don't have the authorization for it on our system.

Regarding the deletion job: Do you mean the IDmapper validity time? When creating a new instance, you have to pass a timestamp. Later on, you can run the method removeExpiredIDMaps in order to delete expired entries (see https://help.sap.com/doc/2f39047ed6b141cb83658041d2d4e029/7.5.8/en-US/PI/com/sap/aii/af/service/idma...).

[vicky20691]

Hi,

Refresh token sadly not possible. I find evgeniy.kolmakov solution suitable enough.

Sad, but not many optimized solutions available here.

Regards,

Vikas

[former_member607993]

Thanks alot Vikas.

Vikas Kumar Singh 🙂

[ankit_mishra09]

Hi Rajesh,

As discussed in https://blogs.sap.com/2018/02/26/oauth-2.0-authentication-using-rest-pooling-value-mapping-change-li...

try using Value Mapping to save the tokens.

Do you need both access token & refresh token for your scenario? If you are using Rest Pooling then you can have a fresh access token every 20-25 min.

Thanks

Ankit

[former_member607993]

Ankit Mishra,

Thanks for your reply. As mentioned in my question thread. I had already achieved this with value mapping and also with reading and writing in application property.

But there seems to be cache and security issues. Every time it updates the cache and Activates the change list which I don't think its virtuous with Production and also Tokens needs to be more secured like a password.

What if some one does a delta cache in Production!

How about storing in file system secured( as suggested by Evgeniy Kolmakov) or persist in a custom PO java table for read & write. Looking for a better approach.

Thanks and Regards,

Rajesh PS

[ankit_mishra09]

Hi Rajesh,

If there's cache issue you might go ahead with Evgeniy Kolmakov approach i.e. store the value in some secured file or in PO table. But you'll have to check with BASIS for accessing paths or tables

Thanks

Ankit.

[former_member190293]

Hi!

It doesn't seem to be the best way, but you could save your token to PI server file system in the form of text/xml file and read it using UDF in your message mapping.

Regards, Evgeniy.

[former_member607993]

Hello Eve,

Could you please elucidate. Advance thanks!

[former_member190293]

Hi Rajesh!

First ICo, which performs the polling, saves result (token details) to your PI server's file system, using Receiver file channel.

In your second ICo you use, for example, UDF in message mapping to retrieve that file contents from file system and set required headers/dynamic configuration attributes.

You also can store token timestamp in order to raise exception in your message mapping if the last saved token seems to be expired.

Regards, Evgeniy.

[former_member607993]

Thanks Evgeniy Kolmakov

[vinaymittal]

Hello Rajesh,

While i understand the concern that you really want to limit the number of API calls and which sounds reasonable as well, AFAIK oauth token calls are not metered by any API provider but yes they are a overhead if you can get away with a refresh token.

SAP PO doesn’t have any storage mechanisms . It’s a shame but thats how it has always been.

Your options here are limited while i have never explored use of refresh token specifically in PO rest adapter this would have been a cakewalk in SAP CPI.

There are java based tables which you can create and modify in sap po but i doubt system admin will allow you access to modify java stack database. It’s highly critical.

In the end if it is really not a deal breaker i would suggest that you get a fresh token every time or let the channel manage it.

Again, I am not an expert here that’s why didnt pitch in earlier but there would be some better answers than mine that would be able to help you.

Try tagging michael or eng swee.

Regards

Vinay

Regards

Vinay Mittal

[former_member607993]

Thanks vinay for your reply.

Will check out if there is any other options.