TIBCO Spotfire Platform IT Brief

Transcription

1 Platform IT Brief This IT brief outlines features of the system: Communication security, load balancing and failover, authentication options, and recommended practices for licenses and access. It primarily targets 3.3 and 3.3. Communication Security Communication between components of the platform can be encrypted using HTTPS, LDAPS and Secure JDBC: Data TIBCO Spotfire System: Secured communication Spotfire Database HTTPS HTTPS Secure JDBC.. HTTPS HTTPS.. LDAPS Web Players Load Balancer s LDAP For instance, Kerberos can be used throughout the system: A user can be automatically authenticated from a browser to the ; this Kerberos token is then forwarded through the load balancer, the and all the way to a Kerberos enabled database, potentially applying Role Level Security. The analysis data retrieved is based on the user identity. Refer to the installation and configuration manuals of and TIBCO Spotfire for details. 3.3 and 3.3 have been tested with Nessus Scanner.

2 Load Balancing and Failover The server side system can be clustered independently, as indicated below: TIBCO Spotfire System: Load balancing and failover.... Web Player cluster Load Balancer cluster Spotfire Database Compared to previous versions, memory usage is significantly lowered in 3.3. If the same analysis is used by many users, not only data is shared but also visualizations and configurations. As long as session affinity is maintained, different cluster solutions may be used. Microsoft s Network Load Balancing (NLB) is tested and recommended: NLB supports up to 32 server nodes in a single cluster New nodes may be added without stopping the cluster The distribution of users over the server nodes is based on IP-addresses Analyses may be pre-loaded on specific server nodes associated to the intended virtual cluster, using Scheduled Updates To achieve failover and to balance load, may be deployed to multiple machines, fronted by a load balancer. The load balancer must be able to detect if a TIBCO Spotfire becomes available or unavailable. Any load balancing technology supporting session affinity may be used. Apache HTTP via the AJP protocol is a verified setup. All s in the cluster communicate with the same Spotfire database. 2

3 Authentication Procedure Authentication is determined by existing IT infrastructure. It is a two-step process: 1. Apply a login mechanism to establish user identity 2. Verify that the established identity exists in a user directory system Supported options Password based: LDAP Directory, Windows NT Domain, Spotfire Database, Custom JAAS Module Single sign-on: Kerberos, X.509 Client Certificate, NTLM User directory: LDAP Directory, Windows NT Domain, Spotfire Database The following sections describe authentication setups for, with corresponding scenarios. Common to many setups is the use of the Impersonator feature, enabling the to run as a user of choice. Refer to the installation and configuration manuals of and TIBCO Spotfire for details. Anonymous ASP.NET: None IIS: Anonymous Any supported All users execute on using a configured TIBCO Spotfire account. Anonymous Authentication Always log in using a account 3

4 Username and Password Authentication ASP.NET: Forms Authentication IIS: Anonymous Basic authentication User name: X Password: Y Username and Password Authentication User name: X Password: Y NTLM / Kerberos with impersonation ASP.NET: Windows Auth. with ASP.Net Impersonation enabled IIS: Windows Authentication Specify Impersonation user Basic, NTLM or Kerberos The logs in to the using a configured Impersonator account, and impersonates user A. Domain user: A Single Sign-On Authentication: NTLM or Kerberos with impersonation Log in using Impersonator account Impersonate user A 4

5 Kerberos with delegation ASP.NET: Windows Auth. with ASP.NET Impersonation IIS: Windows Authentication Kerberos Kerberos security is advanced. It is strongly discouraged to set up Kerberos without any previous experience with the technology. Domain user: A Single Sign-On Authentication: Kerberos with delegation Domain user: A X.509 Certificates ASP.NET: None IIS: Anonymous with SSL and Client certificates enabled Specify Impersonation user certificate X.509 Client Certificates The logs in to the server using a configured impersonation certificate. Also note the ability to support SSL throughout, for any authentication type. See below for details. Cert A Cert C User name: A Single Sign-On Authentication: X.509 Certificates Log in using Impersonator account Impersonate user A 5

6 Certificates A Client certificate: Identifies client connecting to the server. B server server certificate: Identifies server to the client. C server client certificate: The impersonation certificate identifying the server when connecting to the. D server certificate: Identifies the server to server. E CA certificate, a certification authority s certificate: Issues certificates A, B, C and D. Used to issue client or server certificates, but also to establish trust between clients and servers. If there is a chain of CA certificates, all CA certificates involved must be used. Client: A browser connects to the server providing A, typically stored in the browser s certificate store for the current user. The server provides B to the client. To ensure that B is trusted by the client, the CA E used to issue B, is added to the Trusted Root Certification Authorities for the current user on the client computer. server: Configured with its server certificate B. To ensure that the client certificate A is trusted, it must be configured with the CA certificate. The server must be configured with certificate C, to be used when connecting to the. : When the server connects to the server, it provides C. For the to trust this certificate, the CA certificate E must be added to the jre/lib/security/cacerts keystore. Custom Authentication ASP.NET: None IIS: Anonymous web.config: Declare custom authentication Specify Impersonation user Typically Basic or NTLM Custom user information for A Log in using Impersonator account Impersonate user A Custom Authentication 6

7 Groups: Controlling Licenses and Access License and Library access is controlled by group membership. Group membership is defined manually or automatically synchronized with an LDAP (for instance an Active Directory). This section outlines how to set up group memberships in an LDAP environment: First create Access and License control groups in LDAP. Next, synchronize them with the, from where they control TIBCO Spotfire behavior. Finally, add users to the groups in LDAP to assign Licenses and Access, not in TIBCO Spotfire. This way License and Access control is handled by LDAP administrator, making the system easy to manage in an LDAP environment. LDAP Create an OU in the LDAP for the Spotfire related groups Create the License related groups Create the resource related groups. A resource may be a particular analysis. LDAP Authentication In the Authentication tab of Configuration Console, configure the server to authenticate against LDAP. Set Context to point both at the OU containing the user accounts, and the OU containing the Spotfire-related groups. 7

8 LDAP Synchronization The LDAP Synchronization is configured in the User Directory tab. Context: The OU containing the user accounts and the OU containing the Spotfire groups: Group Synchronization :All groups to be available in Spotfire under the Spotfire OU: Synchronization schedule: Set to a reasonable value to keep the groups synchronized. License control Licenses are managed in the Administration Manager of client. Launch the UI to assign licenses to the imported LDAP License control groups. Note that LDAP synchronization has to have run at least once before any groups show up in Administration Manager. Access Control Access Control is defined in the Library Manager. Assign Full Control to the Administrator only, ensuring that just the Administrator can modify access permissions. Engineering Version 1 System Requirements: 8