custom authentication in tibco spotfire 7.5 and later · custom authentication in tibco spotfire...

July 2016

Custom Authentication TIBCO Spotfire 7.5/7.6

Custom Authentication in TIBCO Spotfire 7.5 and

later Introduction

Use Cases for Custom/External Authentication

Custom Authentication in TIBCO Spotfire 7.0 and Earlier

Custom Authentication in TIBCO Spotfire 7.5 and Later o Details for TIBCO Spotfire 7.5 o Details for TIBCO Spotfire 7.6 and Later

Advanced Topics

Introduction The main shift from TIBCO Spotfire 7.0 and earlier versions to TIBCO Spotfire 7.5 and later versions is a seemingly simple architecture change: The 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 all connect to the Spotfire Server in order to be serviced.

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

Other documents including the TIBCO Spotfire Server Installation Manual have detailed information about the architectural differences. This document focuses on just what is important in light of custom and external authentication to the Spotfire environment. Many customers embed TIBCO Spotfire Web Player into a portal or other web application or have a corporate single-sign-on method that is used to authenticate to any internal web applications. Prior to TIBCO Spotfire 7.5, this method of authentication has usually been called “Custom Authentication” because it required custom C# coding on the Web Player. In TIBCO Spotfire 7.5 and later versions, since

July 2016


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 discusses the various options with custom and external authentication. The first section reviews how TIBCO Spotfire handled this method of authentication prior to TIBCO Spotfire 7.5.

Use Cases for Custom/External Authentication TIBCO Spotfire supports an almost unlimited set of possible configurations. For the purposes of this document, we have focused on the following major use cases:

I want to... Available tools

Embed Spotfire Visualizations in my Web portal application, e.g. SharePoint or other portal.

Use Web Player Custom Authentication in Spotfire 7.0

and earlier; Configure External Authentication in Spotfire

7.5 and later (may need extra coding in Spotfire 7.5 and

later)

