Using the REST API - simple authentication

I am trying to use the CS 10.5 REST API to do a simple authentication of a user in Javascript. My code is:

function fAuthenticateUser ( ) {

var xmlhttp = new XMLHttpRequest();
var strPath = "http://ecm-dev/livelink/livelink.exe/api/v1/auth";

xmlhttp.open('POST', strPath, false);

var myBody = 'username=;password=';

   xmlhttp.onreadystatechange = function () {
      if (xmlhttp.readyState == 4) {
         if (xmlhttp.status == 200) {
              alert('done. use firebug/console to see network response');
         }
      }
   }

   // Send the POST request
   xmlhttp.setRequestHeader('Content-Type', 'text/xml');
   xmlhttp.send(myBody);

alert(xmlhttp.responseText);

}

I am getting back the following error:

500 - Internal server error - There is a problem with the resource you are looking for, and it cannot be displayed.

I get the same error whether I leave the username / password blank (I'm trying to use integrated windows authentication) or put in a valid set of credentials.

Any input on why I'm running in to this error would be much appreciated. Thanks!

Find more posts tagged with

Comments

Ferdinand Prantl

1. Separate parameters by ampersand and URL-encode the values; this probably caused the 500 status:

  var myBody = 'username=' + encodeURIComponent('your_username') +               '&password=' + encodeURIComponent('your_password');

2. Set the form-encoded content type and that you expect JSON response; CS probably ignores it, but let's be correct:

  xmlhttp.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');  xmlhttp.setRequestHeader('Accept', 'application/json');

3. Prefer asynchronous mode not to block the UI thread; continue after the request is complete in your onreadystatechange function:

  xmlhttp.open('POST', strPath, true);

Pramod Mohandas

Hi Simon,

I have attached a sample HTML file that does basic authentication against a CS URL for a given username/password. You may want to try it out and see if it helps you.

- Pramod Mohandas

Simon_Weekley

Thanks for the response Ferdinand.

Now my function looks like:

}

function fAuthenticateUser ( ) {
   var xmlhttp = new XMLHttpRequest();
   var strPath = "http://ecm-dev/livelink/livelink.exe/api/v1/auth";
   xmlhttp.open('POST', strPath, true);
   var myBody = 'username=' + encodeURIComponent('') +
                '&password=' + encodeURIComponent('');
   xmlhttp.onreadystatechange = function () {
      if (xmlhttp.readyState == 4) {
         if (xmlhttp.status == 200) {
              alert('done. use firebug/console to see network response');
         }
      }
   }

   // Send the POST request
   xmlhttp.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
   xmlhttp.setRequestHeader('Accept', 'application/json');
   xmlhttp.send(myBody);

alert(xmlhttp.responseText);

}

Now I'm getting a Windows Security prompt to log in to the web server (but Cs105 is running with Windows Authenication, so no idea why that would be). And I get the same behaviour whether the actual credentials are present in myBody or not. Very frustrating. Any ideas?

There seems to be a real dearth of documentation and sample code available for the REST API, which is a shame as it looks like it would be very useful. Thanks

keithgagne

I have the same issue using REST. I use Content Server Directory Services 10.5 to sync with Active Directory so the site is set for Windows Authentication. Does anyone have an example for authticating using that method?

Thanks,

Keith

Appu_Nair1

Syncing users from AD is not the same as authentication. When a SSO in IWA is happening the way it works is like this

<![if !supportLists]>1. <![endif]>User clicks a IWA protected resource such as the LL website http:<>/llisapi.dll (this is not OT code standard web transmission)

<![if !supportLists]>2. <![endif]>Webserver checks for REMOTE_USER in header(this is not OT code standard web transmission)

<![if !supportLists]>3. <![endif]>If present a exchange(Kerberos check) is done, if you do a fiddler at this time you will see a momentary exchange(401 checked and passed thru) (this is not OT code standard web transmission)

<![if !supportLists]>4. <![endif]>The user is allowed access to the script(llisapi.dll/livelink.exe) etc (this is not OT code standard web transmission)

<![if !supportLists]>5. <![endif]>The Livelink code gets this .You will see REMOTE_USER in livelink logs.(?func=admin.testargs shows you the raw request in a anonymous webserver you will see that blank, in IWA you will see domain\userid)

<![if !supportLists]>6. <![endif]>If this userid is in KUAF (over several years OT has made many improvements) LL will take this guy as authenticated and if the Object’s ACL(LL stuff) passes the user in.

