test.php reachable but shibboleth authentication not enforced

[CorentinWicht]

RHEL9.3 · REDCap 13.7.24 · PHP 8.0.30 · MariaDB 10.5.22 · Apache 2.4.57

Dear Developper,

We are setting up a new REDCap server with shibboleth authentication and would like to benefit from your module for the e-signature functionality.

We have followed your instruction and the test.php page is reachable and displays shibboleth data in the $_SERVER session information (which are refreshed every 60 seconds).

Nevertheless, authentication is never enforced, even after each 60-seconds refresh.

Authenticating by going to https://redcapdev.unifr.ch/esig/Shibboleth.sso/Login works fine and then a valid session is returned when visiting https://redcapdev.unifr.ch/esig/Shibboleth.sso/Session.

Here is the content of our... 1) /etc/shibboleth/shibboleth2.xml file:

2) /etc/httpd/conf.d/esig.conf file:

Do you have any suggestion?

Best wishes,

C.

[123andy]

Hi @CorentinWicht - So you're saying it isn't the php code, but rather the shib definition that isn't working on your server. You can't seem to get https://foo/esig/ to use the timeout defined in the separate "esig" applicationId?

I'm afraid I'm not going to be much help here... If you install one of the SAML browser plugins, are you able to verify which applicationId you're logging into when you visit the /esig/ page? Maybe there is someone from your institution who is more of an authentication helper?

We have switched from Shib to OIDC connect and haven't re-implemented the esig yet. I'm thinking of making it a separate server all together (or even a cloud function in google) -- but that would require some mechanism for redcap and this external 'authentication' page to talk, but haven't gotten there yet.. Sorry.

[CorentinWicht]

Hi @CorentinWicht - So you're saying it isn't the php code, but rather the shib definition that isn't working on your server. You can't seem to get https://foo/esig/ to use the timeout defined in the separate "esig" applicationId?

I'm afraid I'm not going to be much help here... If you install one of the SAML browser plugins, are you able to verify which applicationId you're logging into when you visit the /esig/ page? Maybe there is someone from your institution who is more of an authentication helper?

We have switched from Shib to OIDC connect and haven't re-implemented the esig yet. I'm thinking of making it a separate server all together (or even a cloud function in google) -- but that would require some mechanism for redcap and this external 'authentication' page to talk, but haven't gotten there yet.. Sorry.

Dear @123andy many thanks for your reply. Indeed, our shibboleth installation was partially wrong and authentication was not enforced. Now it is the case when anyone tries to reach the /esig/test.php page as well as the /esig/index.php.

Regarding the SAML browser plugins, I am not able to see the applicationID but can confirm that authentication is enforced:

Nevertheless, the module seems not to work (at least in REDCap REDCap 14.0.6 LTS) because when I try to e-sign a form, e.g.:

I am still getting the default REDCap e-signature form (here my shibboleth credentials do not work):

From what I understand from your module, this default e-signature form should be bypassed by yours, is it correct? FYI, I have adequately provided the e-sig shibboleth endpoint:

I see that you last updated the module in 2022, could it be that there is an issue with the latest REDCap versions?

Best, C.