Starting with release 10.3.0, StreamBase and LiveView use a unified security model in which the same set of security configuration settings manage:
Client communication with a running StreamBase server.
Client communication with a running LiveView server.
All communication to and between nodes.
Administration of nodes.
All StreamBase security is applied to nodes. You configure security with HOCON configuration files that establish initial settings. Then while a node is running, you can add to, subtract from, activate, deactivate, and display security settings with administration commands.
All security configuration takes place within the context of one or more security realms.
Even without configuration, there is always a security realm active. To ease development, default settings allow you to install, start, and administer nodes on your local machine without considering security issues. However, as soon as you run a node on another machine or on another network, you must plan the security configuration of such a node to allow you to communicate with it.
A simple list of trusted hosts allows you to extend the default security settings for continued ease of development in a larger network. Later, if you configure an advanced security realm, a list of trusted hosts can be used as an added restriction on top of the realm's restrictions.
The Local Authentication Realm is foundational and the simplest to configure. Use this realm to establish a list of initial users and their roles. Establish the privileges assigned to each user or role with a Role to Privileges Mapping configuration.
You can encrypt sensitive information in configuration files, such as passwords and JDBC URIs. You establish a node-level master secret, then use an epadmin command to encrypt individual strings.
Independent of realm, you can enable TLS secure transport, using either server only or mutual client-server TLS.
You can reference the name of a configured realm in other HOCON configuration files. The epadmin command has several security related targets that let you upload and activate replacement configurations to a running node.
Pages that discuss the StreamBase security model might use the following acronyms or terms:
Authentication. Are you who you say you are?
Authorization. Now that you're here, what are you allowed to do?
Lightweight Directory Access Protocol, an open, vendor-neutral industry standard protocol for accessing and maintaining distributed directory services over an IP network. Microsoft's Active Directory product is an extension of the LDAP protocol.
- Distinguished Name (DN)
A naming specification used by LDAP to uniquely name objects such as user and role objects in an LDAP database.
Single Sign-On. An authorization mechanism that allows users to identify themselves one time, and then use that identification in many places without needing to provide credentials again.
OpenID Connect. An HTTP-based standard for SSO using third-party identity providers.
A JSON Web Token, used by OIDC to carry information about an authenticated user.
Another SSO specification. StreamBase uses HTTP-based Kerberos only.
A Kerberos Key Distribution Center, with which Kerberos clients communicate when requesting and validating Kerberos tickets.
Generic Security Services API. An API implemented by the JRE that provides Kerberos client and server authentication services, among many other things.
Simple and Protected Negotiation. An HTTP-based protocol for negotiating authentication protocols. StreamBase uses the Simple and Protected GSS-API Negotiation mechanism to provide Kerberos authentication services.
Java Authentication and Authorization Service, a collection of APIs implemented by the JRE for authN and authZ.