BookmarkSubscribeRSS Feed

How to Configure a Reverse Proxy in Front of SAS Viya Web Applications

Started ‎07-02-2019 by
Modified ‎07-02-2019 by
Views 11,644

You may have noticed that the SAS Viya 3.4 administration guide has been recently updated with new information about how to configure an external reverse proxy in front of SAS Viya web applications. Maybe you already deployed a reverse proxy to access Viya, and are wondering why this recent addition. Given the right conditions, maybe yes, your existing setup is already fine. But if you want to be in a supported environment, it's better to verify that all requirements are met.


A previous article describes how Apache HTTP Server is used to route both external and internal connections to active microservices ( including web applications), using SAS Configuration Server for service discovery. Here, we dig deeper into how that relates to an external reverse proxy and what changes are required to get a fully functional environment.

Internal and external routes

When the sas-httpproxy microservice starts, it registers two "logical services" in the SAS Configuration Server:

  • viya - this is the "external facing" route
  • httpd - this is the "internal facing" route



Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.


The picture above shows an external connection (red arrows) from a browser proxied through the Apache HTTP Server to reach SAS Studio 5. SAS Studio itself then opens an internal connection (blue arrows), for example to talk to the SASLogon microservice, and this connection is proxied as well.


By default sas-httpproxy registers both services with the same address - using "hostname -f" of the machine where it is running. It also configures the SAS Configuration Server to perform health checks for both services.


You can verify the addresses registered for these services with the following code on any machine part of the Viya deployment:


. /opt/sas/viya/config/consul.conf
export CONSUL_TOKEN=$(sudo cat /opt/sas/viya/config/etc/SASSecurityCertificateFramework/tokens/consul/default/client.token)
/opt/sas/viya/home/bin/sas-bootstrap-config catalog serviceurl viya
/opt/sas/viya/home/bin/sas-bootstrap-config catalog serviceurl httpd


Let's expand the previous view to include the backend servers that talk to microservices: CAS and the Launcher Server.




  • Services that create external links, such as Report Distribution, use the URL associated with viya. (red dotted line)
  • Services that need an internal connection use the URL registered for httpd. (blue line)
  • The Launcher Server uses the URL registered in another property, sas-services-url; if that is undefined, it defaults to httpd. (black dotted line)
  • CAS does not use any of that: it relies on its own set of properties, which, by default, also correspond to the same URL registered for httpd. (black dotted line)

Adding an external proxy

After deploying an external proxy in front of the Viya environment, the view changes again:




The good news is that Viya uses relative URLs. This means that, when end-users enter the address of the front-end proxy in their browser, it is preserved for all browser navigation and all their connections use that route. Many times, this simply works. To be sure that it always works, the administration guide provides the following additional steps:

  1. On the external reverse proxy, set the X-Forwarded-Proto and X-Forwarded-Port headers to the protocol and port that the client is using to connect to the external reverse proxy.
  2. From the SAS Viya internal Apache HTTP server machine, comment out the X-Forwarded-Proto and X-Forwarded-Port lines in the petrichor.conf file as follows:
    1. a. Locate the petrichor.conf file according to the platform used:

      Unix /etc/http/conf.d
      Suse Linux /etc/apache2/conf.d
      Windows C:\ProgramData\SAS\Viya\etc\httpd\conf.d
    2. b. Make a backup copy of the petrichor.conf file.
    3. c. Locate the following lines in the petrichor.conf file:

      # Default the X-Forwarded-Proto header to http
      RequestHeader set X-Forwarded-Proto http
      # Set the X-Forwarded-Proto header if request is over HTTPS
      RewriteCond "%{HTTPS}" "on"
      RewriteRule ^.*$ - [ENV=HTTPS:true]
      RequestHeader set X-Forwarded-Proto https env=HTTPS
      RequestHeader set X-Forwarded-Port 443 env=HTTPS
    4. d. Comment out these lines so that they appear as follows:

      # Default the X-Forwarded-Proto header to http
      #RequestHeader set X-Forwarded-Proto http
      # Set the X-Forwarded-Proto header if request is over HTTPS
      #RewriteCond "%{HTTPS}" "on"
      #RewriteRule ^.*$ - [ENV=HTTPS:true]
      #RequestHeader set X-Forwarded-Proto https env=HTTPS
      #RequestHeader set X-Forwarded-Port 443 env=HTTPS
  3. Start (or restart) the SAS Viya internal Apache HTTP Server.

Some requirements for this to work are:

  • The external reverse proxy must use HTTPS (just like the internal one).
  • The external reverse proxy must forward requests through the SAS Viya internal Apache HTTP Server without changing the URL path.

Additional configuration

With this first change, end-users routes should be OK, but that may not be enough. Viya components may not be aware of the front-end proxy: addresses that are created by the platform may keep pointing to the Viya Apache HTTP server, bypassing the front-end proxy (see for example the red dotted line in the above picture).


To have all external connection come through the external proxy, an additional step may be required : the viya service registration should be modified to point to the external proxy.




As a side effect, the SAS Configuration Server will start monitoring the external proxy. After the change, impacted services should be restarted.


To point the viya service to the external proxy, set the following properties in the SAS Configuration Server:


config/viya/sas.httpproxy.external.hostname = ''
config/viya/sas.httpproxy.external.port = '443'


This can be done :

  • before the deployment, specifying the properties in the sitedefault.yml file
  • post-deployment, by loading the properties with the sas-bootstrap-config CLI as follows:
