Custom/External Authentication in TIBCO Spotfire

INTRODUCTIONThe main changes in TIBCO Spotfire® 7.0 and earlier versions to TIBCO Spotfire 7.5 is a seemingly simple architecture change: TIBCO Spotfire® Server is now the entry point, and TIBCO Spotfire® Web Player and TIBCO Spotfire® Automation Services have become a set of scalable backend services. Figure 1 shows how the clients connect to Spotfire Server for analytics services.

Client Tier

Spotfire iPad App

Spotfire Consumer andBusiness Author

Spotfire Server

Corporate LDAP Data SourcesSpotfire Library andAudit Database

SpotfireWeb Player

SpotfireAnalyst

Security andRouting Tier

Worker Service Tier

DataTier

Figure 1 TIBCO Spotfire 7.5 Architecture: Clients Connect to Spotfire Server

WHITEPAPER | 2

Other documents, including the TIBCO Spotfire Server Installation Manual, have detailed information about the architectural differences. This document focuses on what is important for custom and external authentication in the Spotfire environment.Many customers embed Spotfire Web Player into a portal or other web application, or have a corporate single-sign-on method to authenticate internal web applications. Before TIBCO Spotfire 7.5, this method of authentication was called “custom authentication” because it required custom C# coding on Spotfire Web Player. In Spotfire 7.5, because the Spotfire Server is handling all client requests and authentication, there is a configuration option called “external authentication” that will handle most cases without coding.

This document walks through these changes and presents the various options for custom/external authentication. The first section reviews how Spotfire handled this method of authentication before version 7.5.

USE CASES FOR CUSTOM/EXTERNAL AUTHENTICATIONSpotfire supports an almost unlimited set of possible configurations. In this document, we focus on the following major use cases:

I WANT TO... AVAILABLE TOOLS

Embed Spotfire visualizations in my web portal application, for example, SharePoint or another.

Use Spotfire Web Player custom authentication in Spotfire 7.0 and earlier; Configure external authentication in Spotfire 7.5 and later (may require extra coding).

Secure Spotfire Web Player using the corporate web application and Single Sign-on technology.

Use Spotfire Web Player custom authentication in Spotfire 7.0 and earlier; Configure external authentication in Spotfire 7.5 and later (likely will not need extra coding in Spotfire 7.5 and later).

Embed Spotfire visualizations in my web portal application and have dynamic user information (group membership, permissions, etc.) passed to Spotfire Server.

Use Spotfire Web Player custom authentication in Spotfire 7.0 and earlier; Configure external authentication in Spotfire 7.5 and later (will need extra coding in Spotfire 7.5 and later). Will need a PostAuthenticationFilter for all versions (not covered in this document).

