Getting through IIS "Basic" authorization process

Alessandro Alinone

https://site1.system.com for the web server and https://site2.system.com would be perfect. The domain will be of course "system.com".

wmolde

Just out of curiosity, are there any special steps on the client side that need to be taken to use ssl encryption? I know that in the LS server config file there are places configure the ssl part of the server, are there any such settings that need to be done on the client side?

I'm thinking that part of my problem might be that the client is not set up to use ssl correctly. In my scenario the data is sent ssl from the browser, it goes through a couple of firewalls (where the ssl encryption is stripped off) and then continues to the LS server (no longer ssl encrytped). Does anyone know of any special configuration setting that need to be made to make this situation work? Will it work this way? If I have to I can run ssl all the way to the LS server.

Thanks for the help!

Alessandro Alinone

The protocol used to connect to Lightstreamer Server is always the same used to download the Master Push-Page. So if the Master Push-Page is downloaded through HTTP, then HTTP will be used for all the connections to Lightstreamer Server. It the Master Push-Page is downloaded through HTTPS, all the connections to Lightstreamer Server will use HTTPS.

The port used to connect to Lightstreamer Server can be set through the setLSPort method.

wmolde

Ok, I was able to get everything up and working on my development system... Now here comes the fun part. The primary difference between my development and production system is that the production system has to have all incoming traffic validated by a Windows Active Directory server. When I try the exact same setup from the production system LS will not connect. The Windows status bar (IE6 and IE7) says "Lightstreamer is Connecting...", but it never actually connects. Are there any tools or variables that I could look at try and see why it is not actually connecting? I have a feeling that it is because of the AD domain server and authorization process, but I would like to have a way to verify this. Any Ideas? Thanks!

wmolde

Hi, I was just able to get hold of one of our IT guys to check out the server logs. He was saying that it looks like the LS Client is trying to talk to the LS server via standard http traffic. I know that I am calling the page via https. I am assuming that if I am calling the main web site pages via https that the master push page is also being recieved via https. The only traffic that is allowed through our firewalls is https (ssl on port 443). Is there a way that I can check to verify that LS from the client is trying to connect via https? Is there anyplace that I can force it to use ssl?

wmolde

Hello again, so I kept digging...

Using a http sniffer, I took a look at what was being sent from the client to the LS server. I noticed that I was getting "HTTP/1.1 403 Forbidden" errors on all calls being sent to my LS server ([url]https://site2.system.com)[/url]. Digging around a little more I noticed that the difference between the calls that were making it through to the server had a "Authorization" line in the header that is missing from the LS calls.

The following is the line in the header that I believe is causing the issue:
Authorization: Basic dXNlck5hbWU6UGFzc3dvcmQ=
From what I can tell this is the section of code that authorizes the traffic with the AD domain server. How can I change the header so that this code is sent to the server whenever the lightstreamer client has to make a call??

Alessandro Alinone

Lightstreamer's authentication scheme is based on an application-level session-id and does not support the HTTP Basic Authentication Scheme (that in any case can be provided by the Web server).

So the canonical architecture has the Web server authenticate the user through any preferred authentication scheme (including HTTP basic authentication). Then the browser connects to Lightstreamer Server sending some code received from the web server through the username and password fields. This information is validated through the Metadata Adapter, that will check it against the Web server or the directory server.

That means that straight HTTP or HTTPS communication should be allowed by the network infrastructure, delegating the authorization management (for the interaction with Lightstreamer Server) to the application itself (i.e. client + Metadata Adapter).

wmolde

That sounds good on paper... If you could just convince our IT department to allow us to do that... :Smile_Ad:

I was afraid that this was going to be the case.
Thanks for the help!

ksivasam

Alessandro,

The authentication scheme you mentioned - "LS uses session_id based authentication'.

Does this mean LS verifies the session_id from the browser with the web server? - how reliable is this over https? Can we depend on this for a production level app? Trying to understand how this works.

If this is not recommended, do you recommend us implementing 'notifyUser()' in the MD adapter?

Thanks,
Kal

Alessandro Alinone

Kal,

What I mentioned was indeed the nofifyUser() implementation. That's the only possible way to validate a sessionId.

For a more detailed explanation, I will cut&paste, below, a description from the General Concepts guide (see the attached PDF for the sequence diagram).

The figure focuses on the authorization process. It illustrates the typical best practice used for Web applications, when a Web/Application server is involved in the process. The actual authentication is usually handled by the legacy Web/Application server, irrespective of Lightstreamer. Some sort of session_id is sent back to the Client (through cookies, response payload or any other technique). When the Web Client creates the Lightstreamer session, instead of sending again the full credentials (usually involving a password) to Lightstreamer Server, it sends just the session_id (or the username and the session_id). The Metadata Adapter is passed this information and validates the session_id against the Web/Application Server that generated it (or a database or whatever back-end system).
The advantage of this practice is that the user’s password is never used outside the legacy system. Also, since the communication between the Client and Lightstreamer Server can leverage HTTPS, the session_id can be encrypted, so that it cannot be intercepted on the network.
This is just an example, because the Metadata Adapter is usually implemented in a custom way for each project, when integrating Lightstreamer into an existing or a new system.

ksivasam

Perfect. I implemented it through the MD adapter and works great!

Is there a way to log from the adapter? It will be great to log the user sessions through 'notifyUser'. I can add a logger but not sure where it will write the logs to? (Lightstreamer.log?)

Dario Crivelli

I'm not sure I understand your logging needs. If you need to log each new session and the related user, then you can do it only in "notifyNewSession", as "notifyUser" is called before session creation.
Admittedly, the Server log lacks this item; while each session name is logged by the Server at session creation (even in the default logging configuration), the related user name is not logged and can only be inferred by nearby log lines.

As far as we know, log4j support is a singleton and (as the Adapter is loaded by the Server in the Server's own ClassLoader) all logging configuration in "lightstreamer_log_conf.xml" is available to Adapter code. You can log on the Server loggers; in this case, your log will share the appenders of the Server log (the console and Lightstreamer.log).
Otherwise (and preferably) you can add and configure your own loggers/categories and appenders; if you inherit from "LightstreamerLogger", you can still share the appenders of the Server log. You can extend "lightstreamer_log_conf.xml" or even load your own configuration file, which will be merged with the Server one. In the latter case, in order to avoid conflicts, just leave the "root" element configuration empty.

Dario