on 11-13-2008 3:50 PM
Hello,
we have an Apache http server, version 2.2, configured as reverse proxy in front of some SAP web dispatcher instances.
The reverse proxy should send the requests, which he gets actually for three different domains, to the proper web dispatcher instance.
We use the reverse proxy because all domains should be available an the standard https port 443 respectively on port 80 for http connections. I know we can solve this with different web dispatchers on different hosts, but because the domain names are all for the same SAP system in the background, we want to avoid this solution.
Another reason for the reverse proxy is to send requests depending on the path in the URL to different webdispatchers. But this is not active at the moment.
For example:
https://sconnect.example.com/sgui -> webdispatcher1 connect to the production system
https://sconnect.example.com/sguitest -> webdispatcher connect to the test system
The problem we actually working on, is, that we can choose if we want operate the SAP http GUI with a security problem or without the possibility to login.
If we connect direct to the web dispatcher with the fqdn (full qualified domain name) everything works fine. If we put this fqdn in the remote proxy configuration and connect via the reverse proxy, the user gets the login screen and can enter his username and password. When the user continue to login he don´t get the http GUI masks. What the user get´s is the login screen again as often as he tries to login.
If we put the hostname of the web dispatcher in the reverse proxy configuration instead of the fqdn, the user can login, but must enter his username and password in an pop-up (where he, depending on the browser, can save the username password combination) and get´s a error message (SSO ticket cookie problem, which can be solved with the fqdn). But we want neither the message or the pop-up.
Example of the reverse proxy configuration part:
with fqdn:
Because of the laziness of the users we see a security problem in the pop-up. The one person which should be able to login saves username and password and every trainee can access the sap system.
Has everyone of you have had the same or a similar problems and how did you solve them?
What have you done to solve requirements like the one I described above? What would be your solution if you have a system landscape like this?
Best Regards
Jan Hormann
Hi Jan,
I have quite a similar landscape :
An Apache 2.2 in a DMZ which has access to the internet and acts simultaneously as a forward proxy and a reverse proxy.
2 web dispatchers on the same host, one connected to a SAP XI system and the other one connected to a SAP SRM system.
The Apache reverse proxy directs the incoming http requests towards XI or SRM depending from the URLs.
In the Apache reverse proxy configuration file, I don't use fqdn for the web dispatcher host.
exemple for SRM web dispatcher
ProxyPreserveHost on
RequestHeader set ClientProtocol https
RequestHeader set x-sap-webdisp-ap HTTPS=443
RewriteRule ^/$ https://webdispSRM:443/sap/bc/gui/sap/its/bbpstart [P]
RewriteRule ^/sap/(.*) https://webdispSRM:443/sap/$1 [P,L]
RewriteRule ^/(sap\(.*) https://webdispSRM:443/$1 [P,L]
<Location />
SSLRequireSSL
Order allow,deny
Allow from all
ProxyPassReverse https://webdispSRM:443
</Location>
When connecting from the internet to https://ApacheHostAlias.domain.country/
users get the login page of the SRM system and don't have problems with the saplogon ticket.
So your problem seems strange to me.
Did you set parameter icm/host_name_full in the web dispatcher configuration file ?
Regards,
Olivier
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Oliver,
thank you for your answer. I´m sorry, but I was a little busy, which is the answer for the delay.
I started with testing immediately after you send your reply. I rebuild my webdispatcher environment with a test system and the hints you gave me. Everything worked fine.
After that I tried to transfer the test configuration which seems to have no effect. The difference I found was that there are more services activated in the test system.
Without doing anything else I was supprised when I noticed a few days later that everything worked fine. Maybe there is a connection with a reboot which was necessary because of maintenance works.
Again, thank you for your help.
Best Regards
Jan
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.