Secure Spotfire Web Player using the corporate Web application Single-Sign-On technology



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 passed to Spotfire Server (e.g. group membership, permissions, etc.)



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 TIBCO Spotfire 7.5, the technology to do this has been referred to as “Web Player Custom Authentication” (http://stn.spotfire.com/stn/Tasks/ImplementingCustomAuthentication.aspx). One reason for the name, “Custom Authentication,” is that it required one to write a bit of C# code, place the compiled DLL on the Web Player Server, and modify the Web.Config file in order 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, e.g. portal login, single-sign-on mechanism, SAML token, etc.

http://stn.spotfire.com/stn/Tasks/ImplementingCustomAuthentication.aspx

July 2016


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

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 Web Player (4). The custom authentication component on the 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:

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

July 2016


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 Providers 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 Providers 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 Providers 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 Corporate LDAP, and returns the information to the Web Player.

10

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 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 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 the Web Player is controlled by an IIS agent from the SSO solution which checks that all access to the Web Player has been authenticated. In these cases, the code can be simple since 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. using System.Security.Authentication;

using System.Security.Principal;

using System.Web;

July 2016


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, e.g. 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 Web Player Custom Authentication in the Spotfire Development Kit which can be used as a starting point. One needs 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. Once one has 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 Web Player Web.config file

(a) Edit authentication to match the Anonymous Authentication from the Web Player installation manual

July 2016


(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 Web Player application automatically because the Web.config file changed, but if anything seems unusually, one can stop and restart the 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. Once these steps are completed, then the custom authentication should work in the Spotfire environment. As an aside, some OEM customers pass extra information (e.g. 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 TIBCO Spotfire 7.5, how the custom authentication is implemented does change and is discussed in the next section.

Custom Authentication in TIBCO Spotfire 7.5 and Later As mentioned above, because the architecture changes in TIBCO Spotfire 7.5, different tools and configurations will be used to support the external authentication integration. In this section, “External Authentication” and “Custom Authentication” will be used interchangeably. The configuration option in TIBCO Spotfire 7.5 and later versions is labeled “External Authentication” in the UI Configuration Tool. In versions of TIBCO Spotfire prior to 7.5, some combinations of different authentication methods are allowed on Web Players and Spotfire Servers. For example, one could setup Web Players with custom authentication for external users and have Web Players for internal users with a different authentication method. With TIBCO Spotfire 7.5 and later, all authentication is done on Spotfire Server. There are some authentication methods that are allowed simultaneously; External Authentication is one of those. One can configure External Authentication and another method of authentication in order to support these use cases.

July 2016


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

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 custom authenticator (7.6 and above) or the authentication filter (7.5 and above) 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 custom authenticator or authentication filter then sets the user principal for the session using the user identity provided by the Authentication Service. For simpler scenarios, the use of custom coding will not be required and can be supported by the Spotfire Server External Authentication configuration options. This will be discussed in more detail later in this section.

July 2016


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

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 Providers SSO Service.

3

The Tomcat 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 Providers 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.

July 2016


7

The Tomcat Plugin verifies the SAML token using the Identity Providers 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 a Custom Authenticator or 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 one is using External Authentication for web browser users, then typically one will need a method of authentication for users connecting via Spotfire Analyst. Since all users now connect to Spotfire Server, it will have to handle both methods. This screen shot shows the authentication configured for username/password using the Spotfire database and then 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.

If all one needs to do is pull out a user identity from the HTTP Attribute, Header or Cookie, then no custom code is needed. But if one needs to pull out an encrypted token or do something more with the identity, then a Custom Authenticator or an Authentication Filter is needed. For the simpler case, one can use the External Authentication configuration to pull out the appropriate HTTP element. This screenshot from Spotfire Server Configuration Tool shows the type selected as (HTTP) Header and the Header to look for is REMOTE_USER.

July 2016


In addition to configuring where the identity is passed in the HTTP information, one can configure some constraints that will make the connection more secure, e.g. requiring SSL, allowed hosts and allowed IPs. The allowed IPs allow one to use regular expressions to allow blocks of IPs, e.g. 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 one needs more complex processing than just pulling out a Header, Attribute or Cookie value, then one will need to write custom code. Since Spotfire Server is based on Tomcat, a Java web application container, any custom coding needed in TIBCO Spotfire 7.5 and later will be Java code. If custom coding is needed with TIBCO Spotfire 7.5, then this is done using a Java Authentication Filter which will be shown below in the Details for TIBCO Spotfire 7.5 section. With TIBCO Spotfire 7.6, an additional API, a CustomAuthenticator interface, was added which makes custom authentication in TIBCO Spotfire 7.6 very similar to the older custom authentication on the TIBCO Spotfire Web Player. The ability to use the Authentication Filter is still possible, but, typically, users will use the CustomAuthenticator API which is part of the Server Platform API. The CustomAuthenticator simplifies the implementation and is more integrated into the Spotfire platform. There still may be use cases where the Authentication Filter is necessary. Since the Authentication Filter is earlier in the chain, it can be used when you need to perform a redirect or alter the HTTP response. For TIBCO Spotfire 7.6 and later, the use of the Custom Authenticator is recommended and should be used whenever possible. The Custom Authenticator is discussed in the Details for TIBCO Spotfire 7.6 and Later section.

https://docs.tibco.com/pub/spotfire_server/7.6.0/doc/api/TIB_sfire_server_Server_Platform_API_Reference/platform/index.html?com/spotfire/server/security/CustomAuthenticator.html

July 2016


Details for TIBCO Spotfire 7.5

As mentioned previously, if the external authentication configuration options are not enough to support the custom authentication needed with TIBCO Spotfire 7.5, then one will need to write an Authentication Filter. This section discusses some examples and how to configure TIBCO Spotfire Server to support this. The TIBCO 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 TIBCO Spotfire Server download package. On the docs.tibco.com site, the documentation and sample code are available from the TIBCO Spotfire Server 7.5 page: https://docs.tibco.com/products/tibco-spotfire-server-7-5-0 These examples 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, e.g. the IdentityProviderAuthFilter redirects to an authentication service and then returns to the originally requested URL. The Appendix provide some discussion of these examples. In more complex situations, in order to get the authentication information from the HTTP request and pass it onto the Spotfire environment, one needs to write a Tomcat Filter to process the authentication information and an HttpServletRequestWrapper to hold the user principal information. One cannot directly set the user principal in the HTTP request, and therefore one has to write a wrapper to hold this information. Below is sample code which was 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 org.apache.log4j.*;

/**

* 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);

/**

* Default constructor.

https://docs.tibco.com/products/tibco-spotfire-server-7-5-0

http://www.coderanch.com/t/466744/Servlets/java/Set-user-principal-filter

July 2016


*/

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

}

}

/**

* @see Filter#init(FilterConfig)

*/

public void init(FilterConfig fConfig) throws ServletException {


}

}

