DEPRECATED: Authorization handlers

Role-based authorization

Attention:

The new role-based security model has superseded authorization handlers. Role-based security enables you to more simply manage permissions and users. We recommend you use role-based authorization instead of authorization handlers. For more information, see Role-based authorization.

As of Diffusion 6.2, authorisation handlers can no long validate credentials.

An authorization handler is a user-written Java™ class that must implement the AuthorisationHandler interface in the .

Such a handler can be used to restrict access of clients according to any criteria that is appropriate. One capability within Diffusion is for a client to be able to specify Credentials when they connect that can be checked by the authorization handler.

The handler can either be specified in etc/Server.xml in which case it is loaded when the server starts or can be set programmatically within a publisher using the Publishers.setAuthorisationHandler method.

There can only be one handler and it is system wide across all publishers, although you can have authorization at the publisher level.

If an authorization handler is not specified, credentials sent by a client are assumed to be valid. A publisher has access to the credentials to perform finer-grained authorization, if required.

The authorization handler interface has the following methods:

Table 1. Authorization handler methods
canSubscribe(Client, Topic)	This method is called when a client subscribes to a topic. If topic information is sent with the connection, this method is called after the canConnect method. Note: This is called for every topic being subscribed to, even if subscribed as a result of a topic selector being specified. However (by default), if a topic is rejected by this method, it is not called again for any children (or descendants) of the topic.
canSubscribe(Client, TopicSelector)	This method is called when a client attempts to subscribe to a topic selector pattern (as opposed to a simple topic name). If topic information is sent with the connection, this method is called after the canConnect method.
canFetch(Client, Topic)	This method is called when a client sends a fetch request to obtain the current state of a topic. Note: This is called for every topic being fetched, even if fetched as a result of a topic selector being specified. However (by default), if a topic is rejected by this method, it is not be called again for any children (or descendants) of the topic.
canWrite(Client, Topic)	This method is called when a client sends a message on a given topic, if false is returned the message is ignored, and the publisher will not be notified of the message. When implementing this method, be aware that performance can be impacted if many clients send messages or if a few clients send large messages.

Authorization handler

Authorization at the publisher level can also be achieved. This is required if there are many publishers running within the same Diffusion Server and they have different security settings. The following code example works if the publishers all implement AuthorisationHandler

public boolean canSubscribe(Client client, Topic topic) {

    AuthorisationHandler handler = 
            (AuthorisationHandler)Publishers.getPublisherForTopic(topic);

    // Call the publisher in question
    return handler.canSubscribe(client, topic);
}

Permissions

The permissions process governs whether a client is able to send messages to a publisher, or in other words, is the topic read only. This is handled by the canWrite method. Again a good pattern might be to look at the credentials attachment object to see if this is permissible.

public boolean canWrite(Client client, Topic topic) {
	User user = (User) client.getClientCredentials().attachment();
	return user.canWriteMessages(topic);
}