Spotfire Ideas Portal
We currently use the Authentication Filter capability (which has been deprecated) of Spotfire to implement a couple of features that don't appear to be possible with the CustomAuthenticator API:
It has been suggested that we can use the CustomWebAuthenticator or a custom login page to achieve these steps, but I can't see how that could work (particularly because we're using NTLM authentication if there isn't a token provided).
I'm going to work around the redirection requirement by adding login on our F5 load balancers (they can intercept the 401 response from Spotfire and redirect under appropriate conditions).
I have no way yet to get access to the HttpServletResponse object, other than to start creating filters and attaching them to Tomcat by hacking at the web.config file, which seems drastic!
The CustomWebAuthenticator works like this: when a user needs to be authenticated the getAuthenticationEndpoint method gets called - and the implementation returns a URL (to the IdP, with request parameters and such as needed). The server then redirects the browser to this URL. The IdP should then send the browser back to /spotfire/auth/custom/authenticate - at which the authenticateWeb method gets called.
This can be used to implement SAML when using the Redirect Binding (but obviously doesn't support the POST Binding or such).
If you want to combine SAML and NTLM you can let the LB handle NTLM authentication and simply pass the identity in a header or such - which you can then pick up, possibly using a CustomAuthenticator if you need to validate it (perhaps that's what you're currently doing?).
Thanks Jens. There are a couple of different scenarios I'm working with.
1. We have a SAML based SSO solution which can provide the user identity in a cookie (as you say this means we're restricted to same domain, but that's fine). We use a CustomWebAuthenticator to look for this cookie and validate it. If the cookie is missing (or expired) and the request came from our external load balancers (we assign an HTTP header from the load balancer to indicate external vs. internal) we redirect the browser to the SAML IdP, with a URL parameter that allows the IdP to redirect back to Spotfire once the user has authenticated. Requests from internal machines drop through without redirection to allow NTLM SSO (again we check for the HTTP header from the load balancer). It is perfectly normal for users to arrive at Spotfire with or without a cookie (e.g. they may have already logged into another application sharing the SSO). I don't see how CustomWebAuthenticator supports redirection - guess I'm missing something?
2. We attach a cookie after the user has signed in to pass information to a tool I've built for tracking use of Web Player. I have a custom header set up for Web Player that embeds some JavaScript on the page that then calls RESTful services to track use information - the cookie is used to pass the username between Spotfire and the RESTful services. I only need this solution because the JavaScript has no other way to figure out who the Spotfire user is.
Could you please elaborate a bit?
A CustomWebAuthenticator can be used for implementing authentication scenarios where the user should be redirected to an identity provider (and then returned to the Spotfire Server) - like the Authorization Code flow of OAuth2. Information is then usually transferred in the URL (as request parameters).
You mention that a cookie is used to transfer information between the Spotfire Server and the IdP (if I understand it correctly). While I guess that works when the Spotfire Server and the IdP reside under the same domain it seems like passing the information as request parameters should be a better way (the CustomWebAuthenticator API allows you to build the URL to which the user should be redirected, and allows request parameters to be included when redirecting back).