Authentication & Authorization With Lightstreamer

This short article will guide you through authentication and authorization in Lightstreamer and will introduce a live example with full source code.

Authentication

Most, if not all, Lightstreamer applications will, at some point, require some sort of authentication mechanism to validate their users. Moreover, there usually is an authentication mechanism already in place when Lightstreamer is introduced in the system.

So, let's see how to introduce Lightstreamer in an environment where Authentication is already handled by a Web/Application server.

The MetadataProvider interface of Lightstreamer delegates the authentication to custom code, hence any scenario is totally feasible no matter how the current authentication cycle currently is. Anyway, in this article, we will focus on a rather common pattern where, upon authentication, the Web Server returns a token to the client (e.g.: through a cookie or through an ajax response) and the client uses that token every time it has to request data requiring an authenticated user to the same server. All in all, the user/password pair is only used once (well, the token will expire sooner or later, that's pretty obvious).

Instead of authenticating again the user, using the password within the Metadata Adapter, the suggested approach is to send the token received from the Web Server to Lightstreamer Server; in turn. the Metadata Adapter will validate the received token against the common back-end.

So, first thing, from the client, we grab user and password and we send them to the existing Web Server. In case of success we will have our token.
e.g.:

	$.ajax({
	url: "login.js",
	type: "POST",
	data: {
	user: user,
	password: password,
	},
	success: function(resp) {
	token = resp;
	}
	});

view raw login hosted with ❤ by GitHub

Then we can put the token in our LightstreamerClient instance, and connect to the Lightstreamer server:

	var lsClient = new LightstreamerClient(SERVER,ADAPTER);
	lsClient.connectionDetails.setUser(user);
	lsClient.connectionDetails.setPassword(token);
	lsClient.connect();

view raw connect.js hosted with ❤ by GitHub

On the other side, Lightstreamer will receive the request and will call the notifyUser method on the MetadataProvider implementation in use. The notifyUser will validate the user/token against the back-end and, if valid, will not throw any exception. On the contrary, an AccessException will be thrown to notify the server of the failed authentication. In the below code, the query to the external back-end is wrapped inside the isValidToken method:

	public void notifyUser(String user, String token, Map httpHeaders) throws AccessException {
	if (!AuthorizationRequest.isValidToken(user, token)) {
	throw new AccessException("Invalid user/token");
	}
	}

view raw notifyUser.java hosted with ❤ by GitHub

If the connection is refused the client listeners will receive an onServerError call

	lsClient.addListener({
	onServerError:function(code,message) {
	alert(message);
	}
	});

view raw serverError.js hosted with ❤ by GitHub

Otherwise, the connection will start.

Authentication is now complete.

Authorization

Not all users are created equal though. Some will have access to certain items that others cannot see. The MetadataProvider also provides hooks where these kind of fine-grained authorization can be implemented and enforced.

The MetadataProvider must first declare it wants to verify each and every subscription:

	public boolean wantsTablesNotification(String user) {
	return true;
	}

view raw wantsTableNotif.java hosted with ❤ by GitHub

then, when the client subscribes to a list of items,

	var subscription = new Subscription(mode,itemList,fieldList);
	subscription.setDataAdapter(dataAdapter);
	lsClient.subscribe(subscription);

view raw subscribe.js hosted with ❤ by GitHub

the MetadataProvider will receive a call to notifyNewTables. Each TableInfo instance represents a subscription, and each subscription might contain several items. The item names in the TableInfo instance are in the form of a single string as it is sent by the client. We delegate to the  getItems the explosion of the list.
As with user's authentication, in this example, the authorization policy is wrapped in a single method, namely canUserSeeItems. If the method fails to authorize the user against the items, a CreditsException has to be thrown to prevent the subscription from being fullfilled.

	public void notifyNewTables(java.lang.String user, java.lang.String sessionID, TableInfo[] tables) throws CreditsException {
	for (int i=0; i<tables.length; i++) {
	String[] items = this.getItems(user, tables[i].getId());
	if (!AuthorizationRequest.canUserSeeItems(user, items)) {
	throw new CreditsException(-1, "User not authorized", "You are not authorized to see this item");
	}
	}
	}

view raw tableNotif.java hosted with ❤ by GitHub

Again, a listener on the Subscription is notified if the subscription is refused or did start, permitting the client code to act accordingly:

	subscription.addListener({
	onSubscription: function(updateInfo) {
	//subscription successful!
	},
	onSubscriptionError: function(code,message) {
	//subscription refused
	}
	});

view raw onSubscription.js hosted with ❤ by GitHub

This is just an overview of the basic authentication and authorization workflow. As you can see, you can hook your own system to Lightstreamer Metadata Adapter to perform these activities with your own back-end.

Examples

If you want  to dig a little more on the topic, and start coding yourself, we suggest to explore the following projects:

• Java Adapter:
  https://github.com/Weswit/Lightstreamer-example-AuthMetadata-adapter-java
• HTML Client:
  https://github.com/Weswit/Lightstreamer-example-AuthMetadata-client-javascript

These projects still fake the requests to the back-end with static collections, but contain many useful comments and a simple implementation of an authorization caching mechanism.

The live result can be seen here: http://demos.lightstreamer.com/AuthDemo/