. /opt/sas/viya/config/consul.conf
export CONSUL_TOKEN=$(sudo cat /opt/sas/viya/config/etc/SASSecurityCertificateFramework/tokens/consul/default/client.token)
/opt/sas/viya/home/bin/sas-bootstrap-config kv write config/viya/sas.httpproxy.external.hostname
/opt/sas/viya/home/bin/sas-bootstrap-config kv write config/viya/sas.httpproxy.external.port 443


After this change, restart the reportdistribution and reportalerts services. For example, on a RHEL 7 system , the commands would be:


sudo systemctl restart sas-viya-reportdistribution-default
sudo systemctl restart sas-viya-reportalerts-default

Final considerations

Notice how there is no need to change the configuration of any other components. CAS, the Launcher Server, and most microservices use internal connections, so they keep pointing to the original Viya httpd URL - the address of the internal Apache HTTP Server.


This may not be true for clustered environments, where there are multiple instances of Apache HTTP Server. But that will be the topic of another article.


Hi Edoardo, thank you, an informative blog.


A couple of questions/clarifications.


On the single server 3.4 install I have, the 'petrichor.conf' file is within the '/etc/httpd/conf.d/' directory, however it's a symlink:


ansible -i inventory.ini -m shell -a "ls -l /etc/httpd/conf.d/" -b all

lrwxrwxrwx. 1 sas  sas    62 Jun 14 08:58 petrichor.conf -> ../../..//opt/sas/viya/config//etc/httpd/conf.d/petrichor.conf

Would it make sense to update the file it points to directly, so removing any risk of the symlink getting inadvertantly overwritten?


It also makes me think what would happen if the 'site.yml' were run again, to apply hotfixes for example, could this file get reverted back to its original state as it's within the '/opt/sas/viya' set of directories?





Hi Edoardo.Thanks for sharing this. Is it possible to use Nginx instead of Apache as http-server?

Hello @alancox.

You are correct, the file under /etc/httpd/conf.d is simply a link to /opt/sas/viya/config/etc/httpd/conf.d/petrichor.conf . This way we can keep all SAS-related files under /opt/sas.

You also correct that, when re-running the site.yml to apply fixes, the changes you make to that file may get overridden, so you'd have to redo the same changes each time.

As for where to perform the edit, it should not matter.



Hello @frobi .

You are free to choose your preferred software/hardware to place in front of a Viya installation to act as a reverse proxy, as described in this post.

On the other side, the HTTP server that is deployed within Viya to act as a service router has to be Apache httpd with mod_ssl, as detailed in the SAS® Viya® 3.4 for Linux: Deployment Guide.


Hi Edoardo! Thanks for your explanation!

A (belated) thanks Edoardo!

Hi Edoardo,

It's been over a year since you post this fantastic article. However, I still hope you can reply my question after such long period of time. Thanks in advance.


My question - I've done every steps you mentioned in this article and I was expecting to see the following effect (but the result was not)

1. Put original address in a web browser: https://xxx/SASDrive

2. The web page should be redirect to:

3. In another word, I want to conceal the SASLogon web page, and every login should go through first


However, I can still see the SASLogon web page. Could you give me some clue about why?





Hello Adrian,

the configuration described in this post opens a second door to the Viya environment - the front-end reverse proxy - but the "original door" is still there and still open, as you have experienced.

First of all, it is not possible to completely disable the original SAS Viya Apache web server - the "original door" - because it is required for all the connections coming from the inside. In the last picture, these are the connections labeled CAS, Launcher, and httpd coming from the bottom.

If you want to prevent end-users from accessing the original address, you have multiple options, depending on the IT practice at your site. A couple of ideas that pop to the top of my mind:

  • place a firewall in front of it - blocking any connection not coming from the proxy of from Viya - or
  • create a rewrite rule in Apache to redirect to the proxy every connection coming from outside and not having the proper proxy headers

Dear @EdoardoRiva ,


Many thanks for this amazing article, you made a complex topic simple and easy. The images were done well and made me understand the concept easily.


I have one question which is a bit unusual but one of our customers don't want to use HTTPS between his reverse proxy and SAS Viya. he even said don't use SSL/TLS in your deployment we will do SSL handling and SSL offloading on our reverse proxy.

 So basically in his infrastructure all vendor's applications sets behind his reverse proxy without SSL/TLS and he handles encryption and security at his entry point.


So end users will talk to their company's reverse proxy using HTTPS and then an SSL offloading happens at the reverse proxy, and a clear HTTP communication happens between reverse proxy and any backend application, like SAS Viya in this case.


But the online documentation has below requirement:

- The external reverse proxy must use HTTPS 


Not sure if this requirement is mandatory in case we are integrated with the Apache HTTP Server on port 443 or this requirement is mandatory whether integrating with port 80, 443 or any other port.


Do you have an idea if this kind of integration can happen between client's reverse proxy and Apache HTTP Server on port 80 using HTTP only?  And if it is possible what changes do we have to do at the Apache level and SAS Viya level, since the official publish changes talks about 443 and HTTPS.


Thank you,


We require HTTPS for security considerations; for that reason, it's the only use case that has been tested.

Feel free to open a track with SAS technical support to get help evaluating this specific environment.

Version history
Last update:
‎07-02-2019 03:25 PM
Updated by:



Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.

If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website. 

Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags