Successful IDPv2 to v3 Migration

[McKean, Brandon Scott - mckeanbs]

What is conflicting with that? If you set up and expose to the outside
world (via SAML metadata) an attribute authority on port 8443 you'll
also configure the container with the SAML trust fabric to listen
there (and nothing else).
If you reroute (on the kernel level) external traffic to some other
port, what process is listening on port 8443 then?

In this case it was the original jetty process using 8443 for the main https page. I had 443 redirected to 8443.

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.

I also had to make a new pkcs12 keystore for the original idp.crt
and idp.key files we had so that it would match what the metadata
published.

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:


jetty.backchannel.keystore=/opt/shibboleth-idp/credentials/idp-backchannel.p12
jetty.backchannel.keystore.type=PKCS12
jetty.backchannel.keystore.password=passwordgoeshere


Same here: You did not try to re-use the existing attribute filter
polcies? Or you tried and they didn't work?

In this case I largely started from scratch, we do have a phase in our overall project plan to get tightened down attribute release, but they were never setup particularly well for each SP. So for the initial setup I didn't focus much on that and started anew, but based it off the existing one. I wanted to avoid a legacy configuration. (Hence why one of our next steps is going to be to try to remove SAML1, if we can.)

On Mon, 2015-07-20 at 14:56 +0200, Peter Schober wrote:

* McKean, Brandon Scott - mckeanbs <mckeanbs at jmu.edu<mailto:mckeanbs at jmu.edu>> [2015-07-20 14:47]:


The main gotcha encountered during the actual cutover was needing to
support SOAP endpoints as is documented on the Jetty9 page. The
configuration didn't work for us out of the box because of port 8443
conflicting with what we had setup (as was hinted on the
SecurityAndNetworking page), so I changed it to use 8009 and made an
iptables rule redirect port 8443 to 8009.



What is conflicting with that? If you set up and expose to the outside
world (via SAML metadata) an attribute authority on port 8443 you'll
also configure the container with the SAML trust fabric to listen
there (and nothing else).
If you reroute (on the kernel level) external traffic to some other
port, what process is listening on port 8443 then?



I also had to make a new pkcs12 keystore for the original idp.crt
and idp.key files we had so that it would match what the metadata
published.



Does that mean you did a fresh install on a new box?



In any case, with all that done, it was just a matter of getting
attribute-filter right with various SPs.



Same here: You did not try to re-use the existing attribute filter
polcies? Or you tried and they didn't work?
-peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150720/cad60952/attachment-0001.html>