Integrating Session Management with User, Role, and Permission Management

nyssr.net has integrated session management with associated user, role and rights management. Virtually all operations in the node system can be secured with appropriate rights.

The application for managing users, roles and rights is available in two versions: “RemoteSkin for Web” and “RemoteSkin for Swing”.

Function

In our applications, a login is always required first. The login dialog is therefore the first dialog displayed. After a successful login, a second application is shown for selecting the target application. A new tab in the browser is opened for each started application.

After a successful login, the system receives a session token that is passed to the started application. This session token is included in many messages sent by the application to the recipient. The recipient of the message can then verify whether the session token is still valid, who the owner is, and what rights they have.

There are two different session tokens. The most commonly used one contains all the aforementioned data and is therefore somewhat longer. This way, the verifier of the token does not need to send messages to the session management to verify the session token. For some situations, a short token can also be used. This is derived from the long token. Verifying the short token requires a message to the session management. In the response, the requested data is included in case of success. Typically, this method of token verification occurs so quickly that no noticeable delay is present.

Usage

Every developer can easily register new permissions. The assignment of permissions to roles and roles to users is done using the UserManager application. The recipient of each message can now check with the session token whether the sender has this permission and deny the service if not. Since everything in nyssr.net is based on messages, a comprehensive rights management system is ensured.

Security

The long token is signed with a private RSA key. All nodes have a verification service that uses the public key. The nodes receive the public key either through configuration or via a message shortly after the node starts.

Since the node network is closed and used privately (no external nodes should be allowed to connect), no one can steal a current session token and use it for other purposes. Production systems should therefore always operate with encryption of TCP channels via TLS.

Additional encryption of messages

Messages with session tokens can also be encrypted. A flag in the message header is sufficient for this. The sender node and the receiver node then exchange RSA keys – if this hasn't been done yet – which are used to encrypt the message. This process is transparent to the user.

This method prevents friendly nodes that pass the message on its way to the recipient node from being able to read the message.