The AMS is configured through one or more files that conform to a subset of the HOCON syntax model, which itself is a form of JSON. The supplied configuration file provides a template of default values that you can modify for your site-specific needs. See AMS Configuration File Reference for an example of the AMS.conf file and a description of its HOCON syntax.
AMS configuration is organized into the following categories.
The path to the database file and the user name and password to access the file.
The client API listener specifies the TCP port number on which the AMS server listens and whether this port uses secure (TLS) communication.
To enable secure communications, change the ClientAPIListener.secure property from false to true and the ClientAPIListener.portNumber to the port number on which AMS should listen. Since AMS listens on a single port, it is technically possible to leave the port number unchanged. However, convention dictates that secure servers listen on different ports than non-secure servers, so it is good practice to change the port number when enabling secure communication.
The default port is 2185 (non-secure).
When using secure communication, a key store file, key store password, and key password are required. The configuration underpinnings for two-way (client) authentication are in place, though the AMS server currently supports only one-way (server) authentication.
AMS server installation includes a placeholder key store file, localhost.jks, containing a private key and self-signed certificate, which can be used to enable secure communications. However, the certificate identifies the AMS host name as localhost, thus restricting access to AMS from clients on the same machine the server is running. You are expected to provide your own key store file containing a private key and a certificate and that properly identifies the AMS host name. The CommunicationSecurity.keyStore property should be changed to point to the user-supplied key store file. In addition, TIBCO recommends changing the CommunicationSecurity.keyStorePassword and CommunicationSecurity.keyPassword properties to provide the password of the key store file and the password of the private key within that file, respectively.
AMS validates the identity of each user prior to allowing the user to perform actions. AMS supports the following authentication realms — essentially collections of user, password, and role information — for this purpose:
When configured for local realm authentication, the user, password, and role information are stored directly in the template HOCON configuration file, or in another AMS configuration file included by the template. The local authentication realm is used to seed users and roles in the AMS persistence realm.
When configured for LDAP authentication, AMS consults an LDAP server to validate the identity of the AMS user. The AMS configuration file provides the information required by AMS to access the LDAP server, including its host name, port number, and various search paths and LDAP attributes.
AMS maintains a database of projects, artifacts, and related metadata. AMS can be configured to use the persistence layer for user authentication and authorization as well. In which case user, role, and permission information are stored in the persistence layer.
The seeding of users and roles from the local authentication realm to the AMS persistence realm is a process that happens automatically every time the AMS server starts. No explicit action is required, aside from starting the server itself.
The OpenIDConnectAuthenticationRealm enables single sign-on through an ID provider. See Configuring Single Sign-On.
Once AMS identifies a user, it consults a map of role-to-privilege information to determine whether the user's requested actions are permitted. On start-up, the AMS copies this map from the template configuration file to its database. Administrators can then use the web UI to add, remove, or change roles and their permissions. Roles that are deleted will be re-added on the next start-up if they remain present in the configuration file.
The AMS can now deploy artifacts to different machines in the same subnet. To do so, you must configure an entry in the AMS.conf file's DeploymentServiceNames name-value pair, where the service name can be either a StreamBase Runtime cluster or node name.
For example:
DeploymentServiceNames = {
// Credentials for one or more StreamBase services. These credentials are
// used when deploying artifacts using a Target Type of StreamBase Service
// Name.
services = [
{ serviceName = "sample_decision_table_decision_table.<some name>"
userName = "guest" password = "guest" }
]
}
Ensure that all configuration file values requiring quotes use straight quotes ("...") and not smart quotes (“...”). Smart quotes are treated as data and not as delimiters for HOCON values.
AMS configuration files use straight quotes to encapsulate values. Apple's TextEdit application is a rich text editor that uses smart quotes by default. If using TextEdit or any rich text editor, ensure the editor is set to use straight quotes.