SimpleSAML_Error_Exception: Error validating SubjectConfirmation in Assertion (URL)

[joshc...@gmail.com]

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION

Backtrace:

0 /home/content/31/9055421/html/Apps/ResourceSpace/plugins/simplesaml/lib/www/module.php:180 (N/A)

Caused by: SimpleSAML_Error_Exception: Error validating SubjectConfirmation in Assertion: Recipient in SubjectConfirmationData does not match the current URL. Recipient is 'http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp', current URL is 'http://resources.mydomain.org/Apps/ResourceSpace/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp'.

Backtrace:

3 /home/content/31/9055421/html/Apps/ResourceSpace/plugins/simplesaml/lib/modules/saml/lib/Message.php:694 (sspmod_saml_Message::processAssertion)

2 /home/content/31/9055421/html/Apps/ResourceSpace/plugins/simplesaml/lib/modules/saml/lib/Message.php:528 (sspmod_saml_Message::processResponse)

1 /home/content/31/9055421/html/Apps/ResourceSpace/plugins/simplesaml/lib/modules/saml/www/sp/saml2-acs.php:81 (require)

0 /home/content/31/9055421/html/Apps/ResourceSpace/plugins/simplesaml/lib/www/module.php:135 (N/A)

 Why is the "current URL" pointing back to my sub-domain (resources.mydomain.org), and then attaching on the /Apps/ResourceSpace? The Recipient URL is correct, while the "current URL" is not because the resources sub-domain already points to the /Apps/ResourceSpace directory. 

Any ideas on how to fix this?

Thank you.

[joshc...@gmail.com]

My default-sp...

<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://auth.myidpdomainhere.org">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-logout.php/default-sp"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp" index="0"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml1-acs.php/default-sp" index="1"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp" index="2"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml1-acs.php/default-sp/artifact" index="3"/>
  </md:SPSSODescriptor>
  <md:ContactPerson contactType="technical">
    <md:GivenName>ResourceSpace</md:GivenName>
    <md:SurName>Administrator</md:SurName>
    <md:EmailAddress>ad...@mydomain.com</md:EmailAddress>
  </md:ContactPerson>
</md:EntityDescriptor>

My Config (URLs)...

'baseurlpath'           => 'http://resources.mydomain.org/plugins/simplesaml/lib/www/',

'certdir'               => 'http://resources.mydomain.org/plugins/simplesaml/lib/cert/',

'loggingdir'            => 'http://resources.mydomain.org/plugins/simplesaml/lib/log/',

'datadir'               => 'http://resources.mydomain.org/plugins/simplesaml/lib/data/',

My Auth Sources...

// An authentication source which can authenticate against both SAML 2.0

// and Shibboleth 1.3 IdPs.

'default-sp' => array(

'saml:SP',

// The entity ID of this SP.

// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.

'entityID' => 'http://resources.mydomain.org',

// The entity ID of the IdP this should SP should contact.

// Can be NULL/unset, in which case the user will be shown a list of available IdPs.

'idp' => 'http://auth.myidpdomainhere.org',

// The URL to the discovery service.

// Can be NULL/unset, in which case a builtin discovery service will be used.

'discoURL' => NULL,

),

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-02-27 14:58]:
> *My Config (URLs)...*

> 'baseurlpath' =>
> 'http://resources.mydomain.org/plugins/simplesaml/lib/www/',
> 'certdir' =>
> 'http://resources.mydomain.org/plugins/simplesaml/lib/cert/',
> 'loggingdir' =>
> 'http://resources.mydomain.org/plugins/simplesaml/lib/log/',
> 'datadir' =>
> 'http://resources.mydomain.org/plugins/simplesaml/lib/data/',

Only baseurlpath can resemble a URI (but it can be a relative path,
too), all the other parameters above should reference local file
system paths (directories, as in ".*dir"), and of course none of the
referenced directories should be available via the webserver.
In fact the documentation clearly states that only SSP's www directory
should be exposed to the webserver.
-peter

[joshc...@gmail.com]

Thank you for that clarification. I have fixed it so that all of them are just using file system paths (Apps/ResourceSpace/plugins/simplesaml/lib/www and so forth). Also, cert/log/data directories are not accessible. 

