Confused between authsources and saml20-sp-hosted

[Nicholas Amon]

Hi,

I've download SimpleSAMLPHP v 1.12 and I'm in the process of integrating it with our application.  My understanding of the documentation states that saml20-sp-hosted is deprecated and that we should be using authsources.php  instead.  I have tried doing so but it appears to me that the code is littered with references to saml20-sp-hosted.  For example in the AssertionConsumerService::70 is referencing saml20-sp-hosted as reproduced below:

try {

$metadataHandler = SimpleSAML_Metadata_MetaDataStorageHandler::getMetadataHandler();

$sp = $metadataHandler->getMetaDataCurrentEntityID();

$spMetadata = $metadataHandler->getMetaDataConfig($sp, 'saml20-sp-hosted');

$b = SAML2_Binding::getCurrentBinding();

if ($b instanceof SAML2_HTTPArtifact) {

$b->setSPMetadata($spMetadata);

}

$response = $b->receive();

if (!($response instanceof SAML2_Response)) {

throw new SimpleSAML_Error_BadRequest('Invalid message received to AssertionConsumerService endpoint.');

}

When I'm testing the integration, I'm getting an exception that the metadata for the SP cannot be found.  I've encountered this in a few places and have been forced to modify the code to do the following:

$spmeta = SimpleSAML_Configuration::getConfig('authsources.php');

$spmeta = new SimpleSAML_Configuration($spmeta->getArray('xsuite-default-sp'), 'authsources.php');

What am I doing wrong or misunderstanding?

Thanks,

Nicholas

[Nicholas Amon]

I should mention that I am using SimpleSAMLPHP as an IdP.

[Nicholas Amon]

I encountered the issue in another location.  I ended up hopefully resolving it once and for all by creating the file in the metadata directory and simply importing the authsources.php configuration into the file via an include_once.

[Peter Schober]

* Nicholas Amon <nichol...@gmail.com> [2014-06-06 22:15]:

> I should mention that I am using SimpleSAMLPHP as an IdP.

Then obviously (?) saml20-sp-hosted is irrelevant.
"Hosted" is meant to signify "local", "this system".

saml20-idp-hosted.php is for the ("local") IDP on the IDP machine,
saml20-sp-remote.php for SPs you intend to federate with (on the IDP
machine).
Here's the documentation for the IDP:
https://simplesamlphp.org/docs/stable/simplesamlphp-idp

* Nicholas Amon <nichol...@gmail.com> [2014-06-06 21:52]:

> I've download SimpleSAMLPHP v 1.12 and I'm in the process of
> integrating it with our application.

Then you have two different SimpleSAMLphp instances to configure,
according to two different sets of documentation.
The above applied to your statement of being the IDP.
Here's the documentation for the SP:
https://simplesamlphp.org/docs/stable/simplesamlphp-sp

-peter

[Nicholas Amon]

Sorry, long day. I  am using it as an SP. 

--
You received this message because you are subscribed to a topic in the Google Groups "simpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/V73Zls2qEyw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

[Peter Schober]

* Nicholas Amon <nichol...@gmail.com> [2014-06-07 00:02]:

> Sorry, long day. I am using it as an SP.

I never had to touch saml20-sp-hosted.php and had SPs running without
that file, so whatever you think is the problem is, it must be
independent from that.
-peter

[Jaime Pérez Crespo]

Hi,

On 06 Jun 2014, at 22:21 pm, Nicholas Amon <nichol...@gmail.com> wrote:
> I encountered the issue in another location. I ended up hopefully resolving it once and for all by creating the file in the metadata directory and simply importing the authsources.php configuration into the file via an include_once.

What was exactly the issue? What did you do exactly to solve it?

My impression by reading your initial email is that you are quite confused and doing something wrong with SSP. saml20-sp-hosted is indeed deprecated, and you don’t need that file at all to make SSP work. The reason why there are references to that file in the code is that support for that file is deprecated, not removed. You should be following this documentation:

https://simplesamlphp.org/docs/stable/simplesamlphp-sp

If you did, and something is not working, then you should post the exact error (i.e.: stack trace) that you are getting. Have you tested your installation through the web interface? There you can see your auth sources configured and test them. If they work, but integration with your application is not working, then probably you are doing something wrong in your code. You should be doing something as simple as this:

https://simplesamlphp.org/docs/stable/simplesamlphp-sp#section_6

Regards,

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Nicholas Amon]

