BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
bheinsius
Lapis Lazuli | Level 10

Hi,

 

I have a SAS 9.4M5 web environment on http://server1.internal:7980/.

I want to make it possible to run SAS Stored Processes on this server from the internet on https://mysite.example.com/ through a reverse proxy on a separate Apache instance.

 

I got a part working with this in the Apache instance:

 

<location /SASStoredProcess/>
ProxyPass http://server1.internal:7980/SASStoredProcess/
ProxyPassReverse http://server1.internal:7980/SASStoredProcess/
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
</Location>

 

<location /SASLogon/>
ProxyPass http://server1.internal:7980/SASLogon/
ProxyPassReverse http://server1.internal:7980/SASLogon/
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
</Location>

 

 

in combination with changing the External Connections of these applications in SAS Management Console to:

 

Communication Protocol: HTTPS

Host Name: mysite.example.com

Port Number: 443

Service: /SASStoredProcess

 

resp. 

 

Communication Protocol: HTTPS

Host Name: mysite.example.com

Port Number: 443

Service: /SASLogon

 

When navigating to https://mysite.example.com/SASStoredProcess/ I am redirected to https://mysite.example.com/SASLogon so that looks to be working ok.

But after entering my credentials I get:

 

HTTP Status 401 – Unauthorized

 

Am I doing this right? Is there documentation on how to do this?

 

Bart

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

If you haven't done so already, it'd also be worth looking in (and posting) any relevant errors you see in your Apache and the SAS Web Server error logs files, and the SAS Web Application Server log files, to see if there is a reason logged for the HTTP 401 response.

 

I assume you have also seen these resources:

  1. Configuring the Middle Tier to Use an Existing Customer Reverse Proxy
  2. Whitelist of Websites and Methods Allowed to Link to SAS Web Applications

The first one is more about bypassing the SAS Web Server and connecting your Apache directly to the SAS Web Application Server rather than your Apache > SAS Web Server (Apache) > SAS Web Application Server (i.e. having 2 Apache web servers in front of the SAS Web Application Server).

 

I remember running into the white list issue a while back when I did a config change, but can't remember whether it returned 401 or 403.

View solution in original post

12 REPLIES 12
JuanS_OCS
Amethyst | Level 16

Hello Bart, @bheinsius,

 

 

I think there are no better guides as Apache's or the SAS one:

 

https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html

http://documentation.sas.com/?docsetId=bimtag&docsetTarget=n0y2fq741xmw8nn1btstcnwnq3jj.htm&docsetVe...

 

In order to keep it simple, I also think that, most probably, a reverse proxy is way too much for what you want to achieve. Meaning there are many other possible solutions:

 

- If you or your project feel more comfortable with another Web Server (IIS, or anything else), please use it, it will help with configuration. Otherwise, you will need a good Apache admin, or a Web Developer, they know well this stuff.

 

- The next step of simplification: perhaps you can just use rewrite and redirect https://httpd.apache.org/docs/2.4/rewrite/remapping.htmlhttps://httpd.apache.org/docs/2.0/misc/rewriteguide.html

 

- And then even another step for simplification. If the reverse proxy you are looking for is only for managing alias redirection, not security or whatsoever, perhaps you can just speak with the network guys. They should be able to create a redirect and even rewrite rules on a alias to another alias, directly on the routing/network system, without further effort from your side.

 

I hope it helps,

 

Kind regards,

Juan

PaulHomes
Rhodochrosite | Level 12

If you haven't done so already, it'd also be worth looking in (and posting) any relevant errors you see in your Apache and the SAS Web Server error logs files, and the SAS Web Application Server log files, to see if there is a reason logged for the HTTP 401 response.

 

I assume you have also seen these resources:

  1. Configuring the Middle Tier to Use an Existing Customer Reverse Proxy
  2. Whitelist of Websites and Methods Allowed to Link to SAS Web Applications

The first one is more about bypassing the SAS Web Server and connecting your Apache directly to the SAS Web Application Server rather than your Apache > SAS Web Server (Apache) > SAS Web Application Server (i.e. having 2 Apache web servers in front of the SAS Web Application Server).

 

I remember running into the white list issue a while back when I did a config change, but can't remember whether it returned 401 or 403.

123456789123456
Fluorite | Level 6

Paul,

 

Can you please confirm that if one does have a a 3rd party web server acting as a reverse proxy to the SAS 9.4 middle tier, the SAS Web authentication steps as laid out in the document below will not work, because like you said, the SAS Web Server is being bypassed in a reverse proxy configuration, 

 

do we in this case have to install the 3rd party SSO web authentication module at the reverse proxy web server and make that reverse proxy web server pass the authenticated user credentials in the HTTP header to the SAS Web Application Server ?

 

 

(http://go.documentation.sas.com/?docsetId=bimtag&docsetTarget=n1bhp608f0hsoen10i1vi0p9l5f7.htm&docse...)

 

 

Thanks !

JuanS_OCS
Amethyst | Level 16

Hello @123456789123456,

 

you have a repeated question at https://communities.sas.com/t5/Administration-and-Deployment/Deployment-of-third-party-web-server-in...

 

For you and anyone else interested in this question, there is an answer and follow up on that post open by @123456789123456

123456789123456
Fluorite | Level 6

Hi  

 

 

 

JuanS_OCS
Amethyst | Level 16

Hello @123456789123456,

 

ok, that makes sense!

 

Reviewing your question, not sure why Paul said that, but please read:

In the same Configuring the Middle Tier to Use an Existing Customer Reverse Proxy document refered by Paul:

http://documentation.sas.com/?docsetId=bimtag&docsetTarget=p0sxhuco18v167n13dsmnrfqv7yy.htm&docsetVe...

 

Some network topologies already have a web server that is used to proxy connections. In these deployments, you can reconfigure the SAS middle tier so that it interacts with the existing web server. In these network topologies, it is simplest to keep SAS Web Server in the deployment so that it can continue to load balance connections to a SAS Web Application Server cluster.

So: Reverse Proxy >> SAS Web Server >> SAS Web Application Servers , it is a must.

 

What I mean, is that with the Reverse Proxy you won't bypass the SAS Web Server. Actually, if you read carefully the document, there is a reference to manual tasks, even to the Whitelist mentioned by Paul, but no change on the Reverse Proxy server, because the document will Integrate the reverse proxy server with the current SAS deployment, not to Substitute anything.

 

Hence, I think you will need to implement the Single Sing-On configurations on the SAS Web Application Server, the SAS Web server, and your reverse proxy.

 

I would recommend you to start with just your SAS Web Server and SAS Web Application Server, test if SSO works and only move forward to implement Reverse Proxy and SSO on reverse proxy once the previous steps are done and validated. Of course, all can be done in a single shot, but SSO is a fragile configuration where the encryption (KRB) is sensible, too many steps must be done without previous validation, and you are including also reverse proxy, and SSO on the proxy. That is why I would take it step by step. A single error can be really hard to trace back to its origins. And that considering only a single error.

PaulHomes
Rhodochrosite | Level 12

Hi,

 

Apologies, I didn't intend to imply that the SAS web authentication steps would not necessarily work, just that things are more complex in adding an extra 3rd party layer in front of the SAS mid-tier. After re-reading the SAS resource I listed above (#1) I also realise I was incorrect in my statement about it being about "bypassing the SAS Web Server and connecting your Apache directly to the SAS Web Application Server". That was what I was trying to do, not what the documentation covers.Thanks @JuanS_OCS for prompting me to re-read it 🙂

 

My memory of this was a bit hazy. A year or so back, I tried putting an Apache reverse proxy in front of the SAS Web Server / SAS Web Application Server. I got it mostly working but gave up (and switched to VPN access) after not being able to get to the point of proxying SAS Environment Manager on a non-root path. My intention at the time was to try to use a single more easily updated (i.e. apt-get/yum) vanilla Apache instance to proxy multiple SAS environments using TLS client certificates as the first authorization layer. I might have another go when I get some time.

 

Because web authentication can be done many different ways and can involve a combination of 3rd party products, Apache modules (in the SAS Web Server and/or your other Apache server) and custom configuration of the SAS Logon Manager (running in the SAS Web Application Server), it can be tricky to ensure all the bits are working together correctly. Looking for errors and/or warnings in the Apache and the SAS Web Server error log files, the SAS Web Application Server log files, together with inspection of the requests/responses using browser/server tools will greatly help in troubleshooting where things might be breaking down.

 

At a high level the 3rd party web authentication tech needs to pass on the identity of the already authenticated user to the SAS Logon Manager so that it can do a trust-based authentication of that user in the SAS platform. There are a few documented in the SAS 9.4 Intelligence Platform: Middle-Tier Administration Guide (e.g. IWA, WebSEAL, SiteMinder). A simple example is using a standard Apache module in the SAS Web Server which sets REMOTE_USER. This can be rewritten into the X-Remote-User HTTP header to be picked up by the SAS Logon Manager running in the SAS Web Application Server - as described in SAS Web Server Authentication

 

How are you currently trying to get the (Oracle) authenticated identity through to the SAS mid-tier? Through a HTTP header or some other mechanism? Have you tried using (or rewriting into) the X-Remote-User HTTP header and using the PrincipalFromRequestHeadersValve?

 

Cheers
Paul

123456789123456
Fluorite | Level 6

Thanks @PaulHomes for your reply,

 

Our configuration looks something like,

 

there is a reverse proxy in front of middle tier, and then the SAS web server + SAS web app servers all in the middle tier machine,

 

While there is no documentation available from SAS about using Oracle IAM/ Webgate like there is for CA site minder, IBM Web seal etc. on a high level a oracle webgate module has to be installed on the web server in the SAS VA install, which intercepts the user login request and then redirects the page to a oracle webgate login page where the user is authenticated with LDAP, and then the user credetnails get passed to the SAS web app server in the HTTP header,

 

The SAS Web Server authentication steps in the SAS Guide lay out the generic logic of passing the authenticated user credentials in the HTTP header from the SAS Web server to the SAS logon manager in the SAS Server1_1, like you said,

 

The complexity or confusion that is arising for us is the presence of the reverse proxy, and the question where should the 3rd party auth. plug-in (Oracle Identity Access Manager webgate plug-in) be installed, at the reverse proxy web server or the SAS web server ?,

 

Asked SAS TS this question but they were vague in their response, 

 

PaulHomes
Rhodochrosite | Level 12

If you have a module that can be installed in the SAS Web Server (i.e. Apache 2.2) then that is a possibility. You would need to make sure you verify/carry that customization across during SAS maintenance and version upgrades.  

 

However, if you, or others in your organization, already have setup the module in the proxy server, or have experience in doing so for other proxied products, then I would probably start with that option. Make sure you see the user id header being passed from the proxy to the SAS Web Server and then start the documented customization to the SAS mid-tier to pick up and use the value from that header. 

JuanS_OCS
Amethyst | Level 16

Hello @123456789123456,

 

in addition to what @PaulHomes advised and commented, I would say that your best choice is to contact the technical support of your 3rd Party (Oracle) single sign-on software. At this moment you know how a reverse proxy configuration work within SAS, plenty explained here (if not, please let us know), ant that configuration is what is supported within SAS. Now it is lef the question of SSO.

 

SAS Technical Support will answer what is documented. Oracle is not documented, as far as I know. But other similar solutions are, and if you read them, you will find a certain pattern on the configuration (Web Authentication, then the specific 3rd party requirements on config).

 

They will need to know the deployment (components, configuration changes, communications) would work and that is what you would need to explain and they will be able to explain if they can support you with the integration, or not.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 12 replies
  • 12920 views
  • 9 likes
  • 5 in conversation