Although, I do not believe that this fixes my issue. For some reason I am still getting the same error, as it is saying that my "current URL" is 'http://resources.mydomain.org/Apps/ResourceSpace/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp'.    

The Recipient URL is correct though: 'http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp'    

Either I need to make my "current URL" not add /Apps/ResourceSpace/ to the end of it, or I need to make my current URL not use my subdomain (resources), and just make it use http://mydomain.org/plugins/simplesaml/etc etc.

Any ideas on how to accomplish this?

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-02-27 17:00]:

> Thank you for that clarification. I have fixed it so that all of them are
> just using file system paths (Apps/ResourceSpace/plugins/simplesaml/lib/www
> and so forth). Also, cert/log/data directories are not accessible.

What I meant was to follow the documentation (that's never a bad idea)
and possibly also restructure your application so that
http://resources.mydomain.org/plugins/simplesaml/lib/www/
is neither necessary not possible, but to make it that
http://resources.mydomain.org/plugins/simplesaml/
points to SimpleSAMLphp's "www" directory.

> Although, I do not believe that this fixes my issue.

I didn't think it would, but before fixing such elemantary issues I
wouldn't concern myself with other details.

As to your continuing issue: How are you initiating SSO in order to
get the response sent to the (percieved) incorrect location?

I'd *first* fix the file system arrangement or web server
configuration (as described above, and covered in the installation
documentation), and only *then* try to initiate SSO directy from SSP's
admin web UI (test configured authentication sources).
Only once that works without errors would I look into application
integration.
-peter

[Jaime Perez Crespo]

Hi,

On 27 Feb 2017, at 16:51 PM, joshc...@gmail.com wrote:
> Thank you for that clarification. I have fixed it so that all of them are just using file system paths (Apps/ResourceSpace/plugins/simplesaml/lib/www and so forth). Also, cert/log/data directories are not accessible.
>
> Although, I do not believe that this fixes my issue. For some reason I am still getting the same error, as it is saying that my "current URL" is 'http://resources.mydomain.org/Apps/ResourceSpace/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp'.
>
> The Recipient URL is correct though: 'http://resources.mydomain.org/plugins/simplesaml/lib/www/module.php/saml/sp/saml2-acs.php/default-sp'
>
> Either I need to make my "current URL" not add /Apps/ResourceSpace/ to the end of it, or I need to make my current URL not use my subdomain (resources), and just make it use http://mydomain.org/plugins/simplesaml/etc etc.

If you want “http://mydomain.org/plugins/simplesaml/“ to be the URL in use, you need to configure that in ‘baseurlpath’, because right now with the configuration you have you are literally telling SimpleSAMLphp: “the base URL you need to use is http://resources.mydomain.org/plugins/simplesaml/lib/www”.

Your metadata reflects that configuration, and that’s why your endpoints use the “resources.mydomain.org” domain. And if the endpoints in your metadata point there, that’s where the IdP will send its response, always.

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

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

[joshc...@gmail.com]

Peter,

Just to be clear, do you suggest making a complete move of 'www' into my simplesaml folder? or would I be better off to simply make a symbolic link from /plugins/simplesaml --> /plugins/simplesaml/www? 

Thanks.

[joshc...@gmail.com]

Jaime,

Thanks for that info. My SimpleSAML installation is currently within www.mydomain.org/Apps/ResourceSpace/plugins/simplesaml. I am using SimpleSAML 2.0 with the ResourceSpace application. But I have my clients use the subdomain of www.resources.mydomain.org to access ResourceSpace, which directs them straight to mydomain.org/Apps/ResourceSpace. So I assumed that I should be using http://resources.mydomain.org/plugins/simplesaml/lib/www for my basepath URL because that technically points to my SimpleSAML installation/web panel folder within my webserver. But for some reason when trying to utilize the SSO, it is attaching on the /Apps/ResourceSpace/ to the end of my subdomain URL... so it uses the URL of http://resources.mydomain.org/Apps/ResourceSpace/plugins/simplesaml/lib/www which isn't correct (http://resources.mydomain.org/plugins/simplesaml/lib/www is correct). I guess a possible work-around would be to not use a subdomain within my baseurlpath, and regenerate my SP-Metadata not using the subdomain and send that over to my IdP?

[Peter Schober]

Why not stop doing all of that ("If it hurts ...") and simplifiy,
simplifiy, simplifiy? Canonicalize your application and resources and
vhosts etc as much as possible, make SSP's www directory available to
the webserver as /simplesaml (or whatever) and be done with it?
Why have SSP mapped to /Apps/ResourceSpace/plugins/simplesaml? Is that
a requirement from ResourceSpace? (Does ResourceSpace embed a version
of SSP?) Any why would you ever expose paths like /simplesaml/lib/www
on the web? These are meaningless and potentially insecure.
-peter

* joshc...@gmail.com <joshc...@gmail.com> [2017-02-27 22:38]:

> Thanks for that info. My SimpleSAML installation is currently within
> www.mydomain.org/Apps/ResourceSpace/plugins/simplesaml. I am using
> SimpleSAML 2.0 with the ResourceSpace application. But I have my clients
> use the subdomain of www.resources.mydomain.org to access ResourceSpace,
> which directs them straight to mydomain.org/Apps/ResourceSpace. So I
> assumed that I should be using
> http://resources.mydomain.org/plugins/simplesaml/lib/www for my basepath
> URL because that technically points to my SimpleSAML installation/web panel
> folder within my webserver. But for some reason when trying to utilize the
> SSO, it is attaching on the /Apps/ResourceSpace/ to the end of my subdomain
> URL... so it uses the URL of
> http://resources.mydomain.org/Apps/ResourceSpace/plugins/simplesaml/lib/www

> <http://resources.mydomain.org/plugins/simplesaml/lib/www> which isn't

> > jaime...@uninett.no <javascript:>
> > jaime...@protonmail.com <javascript:>

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-02-27 22:27]:

> Just to be clear, do you suggest making a complete move of 'www' into my
> simplesaml folder?

I don't know what that means. The www directory from a SimpleSAMLphp
software release *is* within the unpacked SimpleSAMLphp release. So
what is a/your "simplesaml folder"?

> or would I be better off to simply make a symbolic link from
> /plugins/simplesaml --> /plugins/simplesaml/www?

https://simplesamlphp.org/docs/stable/simplesamlphp-install#section_6
-peter

[Jaime Perez Crespo]

Hi,

On 27 Feb 2017, at 22:38 PM, joshc...@gmail.com wrote:
> Jaime,
>
> Thanks for that info. My SimpleSAML installation is currently within www.mydomain.org/Apps/ResourceSpace/plugins/simplesaml.

What does that mean exactly? How do you access it from resources.mydomain.org, then? Do you have any kind of URL rewriting?

> I am using SimpleSAML 2.0

I don’t think so. The latest stable version of SimpleSAMLphp is 1.14.11.

> with the ResourceSpace application.

I don’t know that application, and probably others here don’t either. Focus on SimpleSAMLphp, because that’s what we can help you with.

> But I have my clients use the subdomain of www.resources.mydomain.org to access ResourceSpace, which directs them straight to mydomain.org/Apps/ResourceSpace.

What does it mean “directs them straight to mydomain.org/Apps/ResourceSpace? Is it an HTTP redirect? Is it a URL rewrite?

> So I assumed that I should be using http://resources.mydomain.org/plugins/simplesaml/lib/www for my basepath URL because that technically points to my SimpleSAML installation/web panel folder within my webserver.

That’s ok. But then you MUST ensure you access it that way. Also, if you are creating your SimpleSAMLphp sessions in one domain (mydomain.org), you won’t be able to access them from another domain (resources.mydomain.org) unless you have a common higher level domain (mydomain.org) and you configure your cookies to be sent to all subdomains, which is in general not recommended (imagine you have an evil.mydomain.org subdomain that’s not under your control… they would also receive the session identifying the user).

> But for some reason when trying to utilize the SSO, it is attaching on the /Apps/ResourceSpace/ to the end of my subdomain URL…

That’s not the end of your URL, that’s the beginning of your query path. If SimpleSAMLphp expects such a URL, that’s because that’s the URL it sees for itself. SSP will not make things up like that, it will just reflect its own environment.

