User Authentication and Permissioning

StreamLink provides a public interface called CredentialsProvider that is responsible for providing the credentials that Liberator requires to be sure that the user is allowed to log in. These credentials are often a username and password. StreamLink developers can implement this interface themselves to perform custom logic, such as integrating with a single sign on system, or retrieving a password from an external system.

CredentialsProvider

The StreamLink library includes several sample implementations of CredentialsProvider depending on the technology in use:

  • PasswordCredentialsProvider - A basic implementation that provides user credentials consisting of a set username and password.

  • StandardKeyMasterCredentialsProvider - An implementation that attempts to retrieve a password token from Caplin KeyMaster. It can also optionally poll a specified URI on the KeyMaster server in order to keep the HTTP session alive.

  • AuthenticatingKeyMasterCredentialsProvider - An implementation that attempts to retrieve a password token from Caplin KeyMaster server that requires basic HTTP authentication. This implementation has the same behaviour as StandardKeyMasterCredentialsProvider except that it attaches the user credentials to each web request that it makes.

Note that AuthenticatingKeyMasterCredentialsProvider is not available in StreamLink Silverlight, because (at the time of publication) Silverlight does not allow web requests to include user credentials.

Permissions objects

A permissions object allows changes in user permissions on objects to be sent in real time between Permissioning Adapters, and between Liberator and client applications.

In StreamLink, subscribing to a permissions change is just like subscribing to a normal record update (see Subscribing to Data and Receiving Updates), but the callback method to implement from SubscriptionListener is onPermissionUpdate().

The client application will then receive the permission object, and any subsequent updates to it, and can use this information as appropriate. For example, the client could modify the way the application behaves according to changes in the permission object, such as enabling or denying trading on particular instruments.

For more information about permissions objects, see the Caplin DataSource.