Content Server RestAPI tickets when having multiple CS servers behind a loadbalancer

JeroenL

Hi, We have 3 content server servers who together are our content server environment that provide access via RestAPI to a custom application.

These 3 content server are behind a loadbalancer,

when getting an OTCSTicket via the restAPI call Auth we noticed this ticket is only valid for RestAPI calls that go to the content server server that issued the ticket. RestAPI calls that go to the other content servers do not accept the OTCSTicket.

How can we configure Content Server so a OTCSTicket from one content server is valid on the other content server servers

Best regards

Jeroen

Mahesh Pinnamaneni

I believe if you get the OTCSTICKET using the load balancer URL, then it should just work irrespective of how many servers are in the cluster behind the LB. You would always use the LB URL for any subsequent calls.

appuq

You can also use OTDSTicket which is cluster aware and it will seamlessly be replaced for an OTCSTicket

JeroenL

Thank you, i will try using the otDsTicket!

appuq

@Mahesh Pinnamaneni each CS in a cluster encashes cookie tokens using this setting so if the CS servers are not set consistently it can cause discrepancies I have shown the correct way to set the parameter

Configure Security Parameters

The default OT set is the highest spoofing-free setting

This means that a Cookie issued by one server is to be trusted only by the same server.

OTDS is the primary authentication source so once CS gets this the OTDSTicket is decrypted finds the user and sets an OTCSticket.

Mahesh Pinnamaneni

@appuq - You are right. The default configuration is the standard and default option that most clients use. But this is used for Cookie Authentication and I am not aware that REST API uses this when we pass OTDSTICKET or OTCSTICKET. I did a quick test getting a OTCSTICKET directly from one server (without LB url) in the cluster and was able to use that ticket for another server in the cluster. So in my opinion both (LB and individual server ) works. In my experience, you have different ways of getting the tickets for Content Server: 1) use /auth from CS REST API to get OTCSTICKET 2) use OTDS REST API (like /authentication/credentials) for that resource 3) using oAuth client's access_token as bearer token.

My recommendation is to always use LB URL instead of individual server URLs.

@JeroenL - Please make sure you check the settings are in sync (atleast on front-ends).

appuq

@Mahesh Pinnamaneni most likely your servers are set for "Do Not Use IP Address"

a more worthwhile test could in my mind would be this

1. You need two computers with postman installed
2. Your CS URLs should have the 255.255.255.255 mask(the toughest one)
3. using computer one you would hit the non-LB URL to CSURL1 and take its token
4. using computer two you would hit the non-LB URL of CSURL2, it will be rejected…

When you use an LB URL most LB's use sticky so you are going to hit the same server that issued you the cookie unless you know your LB is set to do round-robin or least connections

there are also other things like a common cookie key .

REST will not trust cookies it explicitly looks for a header variable however since Ot's RH and REST is served by the same intercepting code it most likely will be governed by the Security Parameters of the individual server

Mahesh Pinnamaneni

The scenario what you are mentioning will obviously gets rejected bcoz you are spoofing. I don't think this happens in the real world scenario unless it was done as man-in-the-middle attacks. But I think it should work if you use the same client machine to make calls to different front-ends in the cluster using the same token.

Also, I don't think @JeroenL was trying the same thing as you are describing with two separate client machines.

I peeked into the OScript code and I see that its checking for header's OTDSTICKET, OTCSTICKET, Authorization & MYSAPSSO2. It doesn't seem like its checking the Cookie for the REST calls unless I am missing something.

appuq

You are right the protection is to fail spoofing and not using different browser (clients) . Sorry for the incorrect information