The key lines in the code are marked:


July 2016


Line #2 – checks to see if the value is null. If the value is null, one 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 to for browser users. Spotfire Analyst users will always use the non-external authentication method.

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

o Line #2b – processes the found user name; in this example case, just reversing the string. This is where one 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 in order 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 which is just a simple wrapper around the HTTPServletRequestWrapper that allows one 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;

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;

}

};

}

}

July 2016


As a reminder, for the simple cases, this custom coding is not required. It is only required if one must do more processing with the value obtained. The External Authentication configuration in TIBCO 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, one sets the Type in the External Authentication to “Authentication Filter” as seen in this screen shot:

With the External Authentication set to “Authentication Filter,” one needs 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 :

If needed, one can pass in initialization parameters that set various items, e.g. an Authentication Service URL. After one makes the configuration changes, one needs to save the configuration changes, deploy the compiled jar file to Spotfire Server and restart Spotfire Server. I used the Eclipse IDE and linked to

July 2016


the JRE from the Spotfire Server installation, the server.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, one should be able to use the updated authentication methods and test out that it recognizes the correct user values. If there are any issues, one should 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 there are other issues with the authentication filter.

July 2016


Details for TIBCO Spotfire 7.6 and Later In TIBCO Spotfire Server 7.6 and Later, the ability to create a Custom Authenticator is available. The Custom Authenticator is very similar to the older custom authentication available on TIBCO Spotfire Web Player. What needs to be implemented is simpler than the Authentication Filter available for 7.5. The CustomAuthenticator class contains an init method for initializing parameters and an authenticate method for performing authentication and returning the user principal information. The Authentication Filter is still available for TIBCO Spotfire 7.6, but it is strongly recommended that users use the Custom Authenticator whenever possible. This section discusses how to configure TIBCO Spotfire Server and provides a simple example of a CustomAuthenticator. As with the Authentication Filter, the Custom Authenticator is for more complex situations in which the out-of-the-box External Configuration settings are not enough. In these complex situations, in order to get the authentication information from the HTTP request and pass it onto the Spotfire environment, one needs to write a Java CustomAuthenticator to process the authentication information and create a CustomAuthenitcatorPrincipal for the user principal information. package com.tibco.spotfireps.server.security;

package com.tibco.spotfireps.server.security;

import java.util.Map;

import org.apache.logging.log4j.*; // Spotfire 7.9 and above (Log4J2) - log4j-api.jar

//import org.apache.log4j.*; // Spotfire 7.8 and below (Log4J) - log4j.jar

import com.spotfire.server.security.AuthenticationContext;

import com.spotfire.server.security.CustomAuthenticator;

import com.spotfire.server.security.CustomAuthenticatorException;

import com.spotfire.server.security.CustomAuthenticatorPrincipal;

public class TestCustomAuthenticator implements CustomAuthenticator {

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

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

@Override

public CustomAuthenticatorPrincipal authenticate(AuthenticationContext authContext)

throws CustomAuthenticatorException {

CustomAuthenticatorPrincipal authPrincipal = null;

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

String userName = authContext.getHeader("UserHeader"); <- Line #1

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

{

s_log.info("No UserName Specified – assume another method of authentication ");

// Do not want to throw exception or other authentication will not be checked.

// For example, users using Spotfire Analyst will not be able to login

// throw new CustomAuthenticatorException("No UserName Specified - assume

another method of authentication");

}

else

{

String fixedUser = new StringBuffer(userName).reverse().toString(); <- Line #2a

s_log.info("Setting UserPrincipal - " + fixedUser);

https://docs.tibco.com/pub/spotfire_server/7.6.0/doc/api/TIB_sfire_server_Server_Platform_API_Reference/platform/index.html?com/spotfire/server/security/CustomAuthenticator.html

July 2016


authPrincipal = new

CustomAuthenticatorPrincipal(fixedUser, "SPOTFIRE", null, null); <- Line #3

}

return authPrincipal; <- Line #4

}

public void init(Map parameters) throws CustomAuthenticatorException {


}

} The key lines in the code are marked:


Line #2 – checks to see if the value is null. If the value is null, one can either deny access (throw an exception) or pass onto other methods of authentication (return a null principal). If External Authentication is configured with another authentication method, then the second method will be chained to for browser users. Spotfire Analyst users will always use the non-external authentication method. If an exception is thrown, then most likely Spotfire Analyst users will be denied access because Spotfire Analyst will not be providing the correct header information.

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

Line #3 – create the CustomAuthenticatorPrincipal; in this example, only the user name and domain name are set.

Line #4 – return the created principal or null if no user name found. The value of null will imply to TIBCO Spotfire Server that another method of authentication should be checked.

As a reminder, for the simple cases, this custom coding is not required. It is only required if one must do more processing with the value obtained. The External Authentication configuration in TIBCO Spotfire Server 7.5 and Later should handle the majority of the cases without requiring any custom coding. To configure Spotfire Server to use the Custom Authenticator, one sets the Type in the External Authentication to “Custom Authenticator” as seen in this screen shot:

July 2016


With the External Authentication set to “Custom Authenticator,” one needs to set the Class name for the CustomAuthenticator class in the text box below the type. In this example, the Class name is set to: com.tibco.spotfireps.server.security.TestCustomAuthenticator and there are no parameters configured. If needed, one can pass in initialization parameters that set various items, e.g. an Authentication Service URL. After one makes the configuration changes, one needs to save the configuration changes, deploy the compiled jar file to Spotfire Server and restart Spotfire Server. I used the Eclipse IDE and linked to the JRE from the Spotfire Server installation, the server.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, MyCustomAuthFilter.jar has been copied to the spotfire\WEB-INF\lib directory.

After Spotfire Server is restarted, one should be able to use the updated authentication methods and test out that it recognizes the correct user values. If there are any issues, one should 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 there are other issues with the custom authenticator.

July 2016


Advanced Topics This section covers advanced topics that are here to provide additional information and discussion if needed.

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. The post authentication filter 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 one might need to write a Java post authentication filter.

In addition to the filter mode, one 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. This 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 which 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_Fil

https://docs.tibco.com/pub/spotfire_server/7.5.0/doc/api/TIB_sfire_server_Custom_Authentication_Filter_API_Examples.zip

July 2016


ter_API_Examples.zip. The Java documentation is also on-line 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

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 (seen below) and then checks the user database to check the user authentication.

Figure 5 SimpleAuthFilter Login Screen

This example 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

https://docs.tibco.com/pub/spotfire_server/7.5.0/doc/api/TIB_sfire_server_Custom_Authentication_Filter_API_Examples.zip

https://docs.tibco.com/pub/spotfire_server/7.5.0/doc/api/TIB_sfire_server_Custom_Authentication_Filter_API_Reference/javadoc/index.html

https://docs.tibco.com/pub/spotfire_server/7.5.0/doc/api/TIB_sfire_server_Custom_Authentication_Filter_API_Reference/javadoc/index.html

July 2016


example contains a servlet for simulating an authentication service and the authentication filter. Here is the flow with the class names:

Figure 6 Spotfire Server 7.5 Identity Provider example

The Identity Provider documentation provides details around 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 which 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.

custom authentication in tibco spotfire 7.5 and later · custom authentication in tibco spotfire...

Documents