Hi,

Crap you are correct!!! I'm feeling very frustrated and annoyed with myself at the moment.  When installing simplesamlphp, part of the instructions were to include the www directory in the webroot.  While doing so I noticed the initSSO.php, metadata.php, and AssertionConsumerService.php classes in the saml2 and shib13 directories and integrated using those set of files as my starting point.  After reading your responses, I just noticed that there is similar functionality in the modules/saml directory which what I should have been using.  

I was in the phase of creating the config UI and test SSO buttons on our product page and actually hadn't reached the step of actually kicking off the SSO when a user tries to access a protected resource and therefore hadn't thought much of the integration step in the documentation.  Totally my fault.  I will now switch over to using the proper set of classes.  

Btw, what is the difference between the two set of files, I assume one set is deprecated but I'm curious why (everything seems to work w/ it except what I mentioned earlier in my posts)?

Nice code btw!!

Thanks

[Nicholas Amon]

I guess I found my answer here:  https://simplesamlphp.org/docs/1.6/simplesamlphp-sp-migration.  The sad thing is that I actually read the documentation!!! :(

[Nicholas Amon]

I'm also trying to harden the integration.  Using the new method, i.e. modules.php, would I be able to remove all the remaining files in the www directory except that file?  I don't want to use any of the UI features of simplesampl, just the metadata generation and the SSO features.

Thanks

[Jaime Pérez Crespo]

Hi,

On 09 Jun 2014, at 21:54 pm, Nicholas Amon <nichol...@gmail.com> wrote:
> Crap you are correct!!! I'm feeling very frustrated and annoyed with myself at the moment. When installing simplesamlphp, part of the instructions were to include the www directory in the webroot. While doing so I noticed the initSSO.php, metadata.php, and AssertionConsumerService.php classes in the saml2 and shib13 directories and integrated using those set of files as my starting point. After reading your responses, I just noticed that there is similar functionality in the modules/saml directory which what I should have been using.

No prob, that kind of things just happen :-)

You don’t have to use either the files in www/ or the modules. Both are intended for SimpleSAMLphp to accomplish specific things, but in your case you have to use the public API as stated in the documentation, which means basically using the SimpleSAML_Auth_Simple class.

> I was in the phase of creating the config UI and test SSO buttons on our product page and actually hadn't reached the step of actually kicking off the SSO when a user tries to access a protected resource and therefore hadn't thought much of the integration step in the documentation. Totally my fault. I will now switch over to using the proper set of classes.
>
> Btw, what is the difference between the two set of files, I assume one set is deprecated but I'm curious why (everything seems to work w/ it except what I mentioned earlier in my posts)?

Well, no easy answer to that. Some of the files in www/ are indeed deprecated, but not all of them. In general, files in www/ are part of the old interface/implementation, while those in the modules directory are new. Some files are deprecated now because there’s a replacement in a module for them, but not all of them have a new implementation in a module. Those deprecated will most probably go in 2.0.

> I'm also trying to harden the integration. Using the new method, i.e. modules.php, would I be able to remove all the remaining files in the www directory except that file? I don't want to use any of the UI features of simplesampl, just the metadata generation and the SSO features.

No, as I said, some of the files are still required. What you can do indeed is to set an administrator password (‘auth.adminpassword’ in config/config.php) and protect with that password the main pages in the web UI (‘admin.protectindexpage’ in config/config.php). We expect the web interface to be more configurable and a bit more detached to the main functionality in 2.0, but there’s still a long road ahead until we reach that point.

> Nice code btw!!

Thanks! I’ll make sure to forward your compliments to the main “perpetrators” of the code :-)