Running web services as browser user

We are currently writing some integration between Content Server 2010 and a backoffice application. The integration is in the form of a C# .Net web application, which basically runs some searches and retrieves document results / documents.

The code for this is finished and currently runs using a dedicated 'integration' user CS account. However we would like to run the code using the windows user logged into the web application/browser instead.

Is it possible to authenticate a windows user directly using CWS, if you only have the windows username available rather than that and the user's windows password ? We don't want them to have to login or prompt for it.

Or, or do you have to use a dedicated CS user with Admin rights first, authenticate that user using OTAuthentication (and get the token in usual way) then impersonate the windows user account instead via CWS?

many thanks

John

Find more posts tagged with

Comments

Appu_Nair1

I just finished testing IWA code with Livelink CS10 Update 10.IWA did not work off the box so I had to contact OT support and they gave me two patches to make it work.We did not deploy OTDS(RCS) the Tomcat based solution here.We don't have any big integrations here so CSDS will suffice for us and less head aches.

In a nut shell this is what you will have to do.

Create a webservices application and test its working in the normal way .meaning the IIS website is running as anonymous.Once everything looks correct you proceed like this.
The Web.Config that comes bundled from OT is expecting an 'anonymous' scheme.You have to change the places to basically become windows authentication.In my blog livelink.in I have put up several config's and even this info.In this forum Guy Pomeleaux also has the same info.If you saerch the web the WCF pundits say the same thing.
You then make the application an authenticated one,meaning take off anonymous and make it IWA.
I configure IIS for IWA in my job so it is pretty much the same way for webservices as well.A knowledge of IIS is probably a good one.

Unfortunately I do not know how this would work if webservices were in tomcat.Mark simm has posted how you would trap REMOTE_USER when Tomact and IWA is encountered.AFAIK this may be easier if you use OTDS but getting it to cooperate would be the biggest challenge

John_Henderson

Thanks Appu.

We are ok setting up IIS application side as we run many apps with windows authentication, it's more what code options are available via CWS to authenticate a windows user in CS within the CS web services themselves.

Appu_Nair1

You always had the impersonate method which passes off as SSO for many people.

basically to use the challenge method you need two things

The app should do the authentication that is what IWA does for you.It takes care of the vetting betwwn a domain controller or AD(LDAP) service
Secondly livelink should be smart to understand this is a authenticated user and should have code to use REMOTE_USER.In the new CS10 code base you have webserver authentication for free,but that does not get you in a programmatic way .that is where additional code like CSDS or OTDS should come in.

My experience in CS10 Update 9/10 was very easy for IWA although I had to look in builder in my initial attenmpts to figure what was going on

Ferdinand Prantl

The OOTB CWS or RCS provide the latter option that you mention. First authenticate as (any) sysadmin, then impersonate for other user. You impersonated code must run in a trusted context, of course, using the sysadmin's credentials, and acting on behalf of other user.

var authenticationToken = authenticationService.AuthenticateUser("sysadminusername", "password");// Store the initial sysadmin's token to the service object.var authenticationToken = authenticationService.ImpersonateUser("browserusername");// Store the final browser user's token to the service object and to other service objects too.// If you deploy RCS later, it breaks CWS authentication. Use the RCS CAP authentication// service instead and continue using the rest of CWS as usual. While the authentication// token handling is the same the interface of the authentication service is different.authenticationService.Authenticate("sysadminusername", "password", "");authenticationService.Impersonate("browserusername", authenticationToken);// Storing of the authentication token to the service object - the same for CWS and RCS.Authentication.OTAuthentication authenticationValue = new Authentication.OTAuthentication();authenticationValue.AuthenticationToken = authenticationToken;authenticationService.OTAuthenticationValue = authenticationValue;

If you wanted to avoid storing and using sysadmin's credentials from your application server, you could write a plugin for the CS or OTDS which would trust your service originl and return the browser user's token. The trust, which you currently base on sysadmin's credentials, could be based on deploying and using a certificate pair in a secure way on your application server and CS/OTDS, for example. (I'm not sure if OT documents and/or supports this for the partner developers too.)

Both options are used in various OT products, AFAIK. The sysadmin's credentials method is easier to implement for the developer - no plugin on the CS/OTDS side - while a method not requiring the sysadmin's credentials is easier for the customer - no need to ask the CS administrator to type the password in your (suspicious) configuration, no problems with password changes.

--- Ferda