CUSTOM AUTHENTICATION IN TIBCO SPOTFIRE 7.0 AND EARLIERPrior to Spotfire 7.5, the technology needed for customer authentication was referred to as “Spotfire Web Player custom authentication.” (http://stn.spotfire.com/stn/Tasks/ImplementingCustomAuthentication.aspx).

One reason for the name “custom authentication” was that it required writing a bit of C# code, placing the compiled DLL on the Spotfire Web Player Server, and modifying the Web.Config file to have it pick up this custom authentication assembly. The main purpose of the custom authentication component is to extract the user identity and pass it onto the Spotfire environment to handle authorization within the Spotfire environment. User authentication has occurred external to the Spotfire environment via some other mechanism, such as portal login, single sign-on, SAML token, etc.

WHITEPAPER | 3

In the following diagram, authentication is handled by a portal server that uses an authentication service that exposes a ticket that needs to be validated to get the user identity:

Portal Server

AuthenticationService Spotfire Server

Web Player Server(C# Custom Auth Code)

Web Browser

1. Authenticate

5. Ticket

6. User Name

7. Impersonate (User Name)

2. Authenticate 4. Cookie (Ticket)

3. Cookie (Ticket)

Figure 2 TIBCO Spotfire 7.0 Web Player Custom Authentication Flow

Upon entering credentials for authentication (1-2), the authentication service sets a domain cookie containing a user ticket (3), which is made available to the custom authentication mechanism on the Spotfire Web Player (4). The custom authentication component on the Spotfire Web Player Server extracts the ticket, passes it to the authentication service (5), which translates it to the user identity and passes it back (6). Finally, the user login name is used in the impersonation step when communicating with the Spotfire Server (7).

The following diagram shows the steps and which component is handling those steps:

Spotfire Server

Spotfire Web Player IIS Agent User Identity

Provider

Start Here

User tries to access Spotfire

Web Player

User’s browser redirects to the

SSO URL

Form-Based Authentication

Identity Provider parses SAML request and

authenticates User

Identity Provider generates SAML

response and sends to browser

Agent generates SAML request and sends redirect to

SSO URL

Authentication Plugin extracts identity from

SAML token and creates Spotfire

Session

Web Player configures user interface based on permissions

Spotfire Server returns

permissions for User from LDAP

Active Directory

Agent verifies SAML response

User’s browser retries the original

request

User’s browser renders Web Player page

Figure 3 TIBCO Spotfire 7.0 and earlier Spotfire Web Player Custom Authentication Diagram

WHITEPAPER | 4

1 The user attempts to reach the Spotfire Web Player.

2 The IIS plugin recognizes that no valid SAML token is present and generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the identity provider’s SSO service.

3 The IIS plugin sends a redirect to the user’s browser. The redirect URL includes the encoded SAML authentication request.

4 The identity provider decodes the SAML request and authenticates the user.

4a The identity provider may optionally use one or more web forms to authenticate the user using username/password, RSA key, Smartcard, etc.

5 The identity provider generates a SAML response that contains the authenticated user’s username. This response is digitally signed with the identity provider’s public and private keys.

6 The identity provider encodes the SAML response and returns the information to the user’s browser. This stream includes a mechanism to forward the request back to Spotfire Web Player, such as embedded JavaScript or a button that the user presses.

7 The IIS plugin verifies the SAML token using the identity provider’s public key. If the response is successfully verified, the request is passed through to the Spotfire Web Player.

8 The Spotfire Web Player custom authentication plugin extracts the validated username from the request and uses it to impersonate the user to create a new session.

9 Spotfire Server reads the user’s permissions from the Spotfire database, which is synchronized with the dorporate LDAP, and returns the information to the Spotfire Web Player.

10 Spotfire Web Player uses the user’s permissions to render the user interface and control access to retrieve and process data with the Spotfire data engine.

11 The user’s browser displays the Spotfire Web Player user interface. Subsequent requests use the existing SAML token and session id.

Following is a simple example and one of the common code examples seen when using an IIS agent to trap traffic into the Spotfire Web Player web application. This is a common pattern when using an SSO solution like SiteMinder, Oracle Access Manager (OAM), etc. In these cases, access to Spotfire Web Player is controlled by an IIS agent from the SSO solution, which checks that all access to the Spotfire Web Player has been authenticated. In these cases, the code can be simple because a user cannot get past the authentication step without the SSO service performing validation checks. The SSO solution typically puts the user identity into an HTTP header or cookie.

WHITEPAPER | 5

using System.Security.Authentication;

using System.Security.Principal;

using System.Web;

using Spotfire.Dxp.Web;

namespace SpotfirePS.SpotfireWeb.CustomWebAuthentication

{

public class CustomWebAuthenticator : CustomAuthenticator

{

public CustomWebAuthenticator()

{

}

protected override IIdentity AuthenticateTokenCore(AuthenticationContext context)

{

log4net.ILog log = log4net.LogManager.GetLogger(“CustomWebAuthenticator”);

HttpContext httpContext = HttpContext.Current; // context.Context;

string headerValue = httpContext.Request.Headers[“UserHeader”]; <- Line #1

log.Debug(“In Custom Authenticator have context and headerValue=” +

headerValue);

if (headerValue == null || string.IsNullOrEmpty(headerValue)) <- Line #2

{

throw new AuthenticationException(“User cannot be authenticated.”);

}

// Create and return an object that helps authenticating the user.

return CustomAuthenticator.CreateIdentity(headerValue); <- Line #3

}

}

}

The key lines in the code are marked:

•  Line #1 – pulls out the HTTP request header value from the header marked “UserHeader.” This is the header value that is set by the SSO solution, for example, the common value for SiteMinder is SM_USER.

•  Line #2 – verifies that the header value has been set and is not null.

•  Line #3 – passes the user identity from the headerValue onto the authorization steps.

There is an example of Spotfire Web Player custom authentication in the Spotfire Development Kit, which can be used as a starting point. You need to find out from the customer what information is going to get passed, and what the code needs to do with that information. Obviously, this code can be more complex, as in the diagram, in that it could have to verify an encrypted ticket rather than just pull out a user identity.

WHITEPAPER | 6

After you’ve written the code, the following steps need to be performed to complete the configuration on the Spotfire Web Player Server and the Spotfire Server. References to the appropriate manuals are used for the details in some steps.

1 Deploy custom authentication C# assembly; Copy compiled DLL to Spotfire Web Player\<version>\webroot\bin folder.

2 Modify Spotfire Web Player Web.config file:

a Edit authentication to match the anonymous authentication from the Spotfire Web Player installation manual.

b Set impersonation username and password to be appropriate impersonation username and password for connecting to Spotfire Server.

c Set customAuthenticator XML tag information in Web.config in the <authentication...> tag. For example:

<authentication serverUrl=”<server URL goes here>”> <impersonation enabled=”true”/> <customAuthenticator type= “SpotfirePS.SpotfireWeb.

CustomWebAuthentication.CustomWebAuthenticator, SpotfirePS. SpotfireWeb.CustomWebAuthentication” />

</authentication>d Save Web.config file. IIS should restart the Spotfire Web Player application

automatically because the Web.config file changed, but if anything seems unusual, you can stop and restart the Spotfire Web Player website via the IIS management console.

3 Enable impersonation on the Spotfire Server via the Configuration Tool. See Spotfire Server manual to set this up.

When these steps are completed, the custom authentication should work in the Spotfire environment.

As an aside, some OEM customers pass extra information (for example, group membership) in the headerValue and then use a PostAuthenticationFilter to split the username from the other information. The PostAuthenticationFilter can set the correct user identity and use the other information to modify group membership, permissions, etc. While the PostAuthenticationFilter does not change for Spotfire 7.5, how the custom authentication is implemented does change and is discussed in the next section.

EXTERNAL AUTHENTICATION IN TIBCO SPOTFIRE 7.5As mentioned above, because the architecture changes in Spotfire 7.5, different tools and configurations will be used to support the external authentication integration. In this section, “external authentication” will be used in place of “custom authentication” because, in Spotfire 7.5, you configure external authentication in the Spotfire Server Configuration Tool to handle the custom authentication scenarios.

In versions of Spotfire prior to 7.5, some combinations of different authentication methods are allowed on Spotfire Web Player and Spotfire Server instances. For example, you could setup Spotfire Web Player with custom authentication for external users and use a different authentication method for Spotfire Web Player for internal users. With TIBCO Spotfire 7.5, all authentication is done on Spotfire Server. There are some authentication methods that are allowed simultaneously, and external authentication is one of those. You can configure external authentication and use another method of authentication to support those use cases.

WHITEPAPER | 7

The following diagram shows authentication flow in Spotfire 7.5 when a portal is used and how Spotfire Server now handles the external authentication.

Portal Server

AuthenticationService

Spotfire Server (Java Authentication

Filter Code)

Web Browser

1. Authenticate

5. Ticket

6. User Name

2. Authenticate 4. Cookie (Ticket)

3. Cookie (Ticket)

Figure 4 Spotfire 7.5 and later External Authentication Flow

Upon entering credentials for authentication (1–2), the authentication service sets a domain cookie containing a user ticket (3), which is made available to the custom authentication mechanism on the Spotfire Server (4). The authentication filter on the Spotfire Server extracts the ticket, passes it to the authentication service (5), which translates it to the user identity and passes it back (6). The authentication filter then sets the user principal for the session using the user identity provided by the authentication service.

The following diagram shows the steps and which component is handling those steps:

Spotfire Server

Spotfire Server returns

permissions for User

Active Directory

TomcatAgent User Identity

Provider

Start Here

User tries to access Spotfire

Web Player

User’s browser redirects to the

SSO URL

Form-Based Authentication

Identity Provider parses SAML request and

authenticates User

Identity Provider generates SAML

response and sends to browser

Agent generates SAML request and sends redirect to

SSO URL

External Authentication and, if required, Authentication Filter extracts identity from

SAML token and creates Spotfire

Session

Spotifre Server configures user interface based on permissions

Agent verifies SAML response

User’s browser retries the original

request

User’s browser renders Spotfire

landing page; will vary based on permissions

WHITEPAPER | 8

1 The user attempts to reach the Spotfire Web Player/Spotfire Server.

2 The Tomcat plugin recognizes that no valid SAML token is present and generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the identity provider’s SSO Service.

3 The IIS plugin sends a redirect to the user’s browser. The redirect URL includes the encoded SAML authentication request.

4 The identity provider decodes the SAML request and authenticates the user.

4a The identity provider may optionally use one or more web forms to authenticate the user using username/password, RSA key, Smartcard, etc.

5 The identity provider generates a SAML response that contains the authenticated user’s username. This response is digitally signed with the identity provider’s public and private keys.

6 The identity provider encodes the SAML response and returns the information to the user’s browser. This stream includes a mechanism to forward the request back to Spotfire Server, such as embedded JavaScript or a button that the user presses.

7 The Tomcat plugin verifies the SAML token using the identity provider’s public key. If the response is successfully verified, the request is passed through to the Spotfire Server.

8 The Spotfire Server external authentication, or if needed an authentication filter, extracts the validated username from the request and uses it to create the Spotfire session.

9 Spotfire Server reads the user’s permissions from the Spotfire database, which is synchronized with the corporate LDAP, and returns the information.

10 Spotfire Server uses the user’s permissions to render the user interface and control access to retrieve and process data with the Spotfire data engine.

11 The user’s browser displays the Spotfire Server user interface, which will be dependent on the user permissions. Subsequent requests use the existing SAML token and session id.

The configuration for external authentication can be found in the Spotfire Server Configuration Tool or modified using the command line config-external-auth. The Spotfire Server manual has a section called External Authentication that has more information.

If you use external authentication for web browser users, then typically you will need a method of authentication for users connecting via Spotfire Analyst. Because all users now connect to Spotfire Server, it will have to handle both methods. The screen shot below shows the authentication configured for username/password using the Spotfire database and a warning that external authentication is also enabled. The warning is there to make sure the user is aware that external authentication is enabled on the external authentication page and can be configured or disabled on that page.

WHITEPAPER | 9

If all you need to do is pull out a user identity from the HTTP attribute, header, or cookie, then no custom code is needed. But if you need to pull out an encrypted token or do something more with the identity, then a custom authentication filter is needed. For the simpler case, you can use the external authentication configuration to pull out the appropriate HTTP element. The screenshot below from the Spotfire Server 7.5 Configuration Tool shows the type selected as (HTTP) Header and the header to look for is REMOTE_USER.

In addition to configuring where the identity is passed in the HTTP information, you can configure some constraints that will make the connection more secure, for example, require SSL, allowed hosts, and allowed IPs. Allowed IPs lets you to use regular expressions to allow blocks of IPs, for example 192.253.*. Some basic transformations are allowed to extract the name using a regular expression. Please see the Spotfire Server manual for more information.

If you need more complex processing than just pulling out a header, attribute, or cookie value, then you will need to write custom code. Because Spotfire Server is based on Tomcat, a Java web application container, any custom coding needed in TICO Spotfire 7.5 will be Java code.

WHITEPAPER | 10

The Spotfire Server 7.5 documentation comes with two authentication filter examples:

•  SimpleAuthFilter – basic filter that has built-in login form

•  IdentityProviderAuthFilter – shows example of using an external authentication service

The documentation and code for these are on the TIBCO docs site and on the TIBCO edelivery in the TIB_sfire_server_7.5.0_documents.zip file that is part of the Spotfire Server download package. On the docs.tibco.com site, the documentation and sample code are available from the Spotfire Server 7.5 page: https://docs.tibco.com/products/tibco-spotfire-server-7-5-0

These are complete examples that come with the entire code that is needed for the scenario. In contrast, the example code provided in this document assumes some external agent is providing the authentication and identity information, which is usually the case seen in the field. The examples provided with Spotfire Server can be useful and should be reviewed if the scenario applies, for example, the IdentityProviderAuthFilter redirects to an authentication service and then returns to the originally requested URL. The Appendix provides some discussion of these examples.

In more complex situations, to get the authentication information from the HTTP request and pass it onto the Spotfire environment, you need to write a Tomcat filter to process the authentication information and an HttpServletRequestWrapper to hold the user principal information. You cannot directly set the user principal in the HTTP request, and therefore you have to write a wrapper to hold this information. Below is sample code based on code modified from this URL: http://www.coderanch.com/t/466744/Servlets/java/Set-user-principal-filter.

package com.tibco.spotfireps.server.security;

import java.io.IOException;

import java.io.PrintWriter;

import javax.servlet.Filter;

import javax.servlet.FilterChain;

import javax.servlet.FilterConfig;

import javax.servlet.ServletException;

import javax.servlet.ServletRequest;

import javax.servlet.ServletResponse;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import com.spotfire.logging.LogManager;

import com.spotfire.logging.Logger;

/**

* Servlet Filter implementation class TestAuthenticationFilter

*/

public class TestAuthenticationFilter implements Filter {

private static final String CLASS = TestAuthenticationFilter.class.getName();

private static final Logger s_log = LogManager.getLogger(CLASS);

WHITEPAPER | 11

/**

* Default constructor.

*/

public TestAuthenticationFilter() {

// TODO Auto-generated constructor stub

}

/**

* @see Filter#destroy()

*/

public void destroy() {

// TODO Auto-generated method stub

}

/**

* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)

*/

public void doFilter(ServletRequest request, ServletResponse response, FilterChain

chain) throws IOException, ServletException

{

// get HTTP request and see if anything in the user agent

HttpServletRequest httpReq = (HttpServletRequest) request;

String userName = httpReq.getHeader(“UserHeader”); <- Line #1

// if userName is NULL then deny access

if (userName == null) <- Line #2

{

s_log.info(“No UserName Specified - assume another method of authentication”);

// HttpServletResponse httpResponse = (HttpServletResponse) response;

// PrintWriter httpWriter = httpResponse.getWriter();

// httpWriter.println(“<html><head><title>No access</title></head>”);

// httpWriter.println(“<body><h2>Access denied</h2></body></html>”);

// //.sendRedirect(timeoutUrl);

// return;

chain.doFilter(request, response); <- Line #2a

}

else

{

// Process found user identity – simple example reverse string

String userNew = new StringBuilder(username).reverse().toString(); <- Line #2b

s_log.info(“Setting UserPrincipal - “ + userNew);

// pass the request along the filter chain

chain.doFilter(new UserAuthRequestWrapper(userNew, httpReq), response); <-Line#3

}

}

WHITEPAPER | 12

/**

* @see Filter#init(FilterConfig)

*/

public void init(FilterConfig fConfig) throws ServletException {

// TODO Auto-generated method stub

}

}

The key lines in the code are marked:

•  Line #1 – pulls out the HTTP request header value from the header marked “UserHeader.” This is the header value that is set by the SSO solution, e.g. common value for SiteMinder is SM_USER.

•  Line #2 – checks to see if the value is null. If the value is null, you can either deny access (the commented out lines of code return an HTTP response that denies access) or chain onto the next method of authentication, e.g. forms based, etc. If external authentication is configured with another authentication method, then the second method will be chained for browser users. Spotfire Analyst users will always use the non-external authentication method.

•  Line #2a – passes the response to the next filter in the chain that is determined by Spotfire Server. This will chain to the next method of authentication.

•  Line #2b – processes the found user name; in this example, just reversing the string. This is where you would do more complex processing like calling out to an authentication service with a token to validate and get a username back.

•  Line #3 – creates the UserAuthRequestWrapper and passes this updated request with the user principal from the HTTP header onto the next filter in the chain.

The UserAuthRequestWrapper is created in the doFilter method to set the user principal that will later be passed on as the user identity. The TestAuthenticationFilter gets the username from the HTTP request header

“UserHeader.” Here is the UserAuthRequestWrapper code that is just a simple wrapper around the HTTPServletRequestWrapper that allows you to set the user identity such that it can be used later on in the authentication processing.

package com.tibco.spotfireps.server.security;

import java.security.Principal;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletRequestWrapper;

/**

* An extension for the HTTPServletRequest that overrides the getUserPrincipal().

* Used to override normal principal information.

* @author peter

*/

public class UserAuthRequestWrapper extends HttpServletRequestWrapper {

String user;

HttpServletRequest realRequest;

WHITEPAPER | 13

public UserAuthRequestWrapper(String user, HttpServletRequest request) {

super(request);

this.user = user;

this.realRequest = request;

}

@Override

public Principal getUserPrincipal() {

if (this.user == null) {

return realRequest.getUserPrincipal();

}

// make an anonymous implementation to just return our user

return new Principal() {

@Override

public String getName() {

return user;

}

};

}

}

As a reminder, for the simple cases, this custom coding is not required. It is only required if you must do more processing with the value obtained. The external authentication configuration in Spotfire Server 7.5 should handle the majority of the cases without requiring any custom authentication.

To configure Spotfire Server to use the custom Java authentication filter, you set the type in the external authentication to “Authentication Filter” as seen in this screen shot:

With the external authentication set to “Authentication Filter,” you need to set the filter class for the authentication filter. This is done in the authentication filter configuration as seen in this screen shot in which the Filter class is set to the code example from above with no parameters: com.tibco.spotfireps.server.security.TestAuthenticationFilter :

WHITEPAPER | 14

If needed, you can pass in initialization parameters that set various items, for example, an authentication service URL. After you make the configuration changes, you need to save them, deploy the compiled jar file to Spotfire Server,and restart Spotfire Server. In the example below, the Eclipse IDE is linked to the JRE from the Spotfire Server installation, the dss.jar file from tomcat\lib\webapps\spotfire\WEB-INF\lib, and servlet-api.jar from tomcat\lib directory of the TSS installation directory. The compiled jar file needs to be copied to the tibco\tss\<version>\tomcat\lib\webapps\spotfire\WEB-INF\lib directory, and the Spotfire Server must be restarted to recognize the new jar file. In the screen shot below, MyAuthFilter.jar has been copied to the spotfire\WEB-INF\lib directory.

After Spotfire Server is restarted, you should be able to use the updated authentication methods and test out that it recognizes the correct user values. If there are any issues, look at the Spotfire Server log files in the tomcat\logs directory. The server.log file is a good place to start. Spotfire Server may not start correctly if it cannot find the Java class specified, or if there are other issues with the authentication filter.

WHITEPAPER | 15

ADVANCED TOPICSThis section covers advanced topics that provide additional information.

•  PostAuthenticationFilter in Spotfire Server

•  Custom authentication examples in 7.5 documentation

POSTAUTHENTICATIONFILTER IN SPOTFIRE SERVERThis section discusses the post authentication filter as another extension point in the authentication and authorization of a user in Spotfire Server. The post authentication filter in Spotfire Server provides a couple of different configuration options. It is provided to perform an additional check after a user’s identity has been validated. The Spotfire Server manual has a section, Post-authentication filter, describing the configuration options. This discussion focuses on when you might need to write a Java post authentication filter.

In addition to the filter mode, you can specify a post-authentication filter class, which is a Java class that can do extra manipulation, validation, etc. of the user identity that has been passed in. Below is a screen shot from the Spotfire Server configuration tool showing the post authentication filter configuration:

One scenario for a post authentication filter involves using external authentication to pass in additional user information that can be used to dynamically assign group membership, permissions, etc. For example, the user identity string could contain additional information that when parsed could contain the user identity and group information that can then be used to dynamically set which groups the user is a member of. The post authentication filter can also be used to do additional validation of the user identity and reject the user if needed.

CUSTOM AUTHENTICATION EXAMPLES IN 7.5 DOCUMENTATIONThis section gives a brief description of the two code examples that come with Spotfire Server 7.5. The Java documentation and example code is available in the documents zip for Spotfire Server 7.5 and directly from this link on the docs.tibco.com site: https://docs.tibco.com/pub/spotfire_server/7.5.0/doc/api/TIB_sfire_server_Custom_Authentication_Filter_API_Examples.zip. The Java documentation is also online here:https://docs.tibco.com/pub/spotfire_server/7.5.0/doc/api/TIB_sfire_server_Custom_Authentication_Filter_API_Reference/javadoc/index.html. As described earlier, there are two authentication filter examples that are self-contained:

•  SimpleAuthFilter – basic filter that has built-in login form

•  IdentityProviderAuthFilter – shows example of using an external authentication service

WHITEPAPER | 16

The documentation for the specific classes—SimpleAuthFilter, IdentityProviderAuthFilter, and IdentityProviderServlet—provides details around compiling, deploying, and configuring.

The SimpleAuthFilter is an authentication filter that provides a login screen if authentication information is not present. The user database is a simple text file that has the username and password in it. The user database parameter is passed as an initialization parameter as seen in the screen shot below from the authentication filter configuration page:

The SimpleAuthFilter presents a simple login screen (shown below), and then checks the user database for the user authentication.

This is a simple self-contained example that could be modified to provide a custom login for a customer. The code provides a good starting point but should be modified for a production environment.

The second example provided with Spotfire Server 7.5 is a bit more complex and follows the pattern of an authentication service provider that gives a token that needs to be verified. The identity provider example contains a servlet for simulating an authentication service and the authentication filter. Here is the flow with the class names:

WHITEPAPER | 17

TIBCO Software empowers executives, developers, and business users with Fast Data solutions that make the right data available in real time for faster answers, better decisions, and smarter action. Over the past 15 years, thousands of businesses across the globe have relied on TIBCO technology to integrate their applications and ecosystems, analyze their data, and create real-time solutions. Learn how TIBCO turns data—big or small—into differentiation at www.tibco.com.©2016, TIBCO Software Inc. All rights reserved. TIBCO and the TIBCO logo, and Spotfire are trademarks or registered trademarks of TIBCO Software Inc. or its subsidiaries in the United States and/or other countries. All other product and company names and marks in this document are the property of their respective owners and mentioned for identification purposes only.

06/29/16

Global Headquarters 3307 Hillview Avenue Palo Alto, CA 94304+1 650-846-1000 TEL +1 800-420-8450 +1 650-846-1005 FAXwww.tibco.com

Spotfire Server IdentityProviderAuthFilter

Web Browser

1. Authenticate

5. Ticket

2. Redirect Browser to Service

6. User Name

4. Cookie (Ticket)3a. User ProvidesCredentials

3b. Cookie (Ticket)

IdentityProviderServletAuthentication Service

The identity provider documentation provides details of all the initialization parameters and how to set up the components. The IdentityProviderServlet is a Java servlet that should be installed on another servlet container to simulate an authentication service that provides a login service and a validation service. If a user is not authenticated, the IdentityProviderAuthFilter redirects the user to the authentication service (2) which captures the user credentials (3a) and provides a ticket (3b). This ticket is then sent back to the IdentityProviderAuthFilter (4), validated by the IdentityProviderServlet (5) and then converted into a user principal (6). This user principal is then used as the user identity.

Below is an example screen shot showing the initialization parameters for the IdentityProviderAuthFilter authentication filter:

The IdentityProviderServlet provides a similar login dialog to the SimpleAuthFilter. Similar to the SimpleAuthFilter example, this code is provided as a starting point and should not be considered production ready.