The reason why I say this to Keith Gagne is for many years we had SSO with Directory Services module. Our users were created using oscript code. Not using Directory Syncing or LDAP filters.

Synchronization is executing a AD query and creating users in livelink .The SSO itself is handled by a setting in your browser Tools->Internet Options->Security->User Authentication->Logon

This allows for that automatic feel(a.k.a avoiding the windows pop up). Browsers like Firefox you can change the domain user and put the password and can get in to livelink as another user, provided

You know the other guy’s password)

Look for a example by Alex Kropp who shows you how in a IWA realm how search can be done. In myblog I think I have done some SSO experiments in SOAP and I think this search thing

What I remember OT folks saying is for REST unless the developers had made allowances to handle IWA .I also think developer.opentext.com is the one stop shop for everything REST API.

If examples are not helpful pressurize that product managerJ Sometimes they listen.

PS:I am a livelink developer/Admin and not a network person so my definition may not be accurate totally in that sense, but I know my authentication stuff very nicelyJ

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Wednesday, January 04, 2017 9:17 AM
To: eLink Recipient <devnull@elinkkc.opentext.com>
Subject: [EXTERNAL]RE Using the REST API - simple authentication

RE Using the REST API - simple authentication

Posted by Gagne, Keith On 01/04/2017 10:11 AM

Thanks,

Keith

[To post a comment, use the normal reply function]
Topic:	Using the REST API - simple authentication
Forum:	Content Server Development Forum
Content Server:	Knowledge Center CS16

Ferdinand Prantl

If you get HTTP status 401, although you provided a correct ticket or correct credentials, it could be sent by IIS and not by CS. You could confirm it by inspecting CS logs. It could happen, for example, if you enabled IWA on the CS CGI directory and disabled anonymous access. CS REST API will not work in this case, unless you authenticate the request for IIS too.

You can do one the following:

1. Enable anonymouis access on the CS CGI directory.
2. Create another virtual directory for CS REST API clients, for example "/rest/" and enable anonymouis access on it.

There is another option, which does not work universally:

3. Let the AJAX call send also cookies or other request headers. It will punch through the IWA, but you still need to authenticate CS REST API by its authentication ticket.

If you open the page in IE10+ and you if you are already looged in to CS Classic UI, you can have the IWA authorization headers sent to the server by setting the following flag before sending the request:

  xmlhttp.withCredentials = true;

Notes:

CS REST API does not authenticate automatically by cookies or other request headers to prevent XSRF. You need to set an authentication header explicitly, when you make the request. The web server serving CS REST API should accept anonymous requests, so that CS itself is able to authenticate the client.

When you implement a page calling CS REST API, the portal hosting the page should authenticate to CS (preferably by SSO). When the page is generated on the server, you should write an authentication ticket to the script making the CS REST call.

Ferdinand Prantl

CS REST API requests are not authenticated by IWA. You need to set a supported authentication header explicitly. See my previous post in this thread for more information.

keithgagne

Thank you Appu and Ferdinand for the information. It was very helpful. I am using a separate website configured for anonymous access and my sample code is working fine. I can request the ticket and use it to interact with Content Server, for example to request a node. However, this only works for the Admin account. I tried creating a separate user in Content Server, and gave it full Admin rights. I verified I can login to Content Server through the GUI and access the node with no issue. I am unable to get a ticket for this user through REST and get a 403 error - Forbidden: Access is denied. You do not have permission to view this directory or page using the credentials that you supplied.

Does only the Admin account work with REST, or do I need to configure something to allow other accounts the ability to use REST?

Appu_Nair1

What is your experience as a trial if you do this

Create a application that is side by side your existing livelink cgi.For kicks call it otcs_stdauth.In its authentication of IIS make it anonymous.Now login to that url somethink like this http://<keith Gagne's server>\otcs_stdauth\llisapi.dll .Does a Livelink Login Screen come or does it look like a OTDS screen?
Create a non synchronized or manual user in OTDS or if not using OTDS a simple user and give it a password.
Can that user login to the alternate CGI?
Can that user now execute the http://<Keith Gagne's server>\otcs_stdauth\llisapi.dll\/api/v1/auth if possible run thread logs on your server and see if LL got the request and is spitting any errors.

My understanding when I looked at the authentication I see OT explicitly re-checking using a login call back and throwing away the request which is surfaced to the browser as a 500. It is as if Ferda said "we will not allow you to come in as IWA".Maybe the smartUI code may be by passing this restapi check.That is for another day.

