I used the home-page function because it is specifically designed to handle requests for "/". I translated the path to /home, which is a bogus path and doesn't exist anywhere, either on the webserver or on the proxy.
Then I defined a new object and had it map the request the way that I want:
As long as there is never a /home in the app then it looks like it should work. What I was suggesting was to have two separate client tag statements with the same NameTrans redirect in each. The difference between them would be that one would check for security="on" and the other would check for uri="/". The idea being that all non secure requests get redirected to the login page as well as secure requests only for the top-level url /. You mentioned that you had tried a NameTrans for "/" which affected all requests. That is what I would expect since the map functionality looks for the from="/" value to be the prefix of the requested item and everything starts with /. I can see that is why you mentioned wanting a regex so that you could limit the meaning of / to be the actual item requested rather than a prefix. That is basically what the <Client uri="/"> does. The example I should have posted was:
Also I had said that the pages could have absolute urls for resources and that because you are manipulating dns name resolution this might minimize the visibility of this issue. I mention this because in an environment where the proxy is actually in front of many applications on many webservers all with different dns names the urls for resources becomes an issue. Are all the web pages using relative urls for thier resources?