Impersonate Token from CWS does not work with CS REST API

Hi,

We are producing CS Tokens for end users by using Content Server WebServices (CWS). We are connecting with a sysadmin account and retrieve a token for an end user (non admin account). With this impersonated token we can work with Content Server WebServices without any problem. Now we would try to run some calls via REST API for performance reasons. We tried to use this token for the REST API, but we get the error message that there is authentication required.

Why does this not work?

If we use the LLCookie from a normal WebBrowser session REST API works as it should. What is the difference from a LLCookie issued via WebBrowser to a impersonated cookie via CWS?

Version Info: Content Server 10.5 SP1 (2014-12) with CS Authentication (OTDS is NOT used for authentication)

Thanks & Regards,
Florian.

Find more posts tagged with

API

Comments

Ep Deroock

I had a similar issue, in my case it was caused by the fact that the token was encoded, so I had to decode it first and then pass it to the REST API request.

Florian_Pesendorfer

Thank you for your answer, I already tried decoding the token, unfortunately without success. Tried same with encoding. Unfortunately this did not work either.

Ferdinand Prantl

You should handle the OTCSTicket as a token specific for the CS REST API only. There is no guarantee that tokens used by the classic UI, CWS or LAPI will be usable with the REST API. Although the current implementation is based on the LLCookie, it can change any time. If you don't use OTDSTicket, MYSAPSSO2 or Authorization, you should obtain the OTCSTicket by calling GET /auth. It supports user impersonation too.

I don't know why the token obtained by the CWS wouldn't work.

Florian_Pesendorfer

We found out in a debug session what was the reason. The user to be impersonated was a user synchronized into CS with OTDS, so REST API refused to accept or create tokens with this user. This behaviour is different to cws and former les-services interface which are allowing this.

We patched the REST API for the time being not performing this check and it is working now as it was with cws.