CS REST API and Authentication

Louis_Legakis

I'm a bit unclear on authenticating with the CS REST API.

For example, if my Content Server (https://host/otcs/livelink.exe) is accessed using Integrated Windows authentication i.e. the Web server is handling the authentication on the "otcs" virtual directory, how can a client (that uses the CS REST API) directly access (SSO) the API (https://host/otcs/livelink.exe/api/v1/..) with an OTCSTICKET when there is a requirement to first authenticate with the Web server.

What are the best practices for this?

Ferdinand Prantl

The typical scenario looks like this:

1. You log in to your application portal (CS, SAP, Oracle, SharePoint, ...), which gives you a token.
2. The CS which you want to connect to trusts the identity provider that the application portal uses, thus you can reuse the token for the access authorization. For example, if you have OTDS, the OTDSTicket is accepted by the CS REST API.
3. If CS doesn't trust your identity provider OOTB, you will have to implement the relay according to your environment. For example, a Login Callback on the CS to accept a WordPress token. Or the other way round - write a plug-in for your portal to get the OTCSTicket on the server side when the portal authentication takes place.

APIs used asynchronously from the web browser do not provide an automatic authentication. With Kerberos/NTLM it is not even technically feasible. Also, it is not considered safe; the user should intentionally authorize an (web browser) application (page) to act on behalf of them.

The CS REST API supports authentication based on HTTP headers, which can be:

1. OTCSTicket - provided by the /auth resource for user credentials. It behaves (expiration, for example) like the LLCookie. Every request returns a refreshed one, so that the often communicating client doesn't need to take care of its expiration.
2. OTDSTicket - provided by OTDS. You should start using the OTCSTicket from the following requests, because OTDSTicket validation is slower and the ticket itself can be configured for a once-only usage.
3. Authorization - Basic Authentication supported by APIs you have ready in the web browser and by command-line tools and libraries like curl, for example. The format of the header value is "Basic " + to_base64(username + ":" + password).
4. Other headers - for example, the SAP token (MYSAPSSO2) is supported OOTB by OTDS & CS to improve the integration with our important partner.

You will find code samples using jQuery and CS UI Widgets in this forum.

Ferdinand Prantl

Note: If you use IIS, you cannot turn IWA on the CGI URL used for the CS REST API. The virtual directory serving the REST API has to allow anonymous requests. If your current virtual folder serves only the CS pages and that's why you configured IWA to get the most convenient SSO, you will have to configure another virtual directory for the REST API. For example:

1. IWA forced: https://host/otcs (used in the browser to open pages: https://host/otcs/livelink.exe?func=llworkspcace)
2. Anonymous allowed: https://host/otcs-api (used for the API requests: https://host/otcs-api/livelink.exe/api/v1/volumes/141)

HFCDev

Hi,
I saw in the responses above, references to specific examples. Is it possible to post links to specific examples? In particular, I would like to see an authentication example for each of the various methods mentioned.

Ferdinand Prantl

The code to authenticate is actually the same for all options. The only difference is in the (name of the) HTTP header. You use the header and value according to what authentication information is available in your application. The header names are listed above. Two links to posts with samples using $.ajax can be found at another reply.