Closed xenophonf closed 7 years ago
Sorry, I forgot to specify the versions of everything:
CentOS 7 PHP 5.6 (installed via the rh-php56 SCL) SimpleSAMLphp 1.14.11 (installed using the tarball) simplesamlphp-module-attributeaggregator 1.0.3 (installed using composer)
The attributeaggregator modul create the request but the binding and message sending and receiving functions are in the SAML2 library.
A suggest you to take a look inside the SAML2/SOAPClient code to further debugging:
https://github.com/simplesamlphp/saml2/blob/master/src/SAML2/SOAPClient.php#L16
After updating to SimpleSAMLphp 1.14.11, I started seeing the following error:
PHP Fatal error: Class 'SoapClient' not found in .../simplesamlphp/saml2/src/SAML2/SOAPClient.php on line 102
I resolved this by installing rh-php56-php-soap (i.e., the PHP SOAP extension).
Should composer handle this dependency? The SimpleSAMLphp documentation doesn't mention a dependency on the PHP SOAP extension, and I expected composer to do the right thing. If composer can't handle the installation of the PHP SOAP extension, then it should be mentioned in the installation instructions for this module.
Actually it is the SimpleSAMLphp SAML library that is the right place for declaring this dependency.
Anyway, the easiest non-solution is to mention this in the README of this module.
Let me try to get the SimpleSAMLphp people to document the PHP SOAP extension dependency. That could end up helping more than just the users of this module.
I want to set up SimpleSAMLphp as a proxy for our virtual organization (VO), with VO-specific attributes handled by a combination of COmanage Registry (the collaboration management platform), OpenLDAP (the attribute store), and Shibboleth IdP (SAML2 attribute authority). SimpleSAMLphp is federated with InCommon as an SP. Ultimately, we want SimpleSAMLphp to not only handle federated logons on behalf of our SPs but to also handle attribute resolution for the VO. When an enrolled user logs into a web app, we want SimpleSAMLphp to pass along both the attributes provided by their home IdP plus the attributes managed by our VO. To do this I have installed version 1.0.3 of the niif/simplesamlphp-module-attributeaggregator module. Without the attribute aggregator module, proxied logons work just fine.
Here's where I'm stuck: the attribute aggregator module never seems to actually call our SAML2 attribute authority. As a result any authentication flow stops at that point. I've confirmed this by both checking the web server access logs on the attribute authority and by running a packet capture. The server running SimpleSAMLphp never even opens a TCP connection to the attribute authority, let alone issues the requisite SOAP request. I have even disabled SELinux.
I'm not sure how to go about debugging this, being new to SimpleSAMLphp and somewhat unfamiliar with modern PHP web app development. I've posted what I think are the relevant log entries from simplesamlphp.log in the following gist, as well as a copy of config.php and the attribute authority's XML metadata:
https://gist.github.com/xenophonf/f165829f8b1eb2a23abe9b1e2a40f94b
I would be grateful for any help you all could give me.