nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

what is the lifetime of a token in a load-balance environment

Guy_Pomerleau

We are developping a web apps that is deployed in a multi-tier and load-balance environment similar to this:

Web apps ---> web services ---- ssl auth ----> load balancer (sticky session enable) ----> livelink web services (2 instance per server on 2 different ip and 2 servers so 4 instance total)

how does it work for the token? Below is our code to authenticate. Since we are in a web service mode, do we need to get a token on each call to the livelink services?

private static LLDocument.OTAuthentication LoginDoc()

{

LLDocument.OTAuthentication tp = null;

try

{

tp = new LLDocument.OTAuthentication();

tp.AuthenticationToken = string.Empty;

LiveLinkHelper.SetConnection("username:unitas_deve;password:xxxxxxx");

LLAuthentication.AuthenticationClient LLAuth = new LLAuthentication.AuthenticationClient();

string LLToken = LLAuth.AuthenticateUser("unitas_deve", "xxxxx");

tp.AuthenticationToken = LLToken;

Token = LLToken;

//tp.AuthenticationToken = string.Empty;

}

catch (System.Exception ex)

{

tp = null;

throw ex;

}

return tp;

}

Find more posts tagged with

Comments

Kyle_Swidrovich

Bonjour Guy,

The lifetime of the LLAuthentication token is what is defined on the Content Server security settings page for cookie expiration.

Possible token management options can be found in this thread: https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=26866704&objAction=viewincontainer&ShowReplyEntry=28814389#forum_topic_28814389

My comment in that thread was:

One possible solution is wherever you pass a token into a web service method, replace that with a call to a helper function you write that handles refreshing the token if necessary.

The Authentication.GetSessionExpirationDate() method will be helpful here.

Regards,

Kyle

Kyle_Swidrovich

One additional point I will mention here is that your instances that interact with your load balancer will need to share common security settings (like your encryption keys).

If not, a token generated by Server A may not be able to be decrypted by Server B.

Regards,

Kyle

Guy_Pomerleau

Are you saying that if my cookie is set to: "never expire" in the "configure Security parametrs and if the "cookie encryption key" is the same on all my servers, once I get a token I can reuse it foreever and wherever the load-balancer send me?

Kyle_Swidrovich

There are other criteria that can be present in a cookie/token that can prevent reuse of the token.

All the fields in the Cookie Authentication Information section of the Configure Security Parameters page will affect it (e.g., IP address).

If you remove all fields from the cookie, disable expiration and have a shared encryption key, then you could probably reuse it forever.

However, your system would then be horribly insecure.

mch_2916826

Hi Kyle,

I have the same issue. On Production environment, when I get the authentication token from Server A via CWS, it does not work with doc management calls (CWS) on Server B. However we have the same setup in QA environment where the token works perfectly fine regardless on which server it was generated. We have confirmed the settings "func=admin.securityvars" are similar on both front ends. Any idea on this issue?

Quoted Kyle Swidrovich on 08/29/2017 05:27 PM:

One additional point I will mention here is that your instances that interact with your load balancer will need to share common security settings (like your encryption keys).

If not, a token generated by Server A may not be able to be decrypted by Server B.

Regards,

Kyle

Appu Nair

The Cookie or Token is seeded by this setting

?func=admin.securityvars and Cookie Encryption Key: if you do not have a common value say for example 'Livelink'

in all servers serving your request the default is to use <OTHOME> so c:\OpenText is seeded differently than

c:\opentext or c:\OPENTEXT.Cookies are inherently Case Sensitive.

That's probably why your working servers don't have a problem perhaps they were made using the anchor cloning method.

I would also look at other params in that like

Time To Live

In most companies web services work perfectly trouble free if you adopt

Dedicated servers for WS traffic

Sticky algorithm for LB

Bad ideas are also possible like Cookie Authentication Information: If you put 'Do not put IP Address for authentication'

then just like it says you could perhaps spoof as well.I know not.

Appu Nair
Principal Architect | Alitek
Phone: 210-833-1826
Email: anair@alitek.com
Website: alitek.com

From: eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com>
Sent: Tuesday, August 29, 2017 2:29 AM
To: eLink Recipient
Subject: RE what is the lifetime of a token in a load-balance environment 2 2

RE what is the lifetime of a token in a load-balance environment 2 2

Posted by Chagani, Munir On 08/29/2017 03:27 AM

Hi Kyle, I have the same issue. On Production environment, when I get the authentication token from Server A via CWS, it does not work with doc management calls (CWS) on Server B. However we have the same setup in QA environment where the token works perfectly fine regardless on which server it was generated. We have confirmed the settings "func=admin.securityvars" are similar on both front ends. Any idea on this issue?Quoted Kyle Swidrovich on 08/29/2017 05:27 PM:

One additional point I will mention here is that your instances that interact with your load balancer will need to share common security settings (like your encryption keys).

If not, a token generated by Server A may not be able to be decrypted by Server B.

Regards,

Kyle

[To post a comment, use the normal reply function]
Topic:	what is the lifetime of a token in a load-balance environment
Forum:	Content Web Services Forum
Content Server:	Knowledge Center CS16

Confidentiality Note: This message contains information, which may be privileged or confidential, or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee responsible for delivering the message to the intended recipient, you are hereby NOTIFIED that any dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you receive this message in error, please notify sender immediately.