This chapter describes the architecture and management of the Spotfire Streaming security model.
Access control is done with users, which are formally known as principals. A principal has a credential (password) and they are granted one or more roles. Principals are managed using administration commands.
A user who installs a node is automatically granted administrative access to the node. This user is defined as a valid principal for the node. There is no password associated with this user and they can only access the node using the trusted host mechanism (see Trusted Hosts). To use the standard user name and password authentication mechanism this user must be updated to have a password.
This user has full administrative control of the installed node when logged in from a trusted host.
It is also possible to specify a different user at node installation. This user must specify a password at node installation since the user name is different than the operating system user that is installing the node. This user is also granted full administrative access to the installed node. See Default Security for details.
Apart from the user that installed the node, other users may administer the node only if they are granted administration privileges using a role. See Roles for complete details on the default security roles.
You can use administration clients without authentication to view some public properties for each node on the network. These are the properties published by the discovery service.
Access to all other node details — and to the managed elements contained within the node — is controlled via the security service. To access these elements, you need to be authenticated. Authentication is performed for each command executed using the command line client. JMX authentication is specific to the JMX tool.
The security model is defined more formally in Figure 1, “Security Model”.
The concepts in the security model are:
A principal definition contains one or more role names that define the privileges granted to the principal.
the principal and credential provided to the administrative command must be defined on all targeted nodes when using a local authentication realm (see Configuration of Local Authentication Realm).
all target nodes must use the same external authentication mechanism, for example LDAP or an OpenId Connect identity provider.
the target nodes for the administrative command must have the client host on which the administration command is being executed defined as a trusted host (see Trusted Hosts).
The choice of authentication mechanism is dependent on local security polices and whether the application is deployed into a trusted network. For example, the use of trusted host authentication would not be appropriate on an untrusted network.
It is recommend that security policy be consistent across all nodes in a cluster. Mixing different authentication realms, or inconsistent user definitions, can easily lead to security vulnerabilities.
Figure 2, “Cluster authentication model” shows the use of common principal and credential information in a cluster.