Workflow webforms, ajax and webservices

I would like to call asmx webservice from workflow webform using ajax... I have a few questions:

- what is the best way to implement security in webservice?

I have this theory..

On a webform I will get livelink cookie values and pass it as a parameter to the webservice. There (webservice) I will create a livelink session with the help of content server webservices with a cookie and if I succeed I will now the user is authenticated.

The problem is that I can not find a method in content server 10, that will authenticate user with a cookie as it did in version 9.7 when createing LLSession.

Also I would like to ask you if you see any flaws with that approach or maybe you know a better one.

Thank you very much for your help,

Danijel

Find more posts tagged with

Comments

Ferdinand Prantl

The scenario you describe should work as long as you have created the cookie for the machine that is going to use it. (You must make sure that this login-on-behalf-of cannot be exploited by an imposter.)

The call you use to talk to LL971 should be available in CS100 too. What is it?

--- Ferda

Carsten_Kulms

You could fall back to HTTP requests which mimic the UI or LAPI (which can be executed via HTTP also) _but_:The cookie is usually bound to the client's IP address thus your webservice will fail to authenticate with a cookie obtained at the webform.I do not know what the webservice will do and/or what applications it will access (there may be options if that webservice will work with another OT product) but it seems you will have design some secure protocol between the ajax code and your webservice to pass over the user information in a trusted manner. (Such probably requires encryption and a timeout on the 'token' or whatever is passed to the webservice.)Or, maybe you could leverage some external authentication respectively SSO solution. (Browser/user authenticates against that; CS and your WS container trust the SSO provider.)

Dejan Lipovec

Thanks for quick reply.....in 9.7 I could use (I haven't tried it yet)

public       LLSession (                String    host,                String    port,                 String    cookie		LLVALUE   config)..as you can see, the third parameter is cookie.....but I cannot find anything similar in cs10

Dejan Lipovec

Thnks for quick replay...

If cookie is bound to IP, then why is there a method bellow

public       LLSession (                String    host,                String    port,                 String    cookie		LLVALUE   config)that you can get LLSession with a cookiea nd not only with username and password...On a client side everything i have is a cookie...there is nothing else Livelink creates when creating a web form..do you think I have any influence on how livelink is creats web form so for example I can create some encoded string in hidden field so I can maybe put inside livelink token and then send it back with ajax and check that token?

Could you please tell me in more detail how did you imagine SSO trust solution in your last sentence. How would the service trust the SSO provider. I need to provide webservice with some authentication info..

thx

Ferdinand Prantl

I assume you pasted a ctor from LLSession from LAPI 9.7.1. You can continue using it against the server 10.0 too. The server implementation for the LAPI calls that were published for LL971 is still available in current server versions.

--- Ferda

Carsten_Kulms

Whether the cookie is bound to the client's IP address (or part of it) is a matter of configuration; the default is that the full IP address is checked.See That LAPI allows to use a cookie instead of name and password can be useful - a client has to authenticate by name/password only once and then throw away the credentials (wipe them from memory) so they cannot be observed. And of course it is possible to set up a system in a way that passing a cookie from one LAPI client to another works because they sit on the same machine (i.e. IP address; or the check was disabled--see above)Regarding SSO... since you mentioned "aspx" I can imagine you could leverage Integrated Windows Authentication (IWA). Content Server can be deployed to play nicely with that (requires proper Directory Services configuration, I think). I am not familiar with ASP.NET but after a quick look at the following pages I believe an ASP.NET application can use IWA authentication also:Introduction to ASP.NET and Web Forms ASP.NET Authentication IIS Authentication / Integrated Windows Authentication ASP.NET Web Application Security ASP.NET Authentication Using IIS Authentication With ASP.NET Impersonation This means: CS trusts the IWA authentication and 'sees' as user whatever IIS tells him.Your ASP.NET applications trusts the IWA authentication and 'sees' as user whatever IIS tells him.Both will be the same.If IWA is not possible (e.g. non-Windows clients) then another SSO solution/products may be applicable--if and what depends on details of your deployment and used technology.And, sure, you could start customizing Content Server itself--that would mean significant work (OScript development) and in case of security I recommend to try hard to leverage existing standard protocols and mature functionality / products instead of building something homegrown.

Appu_Nair

The latest livelink product probably Update 7 includes something for supporting "X forwarded for headers" which is something we wanted.Not sure if you can use that for your issue or not.With this in place the livelink administrator can designate in their OpenText.ini files a list of hosts which livelink will trust.So basically you can still have IP bound cookies but have a small exception list of computer whose cookies livelink will trust.Middle layer livelink service callers such as "RCS" or "ELIB Web Svcs" would benefit in this situation as the individual ip addresses of the RCS nodes will look to livelink as the same computer and will not need to re-authenticate.Just a thought I since I ran into all those issues with RCS and was not in a position to recommend changing the IP address bound to the user cookie.

Kyle Swidrowich of OT would be a good resource if you wanted to pursue that route.As Carsten mentioned if you have IWA in your aspx and livelink then they both will be trusted as "REMOTE_USER" so you will have no problems in your calls against authentication.

Carsten_Kulms

The support of X-Forwarded-For HTTP header was added in update 6.The corresponding setting is labeled "Trusted Proxy Server List" at the Configure Security Parameters page in the CS administration.However, its meaning / functionality is to enable the server to identify ('trace back') a client's IP address even if there are proxy servers between the server and the client.See e.g. http://en.wikipedia.org/wiki/X-forwarded-forOr, as it is described in the Content Server 10.0.0 Plus Updates Release Notes:A new feature, X-Forwarded-For, was added. This is a standard HTTP header used by web proxies to track the path of requests over a network. This feature allows Content Server to include the client's IP address in Content Server cookies for added security by examining the request path. The administrator can now add a list of trusted proxies. The request path is examined and the first IP not in the trusted proxy list is designated as the client IP.Thus this setting does _not_ help in this scenario: if the two clients' (user and external service reusing his cookie) IP addresses are different then the cookie cannot be shared between them. (If the IP address check has not been disabled. Btw: the new support of the X-Forwarded-For header now allows to enable this check in scenarios where this was not possible or was useless because the server had seen a proxy's IP address instead of the client's.)

Carsten_Kulms

I just noticed that I did not fully answered your question about LLSession's cookie and CWS:

..as you can see, the third parameter is cookie...
..but I cannot find anything similar in cs10

What is the cookie with LAPI is the authentication token with CWS; see Content Web Services / Client Guide / Authenticating the Client

Important to note is that this equivalence is by functionality / role only--the cookie/token are not necessarily interchangeable. It depends on how CWS are deployed and which authentication mechanism is in place if you can use a cookie obtained by means of accessing the CS UI as an authentication token with CWS. This will work in certain simple setups only.

And only if the IP address check is disabled. So this information just for the sake of completeness. :-)

Carsten_Kulms

On additional note (to correct myself in some extent):

If you could make your "webservice" look like a proxy, i.e. it can set the X-Forwarded-For header, and it knows the client's IP address, and you configure the webservice's IP address as a trusted proxy address then the webservice could reuse the client's cookie pretending to forward a request from the client (as a proxy does).