TIBCO StreamBase® Runtime uses authentication realms to define authentication mechanisms and common principal and credential management. Multiple authentication realms can be active at the same time. These authentication realms are supported:
Kerberos
LDAP
Local
OpenId Connect
Realm management is provided by the realm
administration target. See the section called “realm target”.
Node administration can use either a local (the default) or an LDAP authentication realm.
A Kerberos authentication realm supports Kerberos single signon authentication using one or more Kerberos Key Distribution Centers (KDC). Kerberos is only supported via the HTTP Simple and Protected [GSSAPI] NEGOtiation (SPNEGO) protocol; non-HTTP communication is not supported.
The Kerberos authentication realm only supports authentication, there is no support for authorization. To support authorization a fallback realm must be specified to provide authorization services.
A Kerberos authentication realm is configured using the
KerberosAuthenticationRealm root configuration
object. See the section called “KerberosAuthenticationRealm”.
An LDAP authentication realm performs authentication against a set of LDAP servers with potentially disjoint user populations. The realm supports any number of LDAP servers, each with different search properties, authentication mechanisms, and secure communication profiles. Multiple LDAP servers can be used for high availability (replicas of the same server), for unifying disjoint user communities, or both. When multiple LDAP servers are configured in a realm, they are tried in turn, always starting with the first server configured in the realm configuration, until a server responds with a positive authentication, or the request fails on all servers.
These mechanism are supported for authentication:
Local password verification: the user's password is queried from the LDAP server over a connection authenticated with system credentials, and sent to the realm LDAP client, which compares it with the password provided by the user being authenticated. If the provided user password is encrypted, it is decrypted using the master secret (see the section called “Sensitive data encryption”) before comparing with the password returned by the LDAP server. This mechanism is used in cases where the LDAP server does not support remote password verification.
Remote password verification: the user's password is sent to the LDAP server over a connection authenticated with system credentials, and the LDAP server compares it with the user's LDAP password. If the password sent to the server for comparison is encrypted, it is decrypted by the master secret manager (see the section called “Sensitive data encryption”) before sending to the LDAP server. This mechanism is preferred to local verification, even when using a secure LDAP connection, because the user's actual password never leaves the LDAP server.
Bind: the realm attempts to connect to the LDAP server using the user's name and password, and authentication succeeds if the connect attempt succeeds.
Support is also provided for:
not requiring a password when connecting over a secure communication channel, like TLS, and that connection uses client (mutual) authentication. The authenticated user is provided by the server network listener, which is responsible for mapping the client X.509 certificate's subject Distinguished Name (DN) to a user name. See the section called “SecureCommunicationServerProfile” for more details on how this is accomplished.
require a password even when connecting from a trusted host.
An LDAP authentication realm is configured using the
LDAPAuthenticationRealm root configuration object.
See the section called “LDAPAuthenticationRealm”.
The LDAP authentication realm can be used as the authentication realm for node administration. It can also function as a fallback realm.
All nodes support a native local authentication realm. This realm provides both authorization and authentication. Users are stored in a node's transactional memory and support these features:
password validation.
access control via one or more roles.
password expiration.
account locking.
requiring a password even when connecting from a trusted host.
not requiring a password when connecting over a secure communication channel
There is also support for configuring a set of initial users that should be defined on the node allowing administrators to bulk-load users rather than creating them individually.
User administration is provided by the user
administration target (see the section called “user target”) and
password management is provided by the password
target (see the section called “password target”). Support for
backing up and restoring the local realm is provided by the
realm administration target (see the section called “realm target”).
A local authentication realm is configured using the
LocalAuthenticationRealm root configuration object.
See the section called “LocalAuthenticationRealm”.
The local authentication realm can be used as the authentication realm for node administration. It can also function as a fallback realm.
An OpenId Connect (OIDC) realm uses a list of OIDC identity providers to perform single sign-on authentication. OIDC is only supported via the HTTP protocol; non-HTTP communication is not supported.
The OIDC authentication realm only supports authentication, there is no support for authorization. To support authorization a fallback realm must be specified to provide authorization services.
An OIDC authentication realm is configured using the
OIDCAuthenticationRealm root configuration object.
See the section called “OIDCAuthenticationRealm”.