EZproxy Test Can't Use Shibboleth

[kevinreiss]

Shibboleth doesn't work on EZproxy test, we need to review the set-up and prod and replicate it on test. There is an entry in the campus IDP for the ezproxy-test.princeton.edu domain, but we may need to reach out to the IAM group to update something.

Shibboleth settings are the /var/local/ezproxy/shibuser.txt, /var/local/ezproxy/user.txt and in /var/local/ezproxy/config.txt files.

Try logging into shib at https://login.ezproxy-test.princeton.edu/admin to produce an error. See the *.xml files that currently get written to /var/local/ezproxy when shib login fails.

[VickieKarasic]

• We renewed the cert on ezproxy-test.princeton.edu since it had expired in April 2024.
• We also put in a ticket with OIT's IAM group to add a new service provider for Shibboleth - see CHG0105200
• We'll move forward on this once we hear back from OIT

[VickieKarasic]

I met with Jennifer Tuorto regarding INC0634311. OIT has updated the certificate on their end for all three iterations of our test site:

ezproxy-test.princeton.edu
http://ezproxy-test.princeton.edu
https://ezproxy-test.princeton.edu

SAML is failing at the return site on the SAML trace that Jennifer provided:

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"Destination="[http://ezproxy-test.princeton.edu/Shibboleth.sso/SAML2/POST"](http://ezproxy-test.princeton.edu/Shibboleth.sso/SAML2/POST%22)ID="_2b6026b29a211b48db888bf52e411956"InResponseTo="_17341066723"IssueInstant="2024-12-13T16:17:53.294Z"Version="2.0"                 ><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.princeton.edu/idp/shibboleth</saml2:Issuer><ds:Signature xmlns:ds="[http://www.w3.org/2000/09/xmldsig#"](http://www.w3.org/2000/09/xmldsig#%22)><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="[http://www.w3.org/2001/10/xml-exc-c14n#"](http://www.w3.org/2001/10/xml-exc-c14n#%22) /><ds:SignatureMethod Algorithm="[http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"](http://www.w3.org/2001/04/xmldsig-more#rsa-sha256%22) /><ds:Reference URI="#_2b6026b29a211b48db888bf52e411956"><ds:Transforms><ds:Transform Algorithm="[http://www.w3.org/2000/09/xmldsig#enveloped-signature"](http://www.w3.org/2000/09/xmldsig#enveloped-signature%22) /><ds:Transform Algorithm="[http://www.w3.org/2001/10/xml-exc-c14n#"](http://www.w3.org/2001/10/xml-exc-c14n#%22) /></ds:Transforms><ds:DigestMethod Algorithm="[http://www.w3.org/2001/04/xmlenc#sha256"](http://www.w3.org/2001/04/xmlenc#sha256%22) /><ds:DigestValue>H3wuI8qbbBnWJbJ9GJdEDuwINEmqggMgpUS+4gvACx4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>I1HgSYTkbFxwgNirdt+wHGZ7zBB5WBVOAb3MHbrXnxWx5aGia972TUashsF4nRKcvO4U7DqKpMYDrvgoAxfDE+0aeeWLtMN0ZgmQmOAoREvO4XJ70Hg55M89mrpq14wCVyv3xiGZJ/Wk54SxAkYa9BtwYbz8qbz3Irt3yS65yKkk54m3QXjHKyyadMFabXxQKvP1KAyGzjkSTU743ePqnrfsYgT2+BrX7xNfIWQE0o+zsvxB23IqaOSEyc0SxaMxcvjPTPuNlXp/oWeMpQCLYiNhY8slHtrVDCI36AQWURGnE3q8YyMlWWBBRV3ODRfkaD1FBs5x8kyiBZAV4GAqcQ==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIDLzCCAhegAwIBAgIUMfmaP7flCY4+d5Gnju4bntgM57wwDQYJKoZIhvcNAQEFBQAwHDEaMBgG A1UEAxMRaWRwLnByaW5jZXRvbi5lZHUwHhcNMDkxMDMwMTI1MTM5WhcNMjkxMDMwMTI1MTM5WjAc MRowGAYDVQQDExFpZHAucHJpbmNldG9uLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJE0moHwKJGyg9z94dvN0HCBklHGPvRdIB0nvzAJxo9KaF81zFaqHpvprwNEoB3Pfy18hIbt nDSv/sV/j6pnKnBwXXsf7QJOOF81klkGHZh4C9VnjUL5ok9Ahx1zPgaLcCgvZeGRG7DiRPnOgxVz uwoBWFnEWBCoLaqcZUl2njnawRB+LXt8mO+HPhsMO8c7ASJ50hF/l9cGaCs3ucEcwp9dFoxSiVy2 TMyatszHTHZknaqVyqR+WNCxE/Jpcwfi1oq6k3V5T372GE8WTKclgvpgIYV8ISROBHpVlYz9v3N0 nnpOn+Io6zuUOS3YNmuX52vaSciaYNoPcmBxYMEG2jcCAwEAAaNpMGcwRgYDVR0RBD8wPYIRaWRw LnByaW5jZXRvbi5lZHWGKGh0dHBzOi8vaWRwLnByaW5jZXRvbi5lZHUvaWRwL3NoaWJib2xldGgw HQYDVR0OBBYEFPQsLxgrW14zmCfogqfOscaIPOtoMA0GCSqGSIb3DQEBBQUAA4IBAQAqkhYwrjjw i31OYkDKjeKyss835BrdLVTqqEfssT3lvYW/SGyRMLCr2hS21p9zbt8dJO67C9RYEjJ/05p2Keo+ ZQj3ehOP80/phxk0r+Je/fNdpO/HbQG9/DfcYp5sLUXk9koYrXrOHq6KnkVhrmikDRb9izfU9nDt tB8hWGLiX0WhIvk9xkIAW5ueyL5QxcQmRYNcaT3BUpjkGiBuFEsLXa42F1nmdBDGrI2woHNEr2di ujL5EOxqIsunquUXuu2dFuNtqA0HRK6wj32bfsZT9KwTEdLv/oAbgQ8zlVXErx54GJFg1ksGAJY3 lsGY+XdvcUaKuVD2IWOrbCtPqZfT</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2p:Status><saml2p:StatusCode **Value="urn:oasis:names:tc:SAML:2.0:status:Responder" /><saml2p:StatusMessage>An error occurred.</saml2p:StatusMessage></saml2p:Status></saml2p:Response>**

From the bolded part at the bottom, she thinks there might be a user error in the access that she and I have and wants to look at it again with @kevinreiss in January to see if we can uncover anything, since it's set up differently than ezproxy-prod.

[VickieKarasic]

We plan to replace this VM, rerun the playbook, and see if we can get it to match production. Steps to do this:

• run the replace a VM in staging playbook in Tower on ezproxy-test
• follow steps for new VM and disk expansion
• run the ezproxy playbook
• set up shibboleth to match ezproxy-prod1

[VickieKarasic]

This PR #5726 rebuilds the EZProxy role. Next steps involve trying to set up Shibboleth using this documentation, and working with OIT to get the handshake to work.

[VickieKarasic]

Things we discovered today:

• In the Princeton IDP metadata, it's login.ezproxy-test.princeton.edu, whereas in ezproxy itself, it's ezproxy-test.princeton.edu, so it is getting stuck in this loop when trying to access the site
• Versions are different: prod is 7.2.12 and test is 7.3.8

[acozine]

When the EZProxy work is done, we need to go through the SSL certificates, figure out which ones are active, and revoke the ones that are not. I think we currently have three certs for each site (*.ezproxy.princeton.ed and *.ezproxy-test.princeton.edu).

[VickieKarasic]

Thanks @acozine. In chatting with @kevinreiss about next steps on this, we think that before we sort out SSO, we should figure out these certs - the 7.3 version guide (which test is on) said that we shouldn't be using the wildcard (though, for our resources, we don't know how that would work for things like https://www-sciencedirect-com.ezproxy.princeton.edu/)...

[VickieKarasic]

@kayiwa and I updated the cert for ezproxy-test.princeton.edu and revoked the one with the wildcard: *.ezproxy-test.princeton.edu. We've also updated the version of ezproxy-test to 7.2.12 to match the version on prod. This will let us proceed with comparing the two systems to see if we can get Shibboleth to work on test.

[sandbergja]

Differences we noticed so far between prod (working) and test (not working):

• In /var/local/ezproxy/messages.txt, prod says Proxy by hostname (good), while test says Proxy by port (bad)
• Prod is using a wildcard SSL cert, test is not. We changed test back to using a wildcard cert.

Fixed (sort of)

• sudo service ezproxy start does not work on test, so we have to start the binary directly. There was an extra line in the init.d script, which we removed. We still don't think it's working.

Next steps:

• make cert on prod match cert on test