Login to CS / OTDS without providing password in SSO environment

Hello Experts,

I couldn't find a post on getting OTCS ticket from OTDS in SSO environment without providing password, if there is such, I apologize for duplication. Now back to question:

We have SSO setup with Azure AD, when users logs in to CS, call is redirected to OTDS, which it then redirects to Azure. Our environment is setup in a such way that Azure doesn't prompt for credentials (it takes logged-in user as the user name and our local AD authenticates that user without prompting for a password), once token is sent to OTDS, OTDS i believe then creates OTCS ticket and redirect user back to CS.

We are trying to create a script in PowerShell to download a file from CS, in order to do that, we need to authenticate it first. Now question is how to do it? All the REST APIs that I have came across requires username and password. We are ideally looking for a REST API call which grabs the logged-in user as a username and doesn't need the password (Just FYI I have tried providing username and password as well but didn't work - my understanding is that REST call only works for CS internal users). I then came across following OTDS REST API:

https://developer.opentext.com/awd/resources/apis/otds-16#!/authentication/authenticate_get_1

This REST API returns OTCSTicket if you are already logged into the client, in our case, we are logged-in yet!

Any folks have tried this scenario before? sounds like a very common scenario; a user needs to download a file from CS in SSO envrionment.

I know i can impersonate user too but that would be my last resort plus i am not comfortable of having admin password within the script (https://knowledge.opentext.com/knowledge/llisapi.dll/kcs/kbarticle/view/KB8295770)

Any suggestions, hints would be greatly appreciated.

Thanks,
Aftab

Find more posts tagged with

Comments

AftabShaikh

Any update folks, can someone from OT; David Templeton, Steve or Ferda can provide their valuable feedback.

Ed Davis

Did you ever get this to work? I agree that it should be a common scenario. I have also looked far and wide for the answer. I see that there is references/examples to OTDSSSO which seems to be a misnomer as it also requires Username and Password. I also observed that the Smart UI default home endpoint "App" grabs the ticket with the connector.authenticator.updateAuthenticatedSession call. Kind of disappointing that the OT folks didn't chime in.

sıɹɥɔ

Hi Aftab,

You likely want to perform a GET to your OTDS at /authentication/headers

There's a Knowledge Base article titled "How do I authenticate my SOAP / REST application via Single-Sign-On / Tokens?" that addresses this, at:

https://knowledge.opentext.com/knowledge/cs.dll/kcs/kbarticle/view/KB9605051

JPepper

If you want to do this via SAML and OTDS is configured for SAML to Azure you'll need to first obtain the SAML response from Azure using their API's and then if applicable Base64 encode it with purely ASCII characters (no escaping) and post it to /authentication/token.

As noted above if you have Kerberos enabled for OTDS as well and want to use that /authentication/headers will work as well.

Ed Davis

Thanks, I will have to experiment with both methods.

My use case was running REST API calls from .html apps. I use WebReports wherever I can with the [LL_REPTAG_OTCSTICKET QUOTE /] call in the AJAX, but one of the problems was that is that web reports isn't very relative URL path friendly.

If the relative path in for a .js lib is for example:

In a Web Report, unless I add it to the /img (Support Directory) on the server or Support Assets Volume and adjust the path, or I have to translate it into a fetch to use it locally:

The other big problem with .html is that you don't have access to the WR tags (e.g. "[LL_REPTAG_OTCSTICKET QUOTE /]),[LL_REPTAG_USERID /] etc. )

As the apps get more involved/complicated and add more .js and css resources and third party libs, it is easier to use .html. So currently for SSO authentication I use a PROXY WR to launch the .html app and add the WR parameters that I need. I don't want to embed USERNAME/PW's via JS.

For example, this small 3 line WR snippet, gets the USERINFO, TimeStamp INFO and the OTCSTICKET and sends them as parameters to the .html where I can use them for populating fields and for the AJAX GET and POST calls:

*************** START OF WR ***************

[LL_WEBREPORT_EXCLUDEHTML /]

let mTicket = encodeURIComponent([LL_REPTAG_OTCSTICKET QUOTE /])

let mURL = 'https://myCSserver/otcs-sso/llisapi.dll/fetch/5405556/-/form.html?nodeid=5402812&vernum=-2&clTicket=' + mTicket + '&clUserName=[LL_REPTAG_USERID USERINFO:FIRSTNAME /] [LL_REPTAG_USERID USERINFO:LASTNAME /]&clDateTime=[LL_REPTAG_DATETIME DATE:"%Y/%m/%d:%H:%M:0" /]&clUserID=[LL_REPTAG_USERID /]'

window.open(mURL,"_self")

</script>

************** END OF WR ******************

on the JS/AJAX side we have:

let mTicket = "";

let mUserID = "";

let mUserName = "";

let mDateTime = "";

const queryString = window.location.search;

const urlParams = new URLSearchParams(queryString);

mUserID = urlParams.get('clUserID');

mTicket = urlParams.get('clTicket');..

mUserName = urlParams.get('clUserName');

mDateTime = urlParams.get('clDateTime');

....

and the authentication within the AJAX call:

beforeSend: function(xhr) { xhr.setRequestHeader('OTCSTicket', mTicket); },

Because the documentation and examples are so lean from OT or within the forums, it's trial and error unless you get lucky with a answer from one of the forum participants.

Thanks again,

Prasad Kukkala

Hello Team,

I acknowledge that I am responding to almost 4 years old discussion, however, we recently faced a similar issue with a customer involving Azure AD. I am sharing the details of the solution here in the hope that it will be beneficial to others who come across this discussion thread.

I am pleased to inform you that the issue has been resolved following an update to the local security policies in the Active Directory. We observed that the customer has various domain local security policies that differ according to operating system versions, vendor virtual desktop infrastructures, branch desktops, laptops, and other factors. Users experienced difficulties with automatic logins due to Kerberos authentication failures, which resulted in repeated login prompts. This situation was attributed to the network security policies established in the Domain Controller.

Resolution Steps followed:

Open Active Directory Users and Computers (dsa.msc).
Locate the relevant policy.
Navigate to Properties → Account Tab.
Ensure that Kerberos AES 256-bit encryption is checked.

Regards, Prasad.