> so it uses the URL of http://resources.mydomain.org/Apps/ResourceSpace/plugins/simplesaml/lib/www which isn't correct (http://resources.mydomain.org/plugins/simplesaml/lib/www is correct). I guess a possible work-around would be to not use a subdomain within my baseurlpath, and regenerate my SP-Metadata not using the subdomain and send that over to my IdP?

That would probably work.

In any case, as Peter said, keep it simple. SSO is complicated, so the more complexity you add to it for free, the more trouble you will have to debug later...

[joshc...@gmail.com]

Okay, I think I understand what you are talking about now. Step #6 within the installation instructions of simplesamlphp is the Apache / Virtual Hosts configuration. I never did this step as ResourceSpace's instructions did not include this. Does this step have to explicitly be done? Because my site is hosted at GoDaddy on shared hosting, and I do not have access to the Apache configuration / httpd.conf. Is there any other way to do this? Can it be done with .htaccess files?

Thanks.

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-02-28 20:36]:

> Okay, I think I understand what you are talking about now. Step #6
> within the installation instructions of simplesamlphp is the Apache
> / Virtual Hosts configuration. I never did this step as
> ResourceSpace's instructions did not include this.

This project publishes documentation for installation and
configuration of the software it produced. That you decided to follow
someone else's (seemingly) incomplete 3rd-party documentation is a
problem, as evidenced by the issues you're having. But by defintion
nothing this project/community can fix.

> Does this step have to explicitly be done? Because my site is hosted
> at GoDaddy on shared hosting, and I do not have access to the Apache
> configuration / httpd.conf. Is there any other way to do this?

Qoting from that section of the SSP documentation:

"There are several ways of exposing SimpleSAMLphp depending on the way
web sites are structured on your Apache web server. The following is
just one possible configuration."

So, yes. there are other ways.

> Can it be done with .htaccess files?

Not a question for SimpleSAMLphp, but for Apache httpd:
https://httpd.apache.org/docs/2.4/en/mod/mod_alias.html#alias
So, no, you can't have Alias directives in .htaccess files.

Personally when I'm on shared hosting I symlink the unpacked SSP
distribution's www directory (that's kept elsewhere in the file
system, so is /not/ exposed to the webserver, at all) into the sharing
hosting's web root (or wherever you want it to be available), e.g.:

$ cd ~/public_html/ # or whatever that may be
$ ln -s ../simplesamlphp-x.y.zz/www saml

And set baseurlpath to '/saml' (or 'https://example.org/saml' if I
need to be more specific). That way SimpleSAML becomes available at
the relative URL /saml on my vhost.
-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2017-02-28 20:59]:

> And set baseurlpath to '/saml' (or 'https://example.org/saml'

For completeness (though that was not the point I wanted to
illustrate): Make those examples '/saml/' or
'https://example.org/saml/' as baseutlpath must end with a path, as
indicated in config.php itself.
-peter

[joshc...@gmail.com]

Peter,

So I have it setup now so that http://mydomain.org/saml/ works perfectly, but I am having 1 more issue that I would be greatly appreciative if you could assist me in implementing a fix.

Testing simpleSAMLphp default-sp authentication on the webpanel at mydomain.org/saml/module.php/core/authenticate.php works fine now. But my issue is that when I try to use SSO through ResourceSpace, I have an issue. The process is as follows: I go to ResourceSpace at http://resources.mydomain.org. I click 'Sign in with SSO' which then uses SimpleSAMLphp, connects to my IdP, authenticates fine, BUT when it redirects back to my end to complete the sign in to ResourceSpace it gives me an incorrect link of "http://mydomain.org/?usesso=true". My assumption is that I need it to redirect back and complete the sign in using http://resources.mydomain.org/?usesso=true. What do I need to change to make it go through and redirect back effectively to resources.mydomain.org/?usesso=true and not mydomain.org/?usesso=true ? 

Am I going to have to change everything (config, authsources, SP metadata) over from http://mydomain.org/saml/ to http://resources.mydomain.org/saml/?

Thank you for the help. Here is some info below...

My config...

        'baseurlpath'           => 'http://mydomain.org/saml/',

My authsources...

// An authentication source which can authenticate against both SAML 2.0

// and Shibboleth 1.3 IdPs.

'default-sp' => array(

'saml:SP',

// The entity ID of this SP.

// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.

'entityID' => 'http://mydomain.org',

// The entity ID of the IdP this should SP should contact.

// Can be NULL/unset, in which case the user will be shown a list of available IdPs.

'idp' => 'http://auth.myidpdomain.edu',

// The URL to the discovery service.

// Can be NULL/unset, in which case a builtin discovery service will be used.

'discoURL' => NULL,

),

My SP given to IdP...

<?xml version="1.0"?>

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://mydomain.org">

  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://mydomain.org/saml/module.php/saml/sp/saml2-logout.php/default-sp"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://mydomain.org/saml/module.php/saml/sp/saml2-acs.php/default-sp" index="0"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://mydomain.org/saml/module.php/saml/sp/saml1-acs.php/default-sp" index="1"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="http://mydomain.org/saml/module.php/saml/sp/saml2-acs.php/default-sp" index="2"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="http://mydomain.org/saml/module.php/saml/sp/saml1-acs.php/default-sp/artifact" index="3"/>

  </md:SPSSODescriptor>

  <md:ContactPerson contactType="technical">

    <md:GivenName>ResourceSpace</md:GivenName>

    <md:SurName>Administrator</md:SurName>

    <md:EmailAddress>ad...@mydomain.org</md:EmailAddress>

  </md:ContactPerson>

</md:EntityDescriptor>

[joshc...@gmail.com]

With my configuration all correct using the symlink as you requested, I also tried changing all of my configs to use my subdomain (resources.wsubsom.org), to try and fix my URL problem I mentioned above. I changed my baseurlpath, my entityID, regenerated my SP metadata, and had my IdP update my SP metadata and entityID on his end. So now, I am back to square one. I am getting the same error that I was getting in my very first post. My IdP says that the SSO authentication appears to be working perfectly fine on his end. So it's evident that the issue is when we are redirecting back to my end during the authentication process, SOMETHING (be it simpleSAML or ResourceSpace) is rewriting/changing my 'current URL' to something different and incorrect. My recipient URL is 100% correct. My current URL is not.

So either SimpleSAMLphp or ResourceSpace has a configuration/file somewhere which is rewriting the 'current URL' to something which isn't correct. My subdomain (resources.mydomain.org) already points to /Apps/ResourceSpace. There is no reason for it to attach on /Apps/ResourceSpace to the end of http://resources.mydomain.org within the current URL.

Does anyone know what would be causing this URL re-write which is giving me the incorrect current URL when returning back from the IdP?

Any help would be appreciated. My full error is below.

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION

Backtrace:

0 /home/content/42/9099541/html/Apps/ResourceSpace/plugins/simplesaml/lib/www/module.php:180 (N/A)

Caused by: SimpleSAML_Error_Exception: Error validating SubjectConfirmation in Assertion: Recipient in SubjectConfirmationData does not match the current URL. Recipient is'http://resources.mydomain.org/saml/module.php/saml/sp/saml2-acs.php/default-sp', current URL is 'http://resources.mydomain.org/Apps/ResourceSpace/saml/module.php/saml/sp/saml2-acs.php/default-sp'.

Backtrace:

3 /home/content/42/9099541/html/Apps/ResourceSpace/plugins/simplesaml/lib/modules/saml/lib/Message.php:694 (sspmod_saml_Message::processAssertion)

2 /home/content/42/9099541/html/Apps/ResourceSpace/plugins/simplesaml/lib/modules/saml/lib/Message.php:528 (sspmod_saml_Message::processResponse)

1 /home/content/42/9099541/html/Apps/ResourceSpace/plugins/simplesaml/lib/modules/saml/www/sp/saml2-acs.php:81 (require)

0 /home/content/42/9099541/html/Apps/ResourceSpace/plugins/simplesaml/lib/www/module.php:135 (N/A)

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-03-01 20:07]:

> So I have it setup now so that http://mydomain.org/saml/ works perfectly,
> but I am having 1 more issue that I would be greatly appreciative if you
> could assist me in implementing a fix.
>
> Testing simpleSAMLphp default-sp authentication on the webpanel at
> mydomain.org/saml/module.php/core/authenticate.php works fine now. But my
> issue is that when I try to use SSO through ResourceSpace, I have an issue.
> The process is as follows: I go to ResourceSpace at
> http://resources.mydomain.org.