keithgagne

Here are my results:

1. Created otcs_stdauth and made it anonymous in IIS. Accessing the url brings up the normal Livelink login screen.

2. Created a local restuser account in Livelink and gave it a password.

3. The restuser is able to login manually to otcs_stdauth Livelink using the url and web page gui.

4. The code errors when using restuser against otcs_stdauth with a 403. Fiddler shows the 403. IIS logs show 200 no issues. Livelink debug logs show the connection coming in with the restuser to otcs_stdauth and then an error:

Dispatcher error: The server is configured for an external authentication. Sign in to the configured identity provider.

This does not make sense to me because when I change the code to use the local Livelink Admin account, everything works fine.

We do not use OTDS. We use the older one CSDS or whatever the previous Directory Services module was called. We have sync jobs run overnight that LDAP query Active Directory and create/disable Livelink accounts based on comparison. Users do not have to enter credentials when accessing the system.

appuGmail

I am guessing totally but that sounds like the [Security ]section of your OT. Ini saying NTLM.

If you have an instance that will not do SSO check its [Security ] section it probably should be saying Livelink

Run your restapi code on that box with the restuser and password

Otherwise post LL version and I could check on Monday and report back I tried everything on a CS16 with OTDS

BTW Admin has special consideration in many places of livelink code . Usually things working with that ID may not reflect how other users is treated . To make SSO work with Soap I was given 2 directory services patch so sometimes you have to debug code or elicit help from OT.

Ciao, Appu

On Jan 5, 2017, at 7:31 PM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

eLink : RE Using the REST API - simple authentication
RE Using the REST API - simple authentication Posted byGagne, KeithOn 01/05/2017 08:27 PM

Here are my results:1. Created otcs_stdauth and made it anonymous in IIS. Accessing the url brings up the normal Livelink login screen.2. Created a local restuser account in Livelink and gave it a password. 3. The restuser is able to login manually to otcs_stdauth Livelink using the url and web page gui.4. The code errors when using restuser against otcs_stdauth with a 403. Fiddler shows the 403. IIS logs show 200 no issues. Livelink debug logs show the connection coming in with the restuser to otcs_stdauth and then an error:Dispatcher error: The server is configured for an external authentication. Sign in to the configured identity provider.This does not make sense to me because when I change the code to use the local Livelink Admin account, everything works fine. We do not use OTDS. We use the older one CSDS or whatever the previous Directory Services module was called. We have sync jobs run overnight that LDAP query Active Directory and create/disable Livelink accounts based on comparison. Users do not have to enter credentials when accessing the system.
[To post a comment, use the normal reply function]
Topic: Using the REST API - simple authentication
Forum: Content Server Development Forum
Content Server: Knowledge Center CS16

keithgagne

I am running 10.5 patched to release 2014-06. I have not yet installed SP1.

I tested all combinations of Windows/Anonymous authentication in IIS, NTLM/Livelink Authentication in opentext.ini, Admin/AD User/Local User. I can conclude from my testing that only the Admin account works with REST services.

Admin will work with both Windows/Anonymous authentication in IIS when opentext.ini is Livelink.

Admin only works with Anonymous when opentext.ini is NTLM.

No other user accounts, whether local Livelink or AD account, work regardless of IIS and opentext.ini authentication.

I will open a ticket with OT Support to see what the offical declaration is. I find it hard to believe that REST will only work with the Admin account so I must be missing some other configuration.

Thanks for all your help Appu and have a nice weekend!

Ferdinand Prantl

There is no extra privilege to be granted for users to enable their authentication for CS REST API. Every user, which can log in to CS UI should be able to authenticate a CS REST API call.

I have no CS 10.x to test with, but I have a user on my CS 16.0.3, which was imported from my external OTDS and using "POST /suth" with this user gives me a valid ticket.

What you describe looks like a bug to me.

Ferdinand Prantl

I don't know, whether CS REST API have ever been tested with CS Directory Services module. I know of tests with OTDS only. You can ask OT Support if CS DS & CS REST API is supported.

Kyle_Swidrovich

There's a known issue with username/password pair auth with a 16.0 system migrated from an earlier system using CSDS if authenticating via the REST API (LPAD-51051).

This will be resolved in the 16.0.4 update (March 2017).

keithgagne

Well that explains it. Thanks for the information, Kyle.