SP is not a valid audience for the assertion. Candidates were: AND SimpleSAML_Error_MetadataNotFound: METADATANOTFOUND('%ENTITYID%' =>

[Tommy Peterson]

I have simplesamlphp set up for an sp and idp using the same domain name. Let's say it is https://mysaml.something.com

I am not using phpsessions. I am using SQL. I see them in the database tables that go created.

I updated the config file as well to include 'session.cookie.domain' => '.something.com',

I have tested it out on the simplesaml admin page. Both sp and idp work just fine. When I log in I get the attributes back.

I have also installed the simplesamlphp module on my Drupal which is also installed on the same server. Let's say my Drupal hostname is https://mydrupal.something.com

I configured the module. I told it to use the local simplesamlphp library. I told it to use the "default-sp" SP.

When I click on the Federation link on the login or go directly to https://mydrupal.something.com/?=saml_login I get the following error:
SimpleSAML_Error_MetadataNotFound: METADATANOTFOUND('%ENTITYID%' => 'https://mydrupal.something.com/simplesaml/module.php/saml/sp/metadata.php/default-sp\'')

So I added an entityid to my default-sp in config/authresources.php for https://mydrupal.something.com/simplesaml/module.php/saml/sp/metadata.php/default-sp. I then updated the metadata20-sp-remote.php file with the same name.

Now, when I click on the Federation link on the login or go directly to https://mydrupal.something.com/?=saml_login I get the following error:
Caused by: SimpleSAML_Error_Exception: This SP [https://mysaml.something.com/simplesaml/module.php/saml/sp/metadata.php/default-sp]  is not a valid audience for the assertion. Candidates were: [https://mydrupal.something.com/simplesaml/module.php/saml/sp/metadata.php/default-sp]
Backtrace:

I have played around with the host parameter in metadat20-idp-remotephp. I tried using the mydrupal.something.com and mysaml.something.com. It is now __DEFAULT__

I tried adding a mydrupal.something.com entry to the metadata20-sp-remote.php file and changing all the URLs to mydrupal.something.com. They error out as there is not simplesaml/module.php/. . . for mydrupal.something.com on my server. I am trying to use the simplesamlphp installed default-sp that connects to the idp here. THye are local.

The issue appears to be that my drupal has a domain name that is different from my sp/idp and when I am trying to return to the drupal upon authentication something happens.

I have no idea how to fix this. Anyone? I have looked at this mailinglist. I have seen a couple of close discussions. But nothing there helped me out.

[Nate Klingenstein]

Tommy,

The error is occurring because SAML requires that trusted messages be sent to trusted locations. This is protection against replay of valid assertions by untrusted entities and it’s necessary for bearer tokens. Think analogous to cookies only getting sent to your domain.

In this case, the IdP is issuing assertions to a location that it believes is valid. The assertion is being delivered to you, by you, successfully. Your SP is dropping it then because it doesn’t know whether this is an attack because it thinks it’s not a valid recipient.

The fix in almost all cases is to re-examine the virtualization of your web environment. Whether this is rooted in Drupal, httpd, your pages, or so forth, and what it should actually be for both the IdP and SP, is something that we can’t know from the outside.

Using one domain name for the IdP and SP is totally possible, but a great way to get yourself tied in knots if you try to start there. I would start with a known working entity if possible, or two domain names if not. Otherwise, you’ll have to get the virtualization right for both components simultaneously and instantaneously.

Thanks,
Nate.

[Tommy Peterson]

Unfortunately I didn't set up the virtualization. And I don't have permissions too edit/view the apache configs.

I saw in the simplesamlphp docs that, if on the same system, the idp and sp should have different domains. Does this imply that I have should set up simplesamlphp twice? One with for the idp and the hostname mapped to it. And another time for the sp with a different hostname mapped to it?

Then just change what I have so that the urls/hostnames are pointing to the new hostname/simplsesaml installation mapping?

[Nate Klingenstein]

> Unfortunately I didn't set up the virtualization. And I don't have permissions too edit/view the apache configs.

That’ll make debugging modestly more exciting.

> I saw in the simplesamlphp docs that, if on the same system, the idp and sp should have different domains. Does this imply that I have should set up simplesamlphp twice? One with for the idp and the hostname mapped to it. And another time for the sp with a different hostname mapped to it?

Well, there needs to be an IdP and an SP. You can set domains for each, but you do need to configure each. Your IdP is logging users in. Your SP is protecting your application. Whether this is mechanically one install or not is up to you.

> Then just change what I have so that the urls/hostnames are pointing to the new hostname/simplsesaml installation mapping?

You’ll need to make sure that the SP points to the IdP, and the IdP recognizes the SP. How you go about that is up to you.

If I had to guess based on the information available to me, you’re probably trying to use the same entityID for the IdP and the SP, which would break unless you get the metadata and virtualization right, but I know even less than you do about this system.

[Tommy Peterson]

Thanks for your help, Nate.

I will look into the entityid duplication for the IDP and SP.

But when I speak to the system admin about the virtualization I remember us discussing the simplesamlphp documentation here:

<VirtualHost *>
        ServerName service.example.com
        DocumentRoot /var/www/service.example.com

        Alias /simplesaml /var/simplesamlphp/www
</VirtualHost>

Is there something given the drupal, idp, and sp concerning the above and my situation that I should speak with him about? 

[Nate Klingenstein]

> I will look into the entityid duplication for the IDP and SP.

They’re just names, so don’t worry that they need to resolve to something(although it's helpful if they do). URI’s are used by the spec as an easy way to get uniqueness. The endpoints do need to resolve and are associated with an entity, which is why I had the hunch that you’ve got the same entityID and your IdP is kinda sending assertions to itself. Here’s a brief, annotated metadata file:

http://testshib.org/metadata/testshib-providers.xml

I believe the error means precisely that the AssertionConsumerService to which the assertion was delivered doesn't consider itself a trusted endpoint listening there for the entityID it was issued to, but the simpleSAMLphp team may know more. Most of this is powered by virtualization and the underlying web server directives, including the redirect generation and response processing, which is why I pointed you there first.

> <VirtualHost *>
> ServerName service.example.com
> DocumentRoot /var/www/service.example.com
>
> Alias /simplesaml /var/simplesamlphp/www
> </VirtualHost>
>
> Is there something given the drupal, idp, and sp concerning the above and my situation that I should speak with him about?

This would be the Apache virtualization, so yes, highly relevant if not "the problem".

Glad to help,
Nate.

[Tommy Peterson]

I just got back to my desk. I checked the IDP and SP are not the same entityid:

IDP:
https://mysaml.something.com/simplesaml/saml2/idp/metadata.php

SP:
https://mysaml.something.com/simplesaml/saml2/sp/metadata.php

I found this which is what I was thinking I should do to separate out the hostnames for the IDP and SP which I mentioned below; it appears this guy did it that way too:

"    <VirtualHost *:80>

DocumentRoot "/Applications/XAMPP/xamppfiles/htdocs/idp"

ServerName idp.vaishnav.com

Alias /simplesaml /Applications/XAMPP/xamppfiles/htdocs/simplesamlphpidp/www/

     </VirtualHost>

     <VirtualHost *:80>

DocumentRoot "/Applications/XAMPP/xamppfiles/htdocs/sp"

ServerName sp.vaishnav.com

Alias /simplesaml /Applications/XAMPP/xamppfiles/htdocs/simplesamlphpsp/www/

     </VirtualHost>

Note: I am not using https and I have two installations of simplesamlphp, one for sp and one for idp. I could have done it on the same install, but I decided to go this route to get a clear idea of what needs to be done on each side."

The weird this is that I used simplesamlphp to set up an adfs SSO and it was pretty straightforward. Worked easily after I got the claim rules set up correctly. But I've never tried to set up a sp/idp on the same machine. Didn't think it would be a problem until I read that "note" in the docs (which had no explanation of how to do it).

Anyway thanks again fo ryour help here. I will try the separate approach and report back here to help someone else experiencing this.

[Nate Klingenstein]

> and I have two installations of simplesamlphp, one for sp and one for idp. I could have done it on the same install, but I decided to go this route to get a clear idea of what needs to be done on each side.”

You may have requests getting routed to the wrong instance as another vague hunch, but as mentioned, it’s hard to guess from here.

> The weird this is that I used simplesamlphp to set up an adfs SSO and it was pretty straightforward. Worked easily after I got the claim rules set up correctly. But I've never tried to set up a sp/idp on the same machine. Didn't think it would be a problem until I read that "note" in the docs (which had no explanation of how to do it).

I’ve tried to explain it 17 different ways to myself, but I just end up more confused than when I started, with sprinkles. ADFS and other implementations can sometimes make simplifying assumptions about their deployment environment or pour a lot of resources into configuration tools, luxuries that simpleSAMLphp doesn’t have.

If I could go back and rewrite the Internet, I’d start with the OSI model, a crowbar, and some superglue… but, until that time, secure messaging between arbitrary systems through a third party vector(e.g. idp <-> sp via browser) will always take some jiggling or assumptions.

Anyway, to debug each leg specifically:

A) Compare the SP metadata as loaded by the IdP to the AuthnRequest content, a check the IdP makes, which is succeeding, in your case, so skip; just adding for archives
B) Compare the Audience of the decrypted assertion to the SP’s configuration

My guess is that you’ll either find the SP’s entityID in the Audience, while the SP thinks its real name is the IdP’s entityID, or you’ll find the IdP’s entityID. I would suspect the former. That said, your currently planned approach makes sense to me, other than the futility of ending up with session persistence in plaintext cookies over http, which I presume is a shoelace you’ll go back for.

If you’re not allergic to code — and this sort of mutilation is the extent of my development talent, so forgive me for mooning the list — you might also just print out or log the two pieces being compared to see why the equality match is failing. A grep should point to the specific processing points. Adding a little more verbosity to the error message in the distribution wouldn’t be a bad feature request, IMO.

[Peter Schober]

* Tommy Peterson <stpe...@gmail.com> [2015-06-20 19:15]:

> Now, when I click on the Federation link on the login or go directly to
> https://mydrupal.something.com/?=saml_login I get the following error:
> Caused by: SimpleSAML_Error_Exception: This SP
> [https://mysaml.something.com/simplesaml/module.php/saml/sp/metadata.php/default-sp]
> is not a valid audience for the assertion. Candidates were:
> [https://mydrupal.something.com/simplesaml/module.php/saml/sp/metadata.php/default-sp]

I'd make sure the SP is on the same vhost as the protected resource
(Drupal, here), and the IDP is wherever you want it. (Ideally
somewhere else for sanity, but all can be on a single vhost if needed,
too.)
-peter

[Tommy Peterson]

OK. I installed simplesamlphp twice. Pointed the new sp hostname to the one. Set it up as the SP. Pointed the new idp hostname to the other one. Set it up as the IDP. Swapped metadata. Tested them through simplesamlphp admin site. All works.

Added a second sp for the drupal to the sp set up. Add the metadata for it to the idp set up. I now get routed to the log in page. I am authenticated but I am returned to the simplesamlphp admin page with a "Congratualtions you have set up simplesamlphp!" message etc.

I set the relaystate in the drupal to return me to the drupal site/homepage. In the drupal simplesamlphp config in drupal I set it there as well.

Is there somewhere else I am supposed to set this redirect?

[Tommy Peterson]

when I am routed to the IDP from Drupal here is the URL; it includes the correct sp entity id and relay state:

https://idp.something.com/simplesaml/module.php/core/loginuserpass.php?AuthState=_f4f0c566425f36783f5e875d72efcc79837a6e91c2%3Ahttps%3A%2F%2Fidp.something.com%2Fsimplesaml%2Fsaml2%2Fidp%2FSSOService.php%3Fspentityid%3Dhttps%253A%252F%252Fdrupal.something.com%26
cookieTime%3D1434999500%26RelayState%3D
https%253A%252F%252Fdrupal.something.com%252F%253Fq%253Dsaml_login

at first I thought it was the relaystate of https://drupal.something.com/saml_login (which is the log in url for that drupal app with the simplesamlphp module). But I removed it from teh url while on the idp log in page and it still redirects me to the simplesamlphp log in page.

[Tommy Peterson]

It is not the drupal module. It is my simplesaml. I tested the drupal module code out and the problem happens when the drupal module asks simple simplesaml to require authentication.

I got access to view my apache config. the IP addresses are the same.

here it is; does anyone see anything:

<VirtualHost ip:443>
    DocumentRoot /path/to/idp/simplesamlphp/www
    ServerName  idp.something.com

    Alias /simplesaml /path/to/idp/simplesamlphp/www/

    SSLProtocol all -SSLv2
    SSLCipherSuite ALL: something goes here
    SSLEngine On
    SSLCertificateFile my.crt
    SSLCertificateKeyFile my.key
    SSLCertificateChainFile my.crt
</VirtualHost>

<VirtualHost ip:80>
    DocumentRoot /path/to/sp/simplesamlphp/www
    ServerName  sp.something.com

        Alias /simplesaml /opt/websites/tommy1/simplesamlphp/www/

        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost ip:443>
    DocumentRoot /path/to/sp/simplesamlphp/www
    ServerName  sp.something.com

    Alias /simplesaml /path/to/sp/simplesamlphp/www/

    SSLProtocol all -SSLv2
    SSLCipherSuite ALL: something goes here
    SSLEngine On
    SSLCertificateFile my.crt
    SSLCertificateKeyFile my.key
    SSLCertificateChainFile my.crt
</VirtualHost>

<VirtualHost ip:80>
        ServerName drupal.something.com
        DocumentRoot /path/to/drupal
        <Directory "/path/to/drupal">
        Options FollowSymLinks
        AllowOverride None
        Order allow,deny
        Allow from all
        DirectoryIndex index.php
        </Directory>
</VirtualHost>

<VirtualHost  ip:443>
        ServerName drupal.something.com
        DocumentRoot /path/to/drupal
        <Directory "/path/to/drupal">
        Options FollowSymLinks
        AllowOverride None
        Order allow,deny
        Allow from all
        DirectoryIndex index.php
    </Directory>

    SSLProtocol all -SSLv2
    SSLCipherSuite ALL: something goes here
    SSLEngine On
    SSLCertificateFile my.crt
    SSLCertificateKeyFile my.key
    SSLCertificateChainFile my.crt
</VirtualHost>

Thank you for your help.

[Tommy Peterson]

In the log with debug mode for the sp right after the attributes are listed based upon authentication I see this:

Loading state: '_a32b22b254e3b26b1322f093d252f0ee08b4018d14'


Jun 22 17:21:02 simplesamlphp DEBUG [af62bc154d] Received SAML2 Response from 'https://idp.something.com/simplesaml/saml2/idp/metadata.php'.


Jun 22 17:21:02 simplesamlphp DEBUG [af62bc154d] Has 1 candidate keys for validation.


Jun 22 17:21:02 simplesamlphp DEBUG [af62bc154d] Validation with key #0 succeeded.


Jun 22 17:21:02 simplesamlphp DEBUG [af62bc154d] Has 1 candidate keys for validation.


Jun 22 17:21:02 simplesamlphp DEBUG [af62bc154d] Validation with key #0 succeeded.


Jun 22 17:21:02 simplesamlphp DEBUG [af62bc154d] Filter config for https://idp.something.com/simplesaml/saml2/idp/metadata.php->https://drupal.something.com: array (  0 =>   sspmod_core_Auth_Process_LanguageAdaptor::__set_state(array(     'langattr' => 'preferredLanguage',     'priority' => 90,  )),)

That is the correct sp entity that the idp is pointed to.

[Tommy Peterson]

after using samltrace in firefox it appears that the user is authenticated then logged out and then redirected to the page. I ahve no idea why. I copied and pasted the metadata from simplesaml.

Anyone?

[Tommy Peterson]

Without anything else to try but trace the saml I realized that the SP was sending me back to the IDP and logging me out. It appears that way. So I forgot that I had changed the session storage to SQL/Mysql database. And since I separated out the idp from the sp yesterday I created a separate database for the IDP session storage. Now each has their own. So now I access drupal, click the federation link, get routed to the sp, get prompted with the log in page, log in, get authenticated and have the IDP release the attributes to te h session, but get a no state error when I am returned to the SP.

I feel like I am in an endless cycle going no where.

I read on here a post where someone pointe dto this doc:
https://code.google.com/p/simplesamlphp/wiki/LostState

I have all that covered. I had the sys admin check the virtual hosts after I looked at them. All seems ok there. The certs are there.

[Peter Schober]

* Tommy Peterson <stpe...@gmail.com> [2015-06-23 16:30]:

> Without anything else to try but trace the saml I realized that the SP was
> sending me back to the IDP and logging me out. It appears that way. So I
> forgot that I had changed the session storage to SQL/Mysql database. And
> since I separated out the idp from the sp yesterday I created a separate
> database for the IDP session storage. Now each has their own. So now I
> access drupal, click the federation link, get routed to the sp, get
> prompted with the log in page, log in, get authenticated and have the IDP
> release the attributes to te h session, but get a no state error when I am
> returned to the SP.

Hard to keep track with your many posts and changes happening between
them.
I'd try to only test the SSP SP that's part of your Drupal site (if
that's possible) and your IDP, with SSP code only. E.g. calling
/path/to/simplesaml/module.php/core/authenticate.php on the vhost
hosting the SSP SP.
I've never used anything else than the default session store and also
never ran into the no state/lost state error. The defaults of the
software always just worked. This would suggest it's something
environmental.
-peter

[Tommy Peterson]

You asked yesterday if the sp and drupal were on the same vhost. I guess I didn't quite understand what you were asking.

So without knowing what else to try I asked the sys admin to change the apache hosts file to point to the simplesamlphp sp directory from https://drupal.something.com/simplesaml since drupal is https://drupal.something.com, for example. I did have the sp as https://sp.something.com and the idp as https://idp.something.com.

I am able to log in and get returned to Drupal. However, I am still not logged in. So one issue resolved. I am no longer returned to the sp admin page.

The logs tell me that I am authenticated, returned to the sp, then a logout request is issued and returned to teh drupal site. So I am still being logged out.

I removed the second sql database for the sessions. I only have one sql database for sessions now: both sp and idp. That didn't fix it.

So I am kinda still stuck. Environmental? Sounds like it. But I don't know where else to look or try.

[Tommy Peterson]

just following back up here for completion/history.

the simplesamlphp issue was solved by me changing my virtual host (or having the sys admin do it) to make my sp https://drupal.something.com/simplesaml instead of https://sp.something.com while the drupal was https://drupal.something.com

But the continuing logouts was because the simplesamlphp module for Drupal (perhaps out of scope here for this forum but again just mentioning it for completion/history) could not find an entry for an authentication type of "simplesamlphp" in the authmap table as my requirement is not to allow drupal users to be created on the fly via simplesamlphp authentication. Since I am using Drupal's latest stable simplesamlphp and not their  latest dev version with many patches to take care of this I updated the code tot eh dev version found here-> https://www.drupal.org/node/1280930. So I then had a Drupal admin checkbox to automatically create authamp entries for simplesamlphp login attempts where drupal manual accounts already existed (the error).

It all works now.

[Nate Klingenstein]

I am able to log in and get returned to Drupal. However, I am still not logged in. So one issue resolved. I am no longer returned to the sp admin page. 

That makes no sense unless the SP is losing your intended destination page.  That could happen if the IdP were ill-behaved or if your SP was misconfigured badly.

The logs tell me that I am authenticated, returned to the sp, then a logout request is issued and returned to teh drupal site. So I am still being logged out.

That would make sense.

I removed the second sql database for the sessions. I only have one sql database for sessions now: both sp and idp. That didn't fix it. 

That would make no sense.

So I am kinda still stuck. Environmental? Sounds like it. But I don't know where else to look or try.

Yep, yep, and yep.

[Nate Klingenstein]

If this guess is off, the other thing you might check is the destination URL supplied by Drupal.  It will usually be in the AuthnRequest in some form.  If you have a Logout URL where you have a protected resource, this could hypothetically happen.

It’s still not a common error situation.

[Peter Schober]

* Tommy Peterson <stpe...@gmail.com> [2015-06-23 19:39]:

> So without knowing what else to try I asked the sys admin to change the
> apache hosts file to point to the simplesamlphp sp directory from
> https://drupal.something.com/simplesaml since drupal is
> https://drupal.something.com, for example. I did have the sp as
> https://sp.something.com and the idp as https://idp.something.com.
>
> I am able to log in and get returned to Drupal. However, I am still not
> logged in. So one issue resolved.

Glad to hear that. I always move the SP as close to the protected
resource as possible, so I never have a SAML SP on a vhost of its own,
without any relation to a protected resource. Unless you're doing
something much more complicated (proxying etc.) having the SP on its
own vhost just doesn't make much sense to me.

Also make sure the vhosts points to SSP's "www" directory, not the
SimpleSAMLphp base directory, otherwise config files and/or keys could
have been exposed to the web server. That's not clear to me from the
above.
-peter

[Tommy Peterson]

yep just the www directory. I think the docs are clear on that. but the docs should really stress using the same hostname instead of just domain name. All my sites were on the same domain. They were subdomains. And of course they can share cookies since they are aon the same subdomain. Maybe it is just me but if the distinction were noted in the saml docs I would have saved myself a lot of time and avoided nervous project manager calls for calls on this task of mine. :-)

[Peter Schober]

* Tommy Peterson <stpe...@gmail.com> [2015-06-24 13:19]:

ACK. SAML only cares about "correct" endpoints (FQDNs), i.e., it is
cross-domain by default. SAML entities (IDP, SP) may or may not share
a common DNS domain -- unless you do something extra (see below) this
doesn't factor into any of the processing.

In some cases you may not want to use the SAML protocol to exchange
data between systems, and when you share a common administrative and
DNS domain you could also share cookies, session stores, etc., but all
that (by defintion) is outside of SAML and outside of SSP's default
configuration/documentation.
-peter