External Windchill Access

[BenLoosli]

We are looking at setting up a company to allow external access to the Windchill system. One solution we are investigating is to use a firewall/DMZ for the external people and have them come into ProjectLink to get the data that internal people have placed there. We still want the internal people to login to PDMLink/ProjectLink like they do today directly to the servers.

Does anyone have some documentation that you are willing to share on how to setup the servers and configure them?

Thanks

[BenLoosli]

I got the external Apache server set up, but now we need to convert it to HTTPS connection.

We want to login to the external machine with HTTPS and have the reverse proxy communicate with the internal Windchill server.
The internal people want to continue using HTTP for access to Windchill.
I can get on the external machine but right now it connects to Windchill with HTTP when the Apache service is running.

Does anyone have some information on doing this or point me to some documentation?

[jessh]

There is no good, maintainable way to configure 1 instance of Windchill
to be accessed via HTTP by some and HTTPS by others. [There is /a/ way,
but it is horribly complicated and you don't want to go there.]

The instance will be accessed by the same URL (including the URL
protocol, HTTP or HTTPS) by everyone.

Having everyone access the system via HTTPS is a perfectly sane (and
much more secure) approach.

Anyone using HTTPS (for any access) will want to be sure that their
Apache configuration is using the latest configuration, though, i.e.:

#BrowserMatch ".*MSIE.*" \
# nokeepalive ssl-unclean-shutdown \
# downgrade-1.0 force-response-1.0
# Adjust the default BrowserMatch to be a little more granular
# in downgrading connection features [PTC]
# All MSIE versions need ssl-unclean-shutdown
BrowserMatch "MSIE" ssl-unclean-shutdown
# MSIE versions 2-5 need additional downgrades
BrowserMatch "MSIE [2-5]" nokeepalive downgrade-1.0 force-response-1.0

in conf/extra/httpd-ssl.conf rather than the Apache default of

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

This configuration change has been made out-of-the-box in recent PTC
Apache releases. Without it, all Internet Explorer users will not be
given keepalive connections when HTTPS is used. While Internet Explorer
had really bad bugs in this area in early versions (hence the special
treatment of versions 2 through 5) and still has some serious bugs in
this area (hence the remaining ssl-unclean-shutdown), the old
configuration killed HTTPS performance for all MSIE users (by requiring
an HTTPS handshake on every request).

--
Jess Holle

[TomU]

Can't a reverse proxy be used to convert external https requests to internal http requests (with no change to Windchill)?

Tom U.

[jessh]

Yes, you can use a reverse proxy to convert external HTTPS requests to
HTTP requests against a backend server with only minor adjustments to
the Windchill configuration.

No, this does not mean that internal requests can use HTTP -- they still
have to use HTTPS.

Each Windchill instance knows of itself as a single URL. So, while
internal traffic to a backend HTTP server would reach there, Windchill
would still generate URLs to the HTTPS URL in its responses, email
notification, etc.

Keep it simple. If you want HTTPS access, then all access should be via
the same HTTPS URL. You might use reverse proxies, etc, but that's an
entirely separate matter.

--
Jess Holle

[BenLoosli]

We are set up with a reverse proxy outside the DMZ, which is the external Apache server.
With Apache shutdown, this machine cannot connect to the internal Windchill with an HTTP request

[jessh]

If you don't external folk to connect directly to an internal HTTP(S)
server then you had best establish a firewall between them and it to
prevent that.

That said, there will be issues trying to support 1 instance of
Windchill using 2 different access URLs -- or 2 different protocols
which is the same thing really.

Thus everyone should access Windchill via the same HTTPS URL in your
scenario -- irrespective of how many reverse proxies you might have in
the picture.

--
Jess Holle

[TomU]

What do you do when the internal domain name used for Windchill is not valid outside the organization (on the public internet)? Can't the reverse proxy "rewrite" the URL from a valid external name to the (not-public) internal name?

[jessh]

Use the external domain name internally. If you need this to go through
a separate internal server than the external server, then it's time for
some DNS tricks internally -- but the URL (including protocol) should be
the same for all users.

A reverse proxy is great for request routing, switching protocols, etc.

Asking a reverse proxy to rewrite URLs in responses is a recipe for
issues, though. Worse, there are e-mail notifications, RMI responses,
etc, where no reverse proxy could possibly rewrite the URLs.

--
Jess Holle

[GaryMansell]

I agree with Jess - previously we looked at URL re-writing with a Reverse proxy and dual http/https config when exposing our system to the internet and gave it up as a bad job.

We ended up with a https configured windchill system for both internal and external users, ReHosted our Windchill System to an Internet resolvable Domain Name and then used "split brain DNS" to allow interal users to access the internal IP of the normal System's Apache server, whilst the external Internet users resolved the hostname to the Internet IP of our Remote Access (Security) box. Once the external users authenticate against this Security device, they then get access to a separate (hardened) remote (not reverse proxy) Apache Server located in a DMZ that authenticates against the Windchill Administrative LDAP which holds the remote users details rather than the corporate Windows AD LDAP which holds our internal users. We can then use this distinction between internal and external users for further security controls in our Windchill ProjectLink access control.

Rgds

Gary