OTCS RestAPI: how to authentication a user which is in an Async Partition with SAML2.0?

Pedro Amaral

Hi guys,

When I access OTCS, SSO happens with SAML2.0. So far so good.

Problem: When I try to use the OTCS RestApi (api/v1/auth) I always get "invalid username/password specified". I tried all the combinations playing around with the account domain, but can't find a way to make it work.

Note: The request works fine if I use a user from a LDAP Synched Partition, so it's not the syntax. I suspect it has to do with the SAML2.0 authentication handler.

Any hints?

Cheers

appuq

what you say Async partition is that what OT calls a Non-Synchronized?

A non Non Synchronized user just means the user is known only to OTDS and the user has been created using APIs inside the Livelink(OTCS) database. If you go to OTCS and try to find the user it should exist. you can use the users&groups function to find the user or the table KUAF.OTDS creates the nonsync and synchronized users using soap API (now may have a rest equivalent).I would first check that and then the resources (like CS) should be available to the partition. The non-synch user should exist in one of the 4 places like otexternalid 1 through 4. The OTDS logs should indicate successful login to the OTDS application and the difficulties that the downstream app does.

If nothing works create a session using a user like otadmin@otds.admin(any user with System Admin privs) and impersonate the smaller user if that works then the smaller user is known to livelink

I always pass OTDSTicket to rule out such difficulties, OTCS is coded to accept one of the tickets…

appuq

BTW in some organizations using IIS as the webserver for Livelink many times the admins will place the OTCS application as IWA because that is the default.OTCS regular users will not have any problems because OTDS will accept the Kerberos ticket. However, OTCS REST API is designed only to accept a header like OTCSTicket or OTDSTicket so I would cross-check if the OTCS application is wrongly pointing to IWA. if you put fiddler and you see your restapi getting an IWA challenge I would cross-check that. Many administrators are averse to changing things that work so it is usual practice to define another application entry point for restapi.To OTCS whether IWA or anonymous it doesn't matter

Another aspect to check is if the non-sync partition has access in the Access Roles .The way OT wants you to think is OTDS is a collection of Users coming from LDAP or others and then there are resources(OTCS,DAM, SAP etc etc) .The access roles says this user in that partition has access to the resource:)

Pedro Amaral

Hi, you are right, Non-Synched partitions, sorry for the confusion.

Thank you for your hints, I also found an article about that with the same explanation.

I leave the article here, in case someone else has the same questions:

https://support.opentext.com/csm?id=search&spa=1&q=KB0547616

As not, to your comments, everything is working perfectly well OTDS wise, I just need to check the IIS as you suggested.

Pedro Amaral

Hi @appuq ,

while looking into this more carefully, I'm not sure how this fits.

1. IIS is configured properly, no IWA is used
2. The users in question sit in a nonsync partition
3. OTDS has an SAML2.0 authentication handler for these users
4. When accessing via browser…
   1. user opens OTCS
   2. user is redirected to OTDS
   3. SAML2.0 Authentication handler is used, the browser is redirected to login.microsoftonline.com
   4. user is correctly authenticated, redirected back
   5. user ends in OTCS with a correct ticket
5. When accessing via RestAPI
   1. immediately "invalid username/password specified"

Now the challenge is how to configure the system to allow these users to access OTCS RestAPI.

According to a colleague, this is not possible directly via OTCS RestAPI because the authentication authority is not OTDS.

The technical steps to be executed, according to him, are:

1. do authentication against Authentication Authority, retrieving the token
2. go to OTDS, using the token above, and get an OTCS token

Then the OTCS RestAPI can be used.

appuq

That is because when the RESTAPI is received in Oscipt it explicitly looks for an OTCSTicket or a OTDSTicket so that is what I would probably do. Explained as a postman sequence

• Hit the authentication of OTDS(not the CS AUTH) you should be able to test this in your OTDS server restapi endpoint, start with something known as a userid/password, and look at its output you will most likely see an OTDSSSO******** thing. This is what Livelink/Content Server CGI REST API needs
• Execute a REST API with that ticket passed as OTDSTicket it will work….
• OpenText has even included a basic auth command so you will be able to even hardcode a userid: password with your API testing most likely you may have to base64 encrypt the userid:password what I am talking about is the most unsafe way an IISwebserver can be done so many organizations will not allow it and it is to allow RAD against CS one can almost say bypass OTDS while developing

Once you are happy with the above example you should now try to work the real requirement which is something out on the web that gave you an OAUTH convert that to an OTDSTicket and you should be able to get it going(I see an OT employee tag so you should be able to harness tonnes of your inside colleague goodwill)

I am not aware of OTDS giving an OTCSTicket perhaps your colleagues meant what I said OTDS is actually tasked with issuing tickets against a resource like OTCS, in your case, it may be the one that starts with OTDS****or the video Jeremy Pepper posted(thank heavens he was helping us before he left)

again if the SmarTUI is correctly working in your scenario you can also look at the way it performs authentication.I think it actually is doing the same thing that a external developer does with REST

Greg Griffiths

you should be able to use PostMan, or similar, to see what is send in the JSON to see if the date/time and offset are passed there correctly to help identify if its an OScript or SmartUI/JS issue.

Pedro Amaral

Hi Greg,

it's not an issue, it's by design :)

Since my initial post I've been gathering info here and there… user/password authentication seems to be possible only when using LDAP Credentials authentication handler.

Using SAML, you need a browser to complete the flow (browser redirects happen).

Using oAuth2.0, you need to decide which flow to use. For service accounts, one needs either a certificate or a clientID/clientSecret.

Whatever is the case, it seems there's no easy way, because both SAML and oAuth2.0 add much more security to the whole login process.

I'll keep this thread posted as soon I found more about it!

Greg Griffiths

thanks for the update, and look forward to future updates :)

The PostMan check was about the date included in the JSON response that was posted earlier.

appuq

If the authentication works for the user in non sync using the SmartUI then it is actually doing REST API calls. The Jeremy Pepper example shows this flow with OAUTH2 so the authority in his example is Google and he gets a Ticket, he converts that ticket into something that OTCS understands like

it will say OTDSSSO*. I think you are missing that action and trying to think that calling the Oauth to Microsoft is all you have to do.This OTDSSSO is akin to you asking otds with a userid/password(or in saml kerberos)

If you do not want to use this you can simply use Impersonate

perhaps this is an old thread I could not find Jeremy Pepper's video https://support.opentext.com/community?id=community_question&sys_id=78eb3b991b18d51022d432a3cc4bcb20&anchor=answer_8869b52d87d49910781b0ed8dabb3530&view_source=searchResult

appuq

I found the article perhaps you can try this and see if you get going

https://forums.opentext.com/forums/developer/discussion/comment/962781#Comment_962781

https://support.opentext.com/csm?sys_kb_id=d9e03dd297753990a72255b00153afb8&id=kb_article_view&sysparm_rank=1&sysparm_tsqueryId=c95c0d7e87cc42d014057488cebb3589