Before fully reading your second/other email: If the protected
resource is at http://resources.mydomain.org. why would you want to
put the SAML SP in charge of protecting this resource on a different
vhost (or even machine)? That makes no sense.

So I'd start with moving /saml to the vhost of your application which
possibly will include the necessity to prevent that application from
also grabbing the URI /saml (possibly with an application error).
How that's done depends on the application and the web server
configuration -- SSP by definition is not involved in the case where
it is not being called at all.

Sadly it seems that everything you did here was from the opposite end
of what people here consider obvious, useful or sensible. Part of that
may be due to not reading and following the available documentation.
I'm sorry you're having such a bumpy ride.
-peter

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-03-01 22:16]:

> With my configuration all correct using the symlink as you
> requested, I also tried changing all of my configs to use my
> subdomain (resources.wsubsom.org), to try and fix my URL problem I
> mentioned above.

That's the Right Thing To Do anyway, as per my previous email, though
the fact that you're having the incorrect redirect means you have an
error somewhere. Changing the vhost may successfuly mask that error,
but there's still an error somewhere in your setup.

> I changed my baseurlpath, my entityID, regenerated my SP metadata,
> and had my IdP update my SP metadata and entityID on his end. So
> now, I am back to square one. I am getting the same error that I was
> getting in my very first post. My IdP says that the SSO
> authentication appears to be working perfectly fine on his end. So
> it's evident that the issue is when we are redirecting back to my
> end during the authentication process, SOMETHING (be it simpleSAML
> or ResourceSpace) is rewriting/changing my 'current URL' to
> something different and incorrect. My recipient URL is 100%
> correct. My current URL is not.

I think you'll agree that it's rather unlikely that SimpleSAMLphp will
inject a spurious redirect/rewrite of its own endpoints to something
including the name of your application.

As I've said before, unless you get SSP working form its web UI (test
authentication sources) with your IDP there's no reason to even look
at application integration.

And once that does work fine, it's up to the application and how
you're trying to integrate SSP with it. Note that you did not provide
any technical details on either of those last two aspects!

* joshc...@gmail.com <joshc...@gmail.com> [2017-03-01 22:16]:
> Backtrace:
>
> 0 /home/content/42/9099541/html/Apps/ResourceSpace/plugins/simplesaml/lib/
> www/module.php:180 (N/A)

How/Where did you install the SimpleSAMLphp software that you're now
referencing (with a file system symlink) as /saml?

If you followed my advise (and the SSP documentation) the above cannot
be the SimpleSAMLphp version you installed, as then it shouldn't be
within a file system path available to the webserver (as
/home/content/42/9099541/html/ strongly suggests is the case for
whatever is below.)

Does ResourceSpace come with a bundled version of SSP and are you
trying to configure that? Did you install SSP seperately and are you
configuring that? Are there two independent (and possibly conflicting)
SSP installs in that machine or only one?

Don't bother continuing with this here before you have answered all of
those questions.

If I had to guess from the above file system path alone I'd say you're
using some application that includes a copy of something related to
SSP (possibly modified, maybe not). What kinds of configutation of the
SSP parts they support/provide/document I don't know (and you haven't
provided specifics). Impossible to say what changes need to be made
where then to fix whatever is wrong in your environment.
-peter

[joshc...@gmail.com]

Peter,

1.) SimpleSAML was working with my IdP within the Web UI (test authentication sources), whenever I was using just mydomain.org as my baseurlpath and whatnot. Unfortunately, that does not work with integrating it into my ResourceSpace application as it would redirect back to mydomain.org, and that's not where ResourceSpace is... it's at resources.mydomain.org. 

2.) ResourceSpace does indeed come bundled with SSP (version 1.11.0). Yes I am trying to configure that.

3.) ResourceSpace bundles SSP within /ResourceSpace/plugins/simplesaml/lib. This is what I am trying to configure.

4.) I did not install SSP separately. It came with ResourceSpace, and I am trying to configure that so that we can use SSO with ResourceSpace.

5.) There is only one SSP install which is at /Apps/ResourceSpace/plugins/simplesaml/lib.

6.) There is little to no documentation on ResourceSpace's end with regards to SimpleSAML. They mention it here: https://resourcespace.montala.com/features?section=security and here: http://www.resourcespace.com/knowledge-base/user/plugin-simpleldap

7.) Here are the instructions provided by ResourceSpace: https://drive.google.com/file/d/0B032K-VmXz55eGtaa1pEZldLUDQ/view?usp=sharing

Hope this clears up some confusion. Thanks again for the help.

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-03-06 15:15]:

> 1.) SimpleSAML was working with my IdP within the Web UI (test
> authentication sources), whenever I was using just mydomain.org as my
> baseurlpath and whatnot. Unfortunately, that does not work with integrating
> it into my ResourceSpace application as it would redirect back to
> mydomain.org, and that's not where ResourceSpace is... it's at
> resources.mydomain.org.

Why would you tell the copy of SSP that comes embedded with the
ResourceSpace application that its fully qualified host name is
"mydomain.org", when the application (that includes an embedded
version of SSP) runs at "resources.mydomain.org"?

> 2.) ResourceSpace does indeed come bundled with SSP (version
> 1.11.0).

It goes without saying, but when using old versions of security
oftware you should be aware of and able to handle any issues
discovered since that version was released.

Also unless you're sure no part of the SimpleSAMLphp software as
shipped by ResourceSpace has been modified by ResourceSpace in anyway,
this group may not be able to give authoritative advise on its use.

> 3.) ResourceSpace bundles SSP within /ResourceSpace/plugins/simplesaml/lib.
> This is what I am trying to configure.

No way to know for me how that is expected/supposed to be exposed to
the web (server). So I'd expect just following *their* instructions
would take care of this. Since it doesn't mention any special steps to
be taken wrt exposing that to the web, and using extra vhosts,
etc. maybe none are in fact required.

> 6.) There is little to no documentation on ResourceSpace's end with regards
> to SimpleSAML. They mention it
> here: https://resourcespace.montala.com/features?section=security and
> here: http://www.resourcespace.com/knowledge-base/user/plugin-simpleldap

The former just says that something is available in the knowledge
base, but the latter (as referenced form the former) only talks about
LDAP. "SAML" is only mentione once on that page, in the sentence:
"If you already have an organisation wide single sign-on system please
refer to the simplesaml plugin.".
How one would refer to that "simplesaml plugin" remains a mystery.

> 7.) Here are the instructions provided by
> ResourceSpace: https://drive.google.com/file/d/0B032K-VmXz55eGtaa1pEZldLUDQ/view?usp=sharing

Well, that starts with stating that you'll need your own working SAML
2.0 IDP, but then goes on to enable the SAML IDP functionality of the
embedded SimlpeSAMLphp software (for no apparent reason, as it's not
touched or configured later on), which does not inspire confidence
that they have a firm grasp on things.

Other than that, there is no mention whatsoever that you'd need to
configure the baseurlpath yourself, or make any other changes
discussed to far. Esp it does not tell you to confuse yourself by
accessing the software with multiple vhosts, including accessing the
embedded SSP software at a different vhost than the rest of the
application?

-peter

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-02-27 14:51]:
> 0 /home/content/31/9055421/html/Apps/ResourceSpace/plugins/simplesaml/lib/
> www/module.php:180 (N/A)

Looking at the 8.0 release (and SVN repo) there's no www directory
within plugins/saimplesaml/lib at all. How can you be getting this
error then -- or expose SSP's www directory to the webserver?
-peter

[joshc...@gmail.com]

I just downloaded the most recent version of ResourceSpace to verify.... inside of /plugins/simplesaml/lib there is www.zip. Then within their instructions they say to just unzip that.

[Peter Schober]

* joshc...@gmail.com <joshc...@gmail.com> [2017-03-07 16:24]:

> I just downloaded the most recent version of ResourceSpace to verify....
> inside of /plugins/simplesaml/lib there is www.zip. Then within their
> instructions they say to just unzip that.

I noticed the zip file but must have missed their instructions to
unzip it (for whatever reason they're doing this), I only glanced over
their docs.
The rest still stands, incl. the question Where would the second vhost
come from if you're merely using an embedded version of SSP with an
application?
-peter