Whitepaper Custom/External Authentication in TIBCO Spotfire

Custom/External Authentication
in TIBCO Spotfire
INTRODUCTION
The 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
Analyst
Spotfire
Consumer and
Business
Author
Spotfire
iPad App
Security and
Routing Tier
Spotfire Server
Spotfire
Web Player
Worker
Service Tier
Data
Tier
Corporate LDAP
Spotfire Library and
Audit Database
Data Sources
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 AUTHENTICATION
Spotfire 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 EARLIER
Prior 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:
1. Authenticate
Portal Server
Web Browser
3. Cookie (Ticket)
2. Authenticate
4. Cookie (Ticket)
5. Ticket
Authentication
Service
6. User Name
Web Player Server
(C# Custom
Auth Code)
7. Impersonate (User Name)
Spotfire Server
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
Identity
Provider
User
Start Here
User tries to
access Spotfire
Web Player
Agent generates
SAML request and
sends redirect to
SSO URL
User’s browser
redirects to the
SSO URL
Form-Based
Authentication
Active Directory
Spotfire Server
returns
permissions for
User from LDAP
Authentication
Plugin extracts
identity from
SAML token and
creates Spotfire
Session
Web Player
configures user
interface based
on permissions
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
Identity Provider
parses SAML
request and
authenticates
User
Identity Provider
generates SAML
response and
sends to browser
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.
bSet 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>
dSave 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.5
As 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.
1. Authenticate
Portal Server
Web Browser
3. Cookie (Ticket)
2. Authenticate
4. Cookie (Ticket)
5. Ticket
Authentication
Service
6. User Name
Spotfire Server
(Java Authentication
Filter Code)
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
Tomcat
Agent
Identity
Provider
User
Start Here
User tries to
access Spotfire
Web Player
External
Authentication
and, if required,
Authentication
Filter extracts
identity from
SAML token and
creates Spotfire
Session
Spotfire Server
returns
permissions for
User
Agent generates
SAML request and
sends redirect to
SSO URL
User’s browser
redirects to the
SSO URL
Form-Based
Authentication
Agent verifies
SAML response
User’s browser
retries the original
request
Active Directory
Spotifre Server
configures user
interface based
on permissions
User’s browser
renders Spotfire
landing page; will
vary based on
permissions
Identity Provider
parses SAML
request and
authenticates
User
Identity Provider
generates SAML
response and
sends to browser
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/Setuser-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 TOPICS
This section covers advanced topics that provide additional information.
• PostAuthenticationFilter in Spotfire Server
• Custom authentication examples in 7.5 documentation
POSTAUTHENTICATIONFILTER IN SPOTFIRE SERVER
This 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 DOCUMENTATION
This 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 selfcontained:
• 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
Web Browser
3b. Cookie
(Ticket)
1. Authenticate
3a. User Provides
Credentials
4. Cookie (Ticket)
2. Redirect Browser to Service
IdentityProviderServlet
Authentication Service
5. Ticket
6. User Name
Spotfire Server
IdentityProviderAuthFilter
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.
Global Headquarters
3307 Hillview Avenue
Palo Alto, CA 94304
+1 650-846-1000 TEL
+1 800-420-8450
+1 650-846-1005 FAX
www.tibco.com
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