OTDS RestAPI with Windows Authentication

We are using CS with OTDS that contains the Windows AD users. When accessing CS no login in necessary because of the windows integrated authentication. Can I authenticate in a similar way with OTDS though the RestAPI to get a ticket for further use for the API?
I have seen the POST /authentication/credentials method which is working fine, but requires the password. I would prefer to use the "windows integrated authentication", because of course I do not have the AD password.

The Application is Not in Content Server Context, but an "external" separate application.

Thanks,
Hannes

Find more posts tagged with

API

OTDS

Comments

Ferdinand Prantl

What application do you make the CS REST requests from?

Matthew Barben

**If you are using the CS RESTful API from a Content Server context, you can read in the LLCookie value. To make the job reading the cookie a little easier I tend use the JS-Cookie library https://github.com/js-cookie/js-cookie that way you can return the auth token in one call:

var auth = Cookies.get('LLCookie');

Hannes Eichner

I would make the REST calls from a Web Application either from JavaScript or from Server Side Java Code (But I believe only JavaScript will be possible since the windows authentication can only work on the client, correct?).
The application is NOT in a Content Server context.

Thanks,

Ferdinand Prantl

CS REST API connections are not authenticated automatically by IWA to avoid a possible XSRF. The application, which wants to make a CS REST API connection, is responsible for authenticating the user amd thus making him aware that some resources, like the CS, will be accessed with their credentials. The application or web portal can utilize the SSO, if desired. But a REST API itself should not.

If you make the CS REST API connection on the server side, you can use the user impersonation. You will need to store securely credentials of a CS user with system administration privileges on your server. You will need to know the CS login name of the user on whose behalf you are going to make the connection.

If you make the CS REST API connection in the browser, you will need the help of the application or portal, which server the web pages. The application is responsible for authentication the USER and obtaining access tokens to the needed resources. If you serve the page by JSF/JSP, you could obtain the OTCSTicket on the server side, like in the server-to-server scenario above, and render a <script> on the page exposing this ticket. However, there is a better solution. The SSO for the CS is usually implemented by the OTDS. You get authenticated by the OTDS in your portal, using all its possibilities, like IWA or ADFS integration, and you will get the OTDSTicket. You will need to generate it on the web page on the server side and you can use it from the browser for CS REST API; it accepts the OTDSTicket header too.

About the cookies: You should not rely on an authentication cookie accessible from JavaScript in the browser. Everyone, who cares about security, will enable http-only cookies in the CS Administration to make them inaccessible from the JavaScript in the browser and thus be immune against CSRF.

Hannes Eichner

Thank you Ferdinand, that helps me.
Regarding your below point, is there any recommended way how to store the credentials? I can imagine that storing them in compiled code is a bit better than cleartext, but still it is not 100% safe.

You will need to store securely credentials of a CS user with system administration privileges on your server

Ferdinand Prantl

I think that the safest secure stores, which do not need user interaction when the store is opened (when your server is started), are provided by the underlying OS. For example, there is DPAPI on Windows, which allows you to write/read the sensitive data only by the same (server) user, which runs your application, or only on the same machine, where your application runs.

Compiling the password with the source code would turn up inflexible quickly, when you wanted to change it. Storing passwords in a file with very limited access is quite usual. Plain text, or using a symmetrical cipher with a key hardcoded in the application source code. You can start with it and switch to some secure store later.

Yet another possibility would be to establish the server-to-server trust between your application server and the CS by some certificates maintained locally on both servers, so that the impersonation would not need a system administrator credentials. But it would mean an extra development on the CS server side.