Custom/External Authentication in TIBCO Spot˜re · PDF fileauthentication” that...

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Custom/External Authentication in TIBCO Spot˜re · PDF fileauthentication” that...

  • 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


    Security andRouting Tier

    Worker Service Tier


    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 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:


    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 extracoding).

    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 SpotfireServer.

    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 thisdocument).

    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. (

    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.


    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 thosesteps:

    Spotfire Server

    Spotfire Web Player IIS Agent User


    Start Here

    User tries to access Spotfire

    Web Player

    Users browser redirects to the


    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


    Authentication Plugin extracts identity from

    SAML token and creates Spotfire


    Web Player configures user interface based on permissions

    Spotfire Server returns

    permissions for User from LDAP

    Active Directory

    Agent verifies SAML response

    Users browser retries the original


    Users browser renders Web Player page

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


    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 users 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 users 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 users 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 users 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 users permissions to render the user interface and control access to retrieve and process data with the Spotfire data engine.

    11 The users 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.


    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];


    After youve 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\\webroot\bin folder.

    2 Modify Spotfire Web Player Web.config file:

    a Edit authenticatio