Symantec Access Management

Tech Tip: fix for when Access Gateway returns redirect to HTTP: rather than HTTPS: 

08-10-2018 12:03 AM

Summary : 

Sometimes CA SSO Access Gateway (Ag) can return a 302 redirect to a HTTP (port 80) location, when a HTTPS (port 443) location was expected. 

In Access Gateway Apache mod_headers module can be used to fix the returned Location: header - as explained below.

 

Issue : 


We have a request from the client may be https (port 443) :

GET https://www.example.com/ 

 

But the response we get back from is a 302 redirect to the http (port 80) location eg : 

HTTP/1.1 302 Found
Location: http://www.example.com/mainsite/

Environment: 

Access Gateway R12.8. (in this article the Access Gateway is often referred to as Ag)
Windows 2016

 

Cause: 

This happens when there is some form of SSL offloading, and when the request gets to the Access Gateway (Ag) and/or the backend the request is in HTTP rather than HTTPS.  
In this case we have calling topology of : 
     client -> SSLOffloader -> Access Gateway- > backend

So by the time the request gets to to Access Gateway (Ag) or the backend, the Ag or backend believe the request is a HTTP request not a HTTPS request.   So If the Ag or backend generates a redirect the location it will specify will likely be a HTTP (port 80) reference rather than a HTTPS (port 443) reference.

For example :  with topology  of : 
     client --:443 -> SSLOffloader -- :80 -> Access Gateway -- :80 --> backend

The request from the client may be https (port 443) :

GET https://www.example.com/ 


But that gets passed to the Ag on port 80, the Ag may detect the "https" but when the Ag passes the request to the backend the backend does not know it is HTTPS request.  
So if the backend responses with a 302 redirect it will generally be a 320 redirect to the HTTP (port 80) location eg it returns : 

HTTP/1.1 302 Found
Location: http://www.example.com/mainsite/


That response is returend back to the client, and the client then tries to contact the site www.example.com on port 80, and gets a reject since the SSOffloader /F5 proxy is listening on server on HTTPS (port 443) and not on HTTP (port 80) - so the client gets an error response. 

 

Resolution: 

The solution for Access Gateway is to use the mod_headers apache module to fix the returned Location: and change any that refer to a http:// to a https:// .

1) That is achieved by the following : 

Edit the file  proxy-engine/httpd/conf/httpd.conf 
Add the following : 
    LoadModule headers_module modules/mod_headers.so
    Header edit Location "(^http://)" "https://"  
This will edit any returned 302 "Location" header and change any http:// to https:// before passing the response back to the client.
The above works for HTTP traffic arriving at the Ag, which is what is happening in our case since the SSL is offloaded, so the traffic arrives on port :80.  

 

2) However if your traffic arrives at the Ag on port :443 as SSL, 


Then you may need to make the same "Header edit" entry in the virtual host definition for the SSL listening port :
Edit the file : 
      proxy-server/httpd/extra/httpd-ssl.conf 

in the VirtualHost entry listenign on port :443) 
    Header edit Location "(^http://)" "https://"  

 

Depending on your circumstances. 
Then any returned 302 redirect that starts with http:// will be changed to be https://

 

Additional Information: 

The Apache mod_headers command is quite useful. 
Clearly here the "Header edit " command here is using a simple pattern match and the replace.  But more complex matching and substitution can also be performed.  
https://httpd.apache.org/docs/2.4/mod/mod_headers.html

 

 

raw kb link : 

https://comm.support.ca.com/kb/access-gateway-returns-redirect-to-http-rather-than-https/kb000110262 

 

 

Cheers - Mark

Statistics
0 Favorited
2 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

08-19-2018 05:30 PM

Thanks Mark.ODonohue for sharing this. This may also have a use case in integration when #siteminderandadvancedauthintegration is involved with CA IDM and CA Identity Portal.

Regards,

N

Related Entries and Links

No Related Resource entered.