Successful IDPv2 to v3 Migration

[Peter Schober]

* McKean, Brandon Scott - mckeanbs <mckeanbs at jmu.edu> [2015-07-20 15:05]:
> In this case it was the original jetty process using 8443 for the
> main https page. I had 443 redirected to 8443.

I see: If your web browser-facing port was 8443 /internally/ (mapped
to 443 externally) you'd need something else for the back-channel,
e.g. 8444 (and map that to whatever you want externally).

> Thus to work around that I had Jetty also use 8009 for the SOAP
> endpoint, then redirected 8443 to that. Routing wise it is a bit
> confusing I confess.

8009 often is used for the AJP connector on Tomcat, that's one
possible confusion. The other is that your internal 8443 listener
doesn't match what's available on 8443 externally but that's just
visible/confusing for you and your colleagues, of course.
Note there is no requirement to use port 8443 specifically on the back
channel (the port is listed explicitly in SAML metadata, so no need
for a convention), though some SPs might have packet filters in place
blocking other ports outgoing...
(For completeness: There's no requirement to use TCP/443 for the
browser-facing portion either, of course, though since that affects
many more clients and possible networks I wouldn't consider changing
that.)

> Not entirely, the idp.crt and idp.key I had before from the v2
> installation. By that I meant I just had to make them into a pkcs12
> keystore so that Jetty could be configured properly, specifically
> for these lines:

OK, the v2 IDP did not come with a PKCS#12 format key store (but a JKS
plus separate Base64-encoded DER certs and private key) so if you want
to use PKCS#12 you'd have to convert that yourself (since that
involves assigning a passphrase).
-peter