Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Hybrid View

  1. #1
    Member
    Join Date
    Apr 2007
    Location
    Kerry
    Posts
    17

    Security patterns: Forcing disconnection

    Hi guys,

    I'm doing some additional evaluation to LightStreamer, this time regarding Security. I would like to know if there is any security patter/best practice to address the scenario in which a client is successfully receiving notifications but suddenly the client session gets invalidated and Lighstreamer must disconnect him.

    Assuming we are using the Java API, i.e. a non HTML client, what is the correct pattern to force a client unsubscription from server-side? Is it sending a notification? is there any exception that can be thrown? ...

    Thanks,
    Martin

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan, Italy
    Posts
    517
    Hi Martin,

    There exist cases where you could decide to disconnect a user from Lightstreamer Server (for example if they log into a second session on a different Server and you don't want to support multiple push session for the same account; if you have one Server only, ConflictingSessionException will do the trick). There are three ways to terminate an existing Lightstreamer session (one of which has been deprecated):

    Option 1) Implement the getUserSession() method of the MetadataProvider together with the KILL command on the HTTP interface (see section 4.4 of “Network Protocol Tutorial.pdf”). But the getUserSession() method has been deprecated (i.e. we could decide in future releases of Lightstreamer Server to discontinue it), mainly for security reasons.

    Option 2) Use JMX (which is only available in the Vivace Edition of Lightstreamer). JMX (Java Management eXtensions) is a standard specification that allows an application to be controlled both internally and externally and both manually and automatically (i.e. from code). Lightstreamer Server exposes a set of MBeans that give full control over the engine and the sessions. To terminate a session through JMX, you just need to call the destroySession() method on the appropriate SessionMBean object. The powerful aspect is that you can access MBean objects both from inside your Adapter and from your J2EE application server, because JMX already implements several transport protocols for remote invocation, besides in-process invocation.

    Option 3) Handle the termination on the client side. Your clients will subscribe to some "service item" through which your Data Adapter will deliver termination notifications to the clients. When a client receives such message, it will terminate its Lightstreamer session, disconnecting from Lightstreamer Server.

  3. #3
    Member
    Join Date
    Aug 2008
    Location
    HCM City
    Posts
    7
    Quote Originally Posted by Alessandro
    There exist cases where you could decide to disconnect a user from Lightstreamer Server (for example if they log into a second session on a different Server and you don't want to support multiple push session for the same account;
    Option 3) Handle the termination on the client side. Your clients will subscribe to some "service item" through which your Data Adapter will deliver termination notifications to the clients. When a client receives such message, it will terminate its Lightstreamer session, disconnecting from Lightstreamer Server.
    This is our case: we want the server to disconnect all previous sessions of an user when he/she connects again (the same way as Yahoo Messenger does). And Option 3 sounds like a solution. Could you please explain a bit more details on how could I achieve this effect. Thank you.

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    973
    Note that the "termination on the client side" technique was suggested for a java-based client.
    If your client were a web page, it might be easier for a malicious user to disable the mechanism.

    The idea is that the Data Adapter should manage special items that allow each single client session to subscribe to its own item, so as to receive its own notifications from the Data Adapter. For instance, the item names might be of the general form "<sessionID>_status".
    The client should only subscribe to a generic name like "session_status"; then, the Metadata Adapter, in getItems could generate the final name by leveraging session information.
    The Data Adapter might manage a single field for all those items (let's call it "allowed") and value it as "Y" or "N", according to your constraints.
    A client which found that the "allowed" field has a value of "N" should disconnect.

    Consider that the forthcoming 3.6 release of the Server will support a new "destroy session" request, as a milder replacement for the deprecated "kill all user sessions" feature.
    So, it will be possible to issue the request from any backend process that knows the active session IDs (by communicating with the various Metadata Adapter instances).
    However, the availability of the generic client SDK would be needed, which requires the Presto or Vivace version of the Server.

  5. #5
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    973
    Lightstreaemer Server 3.6 release is now available.
    What follows is a sample code for forcing session termination from the Metadata Adapter, made possible by the new "destroy session" request.
    The sample can substitute the JMX based one shown earlier in this thread and represents a new implementation of Option 1 introduced above.

    So, we show a code snippet that, added to the Metadata Adapter code, listens to the notifications for session initiation and termination and causes each session to be closed after it has lived longer than five minutes.
    Upon forced session closure, the Web Client Library will enter "DISCONNECTED" state and won't try to recover the session; it will just notify application code through the "onServerError" event handler, with proper error codes.



    Note that the above code can only be used in Lightstreamer "Presto" or "Vivace" edition, in which the text interface is available.
    In "Allegro" or "Moderato" edition, we need to resort to the html or javascript interface; the following code snippet exploits the javascript case; the request syntax is the same, but for control.js in place of control.txt.




    Note that the response is in javascript and it is more complicated to analyze it.
    In case the operation is successful we should expect:

    On the other hand, if the session was not found we should expect:

    Any other response means that an unexpected condition has occurred.

  6. #6
    Senior Member
    Join Date
    Jul 2009
    Location
    not
    Posts
    41
    Hi Dario,

    How to do such thing, for example with the StockList Demo, knowing that this demo is using the default MetaAdapter ?
    Do i have to impelement one ?

  7. #7
    Senior Member
    Join Date
    Nov 2006
    Location
    Riyadh
    Posts
    33
    Hi,

    Do you mind explaining in java code how option 3 (in process jmx invoke) works inside the meta adapter for instance ?
    I asked a while ago in the forums how within the meta adapter notifyUser() function I can get the remoteIP and UserAgent and it seems SessionMBean does it.

    Thanks
    A

  8. #8
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    973
    Hi

    assuming you asked for an example based on JMX (i.e. option 2), we show you a code snippet that, added to the Metadata Adapter code, listens to the notifications for session initiation and termination and causes each session to be closed after it has lived longer than five minutes.

    There are several ways to access Lightstreamer MBeans server from the Metadata Adapter.
    We use the simplest one, which takes advantage of the fact that Lightstreamer Server loads all the Adapters in its main ClassLoader;
    so we access the MBeans server via static references, through the MBeanServerFactory.findMBeanServer method.



    Old note (until Web Client Library version 4.2.1)
    Note that this closure strategy is entirely server-side and the client receives no notice of the closure reason.
    The client only sees an unexpected closure.
    This means that, if the client is a web page based on the Web Client Library, the client will enter stalled state and, eventually, an attempt to create a new session will be performed.
    In this sense, option 3 may be preferrable to both 1 and 2.
    New note (since Web Client Library version 4.2.2)
    Note that, in case a session is forcibly closed by the Server, the Web Client Library enters in "DISCONNECTED" state and does not try to recover the session; it just notifies application code through the "onServerError" event handler, with proper error codes.
    About getting extended information on the sessions by taking advantage of the JMX interface:
    Old note (for LS Server up to and including 3.6)
    It has to be considered that many of the SessionMBean methods (and getUserAgent in particular) have not been implemented yet.
    This is not reported in the MBeanInfo interface, but is shown in the javadoc-style interface description.
    New note (for LS Server 4.0 and later, still to be released at time of writing)
    All the information available on the SessionMBean is reported in the javadoc-style interface description.
    Note that the same information is available dynamically through the MBeanInfo interface.
    Dario

  9. #9
    Member
    Join Date
    Apr 2007
    Location
    Kerry
    Posts
    17
    Thanks Dario.

    The MBean strategy works perfectly for us.

    The reason why we want to kill the user session is not really related with having multiple sessions (I guess to solve this overwrite the newSession callback method in the adapter is more than enough) but with security. Our system has a built-in hard session expiry mechanism to prevent malicious session handling attacks.

    Having the JMX possibility is enough for us. Btw, is the JMX server secured? Because if it stores the session as it seems I guess that you can obtain plenty of useful information from it.

    Regards,
    Martin

  10. #10
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    973
    Hi Martin

    may you please clarify your security concerns?
    We aim to guarantee security against external hosts. The JMX interface is exposed through some configurable ports, which can be hidden by the firewall and this should be enough.
    However, at the moment, we don't protect the Server (and, in particular, its JMX interface) against its own Adapters. We consider the Server and all configured Adapters as "friends". In fact, they all lie in the same ClassLoader.

    Dario

 

 

Similar Threads

  1. Forcing session termination
    By Alessandro in forum General
    Replies: 5
    Last Post: February 8th, 2016, 06:40 PM
  2. disconnection problems
    By magnum_rg in forum Client APIs
    Replies: 5
    Last Post: August 12th, 2011, 09:43 AM
  3. Track the Server disconnection
    By vaduganathan in forum Client APIs
    Replies: 1
    Last Post: May 12th, 2010, 09:26 AM
  4. System.Security.SecurityException
    By gjoseph in forum Client APIs
    Replies: 3
    Last Post: August 20th, 2009, 10:14 AM
  5. Internet Explorer --> Security zones issue
    By Mone in forum Client APIs
    Replies: 0
    Last Post: July 30th, 2009, 09:09 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 01:23 PM.