In this post I want to explore some help I provided a customer who was using the SAS Fallback authentication module. More information on the Fallback Module can be found in in the Middle-Tier Admin Guide. This customer wanted to be able to access the SAS Logon Manager form after configuring Integrated Windows Authentication without having to go through the custom error page. I looked at the different options we could use to make this work.
A long time ago in a galaxy far, far away…
Well almost, back in the first maintenance release of SAS 9.4, SAS included the fallback authentication module. This module allows customers to have several different authentication mechanisms live and working for their middle-tier.
Remember: The mechanisms supported by the fallback module are only those mechanisms internal to the SAS Web Application Server. Yes you – that means SAML is not going to work with the fallback module. Confused – go read the manual.
The module was written for some specific customers – but there is a great use case for practically all sites wanting to use Integrated Windows Authentication (IWA) for the middle-tier. This use case is trying to access some of the Administration functions after the you have enabled IWA. With just vanilla IWA you must work through and add all required roles & capabilities to each end-user, since the internal accounts are no-longer going to work. However, with fallback, all you need to do is access the web application in a browser not configured for IWA and you will get presented with the normal SAS Logon Manager form. You can then manually log-in with the internal account.
Also using the fallback module makes the configuration of IWA much easier. When using the fallback module all you need to change in the web.xml for the SAS Logon Manager is to uncomment the custom error page for 401. This is the key to how the fallback module works.
Essentially, all the custom error page does is to redirect to the SAS Logon Manager with an additional parameter "fallback=true". Since browsers not configured for IWA display the custom 401 error page rather than sending a Kerberos token this means the non-IWA browser gets sent to the SAS Logon Manager with the parameter sent. For example a broswer not configured for IWA automatically redirects requests for SASAdmin to:
So for this customer they are testing accessing the web applications from a different browser and having difficulties. Some of this is specific to this customer, but many customers have Internet Explorer as their standard browser and when this is unable to do IWA it quite often attempts NTML before displaying the 401 error page. This means the browser pops-up a login box for the user to attempt to type credentials. Using the pop-up box will not work and so it confuses the users. So the customer wanted a simple approach to make using the fallback module easier.
Having sent a draft of these materials to others at SAS it was suggested rather than the novel approach below I should instead "Keep it simple, stupid". Since the SAS 9.4 Middle-Tier automatically provides for Single Sign-On (SSO) between the applications. Remember, once you’ve logged into the Middle-Tier from one browser session you can access any other application from the same browser session without having to log in again. So if the first page you visit is https://servername:port/SASLogon/login?fallback=true, you’ll immediately see the SAS Logon Manager form. After you have logged in with the form you can then just access any of the other SAS web applications and you’ll remain logged in. The only thing is that post logon you’ll need to type the URL of the other application you want to access. As Leonardo da Vinci would put it "Simplicity is the ultimate sophistication".
What about cases where the user does not necessarily want to type one URL, log in, and then type another URL. Could we have a simple URL the customer could use to access the fallback version of the SAS Logon Manager specific for the application they are trying to access?
So what I’d thought about doing was to just add something simple to the standard SAS web application URL and have this redirected by the SAS Web Server to the correct page. What I ended up using for my testing is just "fb" for fallback. So typing https://servername:port/fb/SASAdmin will get me access to the fallback version of the SAS Logon Manager even in a browser configured for IWA and then on logon redirect me to the correct application.
Now for my testing environment I have TLS configured for the SAS Web Server. So my changes might be slightly different to your attempts if you don’t have TLS configured. Since I have TLS configured I’m looking at the:
Whilst if you are working with a site where TLS is not configured you’d be looking at the:
Remember: When you deploy a SAS web application with the SAS Deployment Manager the sas.conf file will be recreated and any changes you make will need to be put back.
The mechanism we will use to take the URL containing "/fb/" and redirecting this back to the SAS Logon Manager is the Rewrite module. In either the httpd-ssl.conf or the sas.conf you will find the line:
We need to remove the comment "#" from this line to enable the Rewrite Engine. Then we can add our new Rule to rewrite the URL:
There are three main sections to the rewrite rule; the first is a Perl compatible Regular Expression which is applied to the URL-path of the request. The pattern "^/fb/(.*)" will match any URL the starts /fb/. Also everything after the second forward slash will be placed into a variable that can be used in the rest of the rule.
The second part is the substitution. This needs to include the SAS Web Server hostname and port to ensure the request is correctly resubmitted rather than just a redirect to a directory local to the SAS Web Server. Then we have the "/SASLogon/login?service" part of the URL we want to redirect to. To ensure the equals sign is correctly processed this is escaped with a backward slash so "\=". Then we have an encoded representation of the SAS Web Server hostname and port number, where "%3A" is a ":" and "%2F" is a "/". Next we have the part of the original URL with the "$1" and then finally the "j_spring_cas_security_check" and the all-important "&fallback=true".
The final part of the rule is a set of flags. Where we have the following:
If your SAS Web Server is not configured for TLS then you should use HTTP rather than HTTPS in your RewriteRule.
So with the rule in place I can access any of the SAS web applications at https://servername:port/fb/SASApplication and get the SAS Logon Manager form even if the browser is configured for IWA. Since the change is not impacting any other parts of the infrastructure and we’re using a standard URL once we get to the SAS Logon Manager it has no implications for using the applications.
Finally, if you want to get rid of the rule and are concerned that your users might have book marked the URL’s with "/fb/" in them just change the rule to the following:
This will just send any requests for https://servername:port/fb/SASApplication to https://servername:port/SASApplication.