The global permission enum
The path permission enum
Returns a SystemAuthenticationScriptBuilder that can be used to modify the server's SystemAuthenticationConfiguration.
a script builder
Change the principal associated with this session.
Allows a session to authenticate as a different principal. If the authentication fails, the current principal remains valid.
the new principal to use.
credentials to authenticate the principal with.
a Result
Example:
session.security.changePrincipal('foo', 'password');Returns the set of global permissions assigned to the role.
the set of global permissions. This may be empty indicating that the role has no global permissions assigned.
Returns a list of path permissions assigned to the calling session on a given path.
the path to query for permissions
a Result which completes when the response is received from the server.
If the request was successful, the Result will complete successfully with a list of PathPermission.
Get the principal that the session is currently authenticated as.
the session's principal
Obtain the current contents of the server's security store.
If the request is successful, the result will complete with a SecurityConfiguration.
Example:
session.security.getSecurityConfiguration().then(function(configuration) {
console.log('Got security configuration', configuration);
}, function(err) {
console.log('Error getting security configuration', err);
});a Result that completes with the security configuration
Obtain the current contents of the server's authentication store.
If the request is successful, the success callback will be called with a SystemAuthenticationConfiguration object.
Example:
session.security.getSystemAuthenticationConfiguration().then(function(configuration) {
// Display principals/roles
configuration.principals.forEach(function(principal) {
console.log(principal.name, principal.roles);
});
// Check the authentication action applied to anonymous connections
console.log(configuration.anonymous.action);
// Check the default roles assigned to anonymous connections
console.log(configuration.anonymous.roles);
}, function(err) {
// Error retrieving configuration
console.log(err);
});a Result that completes with the server's authentication store
Returns a SecurityScriptBuilder that can be used to modify the server's SecurityConfiguration.
a script builder
Register an authenticator for client authentication events.
the handler name which must match an entry in the server's security configuration
specifies the authentication handler
a Result that completes when the authentication handler has been registered, returning a Registration which can be used to unregister the authentication handler.
Otherwise, the Result will resolve with an error. Common reasons for failure include:
REGISTER_HANDLER or AUTHENTICATE
permission;
control-authentication-handler element with the given name.
null or undefined
Send a command script to the server to update the authentication store. The script may be produced by the builder SystemAuthenticationScriptBuilder.
If the script is applied without error to the server, the operation result will complete successfully.
If any command in the script fails, none of the changes will be applied, and the result will be failed with an error object.
If the server is configured for path replication then the changes will be replicated to all members of the cluster.
Example:
session.security.updateAuthenticationStore(script).then(function() {
console.log('Authentication configuration updated');
}, function(err) {
console.log('Failed to update security configuration', err);
});the command script
a Result
Send a command script to the server to update the security store. The script may be produced by the builder SecurityScriptBuilder.
If the script is applied without error to the server, the operation result will complete successfully.
If any command in the script fails, none of the changes will be applied, and the result will be failed with an error object.
If the server is configured for path replication then the changes will be replicated to all members of the cluster.
Example:
session.security.updateSecurityStore(script).then(function() {
console.log('Security configuration updated');
}, function(err) {
console.log('Failed to update security configuration', err);
});the command script
a Result
This feature allows a client session to query and update the security store and to authenticate the credentials of other sessions.
Authentication Control
Sessions are authenticated by a chain of authentication handlers. A client session can participate in the authentication process by creating an authentication handler and registering it with the server.
Each authentication handler is registered under a particular handler name. For registration to succeed, the server's security configuration must include a matching
control-authentication-handlerentry for the name, otherwise registration will fail and the authentication handler will be closed immediately.Each client session can register a single authentication handler for a given handler name.
For each authentication event, the server will use its configuration to determine the handler priority order. The server may call authentication handlers in serial or parallel. The server may stop the authentication process as soon as it has an allow or deny response from an authentication handler and all higher priority authentication handlers have abstained.
For a configured control authentication handler, the server will select a single handler from those registered for the handler name. If no authenticators are currently registered, the server will consult the next configured authentication handler in priority order.
Security Control
The security store is a persistent database maintained by the server containing authorisation rules that control what sessions can do.
Access rights to read and write data and to perform actions on the server are controlled by a fixed set of permissions. When a session is opened, the server assigns it a set of roles based on the principal used to authenticate. The rules in the security store assign each role to a set of permissions. Each role can be assigned zero, one, or many permissions. The same permission can be assigned to multiple roles. Roles can also include other roles to form a role hierarchy, and so inherit permissions from the other roles. Roles are defined implicitly by specifying them in permission assignments or inclusion relationships; there is no need to explicitly create roles in the security store.
Permissions either have 'path' or 'global' scope. Global permissions apply to actions that are server-wide and not specific to a particular path. Path permissions apply to hierarchical context, such as a branch of the topic tree or a branch of the message path hierarchy.
Evaluation of global permissions
A session has a global permission if any of its roles are assigned the permission.
Evaluation of path permissions
A session has a permission for a path if any of its roles have the permission for the path.
Path permissions can be assigned to a role for a path. The permissions are inherited by all descendant paths for the role, except paths that have a separate permission assignment for the role or that are isolated and their descendant paths.
Default path permissions can be assigned to a role to set permissions at the root of the path hierarchy. A default permission assignment applies to all paths without direct or inherited path permission assignments, except paths that are isolated and their descendant paths.
The permissions a session has for a path are determined as follows:
Access control
To query the store the session needs VIEW_SECURITY permission and to update the store it needs MODIFY_SECURITY permission.
In order to register an authentication handler a session needs both REGISTER_HANDLER and AUTHENTICATE permissions.
Accessing the feature
This feature can be obtained from a session as follows:
Example:
// Get a reference to the security feature var security = session.security;