CS REST API and Authentication
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?
Comments
-
The typical scenario looks like this:
- You log in to your application portal (CS, SAP, Oracle, SharePoint, ...), which gives you a token.
- 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. - 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:
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.OTDSTicket
- provided by OTDS. You should start using theOTCSTicket
from the following requests, becauseOTDSTicket
validation is slower and the ticket itself can be configured for a once-only usage.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)
.- 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.
0 -
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:
- IWA forced: https://host/otcs (used in the browser to open pages: https://host/otcs/livelink.exe?func=llworkspcace)
- Anonymous allowed: https://host/otcs-api (used for the API requests: https://host/otcs-api/livelink.exe/api/v1/volumes/141)
0 -
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.0
Categories
- All Categories
- 117 Developer Announcements
- 52 Articles
- 146 General Questions
- 136 Services
- 56 OpenText Hackathon
- 35 Developer Tools
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 912 Cloud Fax and Notifications
- 82 Digital Asset Management
- 9.3K Documentum
- 30 eDOCS
- 173 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 6 XM Fax