Please explain. The main application *is* being served to the outside world, through a corporate web server.
My understanding of the way the isapi-redirect filter and extension works is:
Customer computer over the internet to corporate IIS server: "send me, over HTTPS, the resource at /MyApp/mypage"
Corporate IIS to customer: "Who are you?"
... further authentication
exchange...
Customer computer to corporate IIS server: "Here are my valid credentials, now send me, over HTTPS, the resource at /MyApp/mypage"
Corporate IIS server through the intranet (tunnelled if necessary across the country) to internal tomcat server: "send me, over AJP1.3, the resource at /MyApp/mypage"
Internal tomcat server to corporate IIS server: "Here it is."
Corporate IIS server to external customer: "Here it is."
Employee computer over the intrAnet to internal IIS server: "send me, over HTTPS, the resource at /MyApp/mypage"
Internal IIS server to employee computer: "Who are you?"
... further authentication exchange...
Employee computer to internal IIS server: "Here are my valid credentials, now send me, over HTTPS, the resource at /MyApp/mypage"
Internal IIS server to internal tomcat server on localhost: "send me, over AJP1.3, the resource at /MyApp/mypage"
Internal tomcat server to internal IIS server: "Here it is."
Internal IIS server to employee: "Here it is."
Administrator logged on using Remote Desktop browser to localhost Tomcat server: "send me, over HTTPS on this alternate port, the resource at /MyApp/mypage"
Tomcat to Administrator browser: "Who are you?"
Administrator browser to administrator user: "Who are you?"
Administrator user to Administrator browser: "Here are my username and password"
Administrator browser to Tomcat: "Here are the username and password"
Tomcat to Administrator browser: "Here it is."
We would ask IT to firewall the ports with direct access to Tomcat.
Outsiders not on the corporate notwork are already firewalled from HTTP or HTTPS access to the internal IIS server.
Make sense?
Rebeccah