Users are always returned to simpleSAMLphp welcome page after login

2,688 views
Skip to first unread message

Jacob Poul Richardt

unread,
Nov 8, 2013, 2:38:00 AM11/8/13
to simple...@googlegroups.com
Hey

I've set up a service provider in simpleSAMLphp that uses the wayf.dk idp (SAML 2).
It seems to almost be working, but after a user has logged in at the idp and is returned to simpleSAMLphp,
he is redirected to the simpleSAMLphp welcome page (simplesaml/module.php/core/frontpage_welcome.php)
instead of the page where the login was initiated. Even if I specify a return url, the user is still returned to the welcome page.
I checked the POST data sent from the IDP, and it apears to be valid SAML metadata with the attributes from the logged in user.
If I try to use the built in tool for testing SPs (/simplesaml/module.php/core/authenticate.php) I get the same result.

This is the first time I work with simpleSAMLphp, so might be something that should be obvious.
I appreciate any help
Jacob



I'm using simpleSAMLphp version 1.11.0.

This is the code I use to test the SP:
require_once('../../lib/_autoload.php');

$simpleSaml= new SimpleSAML_Auth_Simple("***");

$simpleSaml->requireAuth(array(
    'ReturnTo' => 'https://***/test.php',
    'KeepPost' => FALSE,
));

$attributes = $simpleSaml->getAttributes(); //This is never called
This is my SP configuration:
'***' => array(
        'saml:SP',
        'redirect.validate' => true,
        'redirect.sign' => true,
        'privatekey' => '***.key',
        'certificate' => '***.crt',
        'entityID' => 'https://***',
        'idp' => 'https://***',
        'attributes' => array(
            'eduPersonTargetedID',
            'GivenName',
            'SurName',
            'mail',
            'eduPersonScopedAffiliation',
            'schacHomeOrganization',
        ),
        'attributes.required' => array (
            'eduPersonTargetedID',
            'GivenName',
            'SurName',
            'mail',
            'eduPersonScopedAffiliation',
            'schacHomeOrganization',
        ),
    ),

Peter Schober

unread,
Nov 8, 2013, 8:17:20 AM11/8/13
to simple...@googlegroups.com
* Jacob Poul Richardt <jacobr...@gmail.com> [2013-11-08 09:10]:
> Even if I specify a return url, the user is still returned to the
> welcome page.
> I checked the POST data sent from the IDP, and it apears to be valid SAML
> metadata with the attributes from the logged in user.

Check SimpleSAMLphp's log files, possibly on DEBUG (setting in
config.php), also look at the HTTP requests and responses e.g. using
the Firefox SAML tracer or HTTP Live Headers extension, look for the
RelayState query parameter.
The URL to end up after the protocol message exchange (i.e.,
RelayState) is not part of the HTTP POST payload and it also is not
SAML metadata what you find inside a SAML assertion.
-peter

Jacob Poul Richardt

unread,
Nov 11, 2013, 3:40:01 AM11/11/13
to simple...@googlegroups.com, peter....@univie.ac.at
On Friday, 8 November 2013 14:17:20 UTC+1, Peter Schober wrote:
Check SimpleSAMLphp's log files, possibly on DEBUG (setting in
config.php), also look at the HTTP requests and responses e.g. using
the Firefox SAML tracer or HTTP Live Headers extension, look for the
RelayState query parameter.
The URL to end up after the protocol message exchange (i.e.,
RelayState) is not part of the HTTP POST payload and it also is not
SAML metadata what you find inside a SAML assertion.
-peter

Thanks for the suggestions, the RelayState appears to be correct, it is set to the original url (the url that it should return to but doesn't).

Looking at the logs there are no errors (debug enabled, log level set to debug).
The only thing of note is a "Session: 'MySP' not valid because we are not authenticated." message, but that appears before "Sending SAML 2 AuthnRequest", which makes sense to me (not authenticated before we are authenticated ).
When user is returned to simpleSAMLphp (looking at the timecodes) there is no mention of MySP.

One other thing I did see, is that using the test with the built in admin login (using the "core:AdminPassword" protocol) does work, and after login I see a list (of one) user attributes.
This suggests to me that it must be something specific to the SAML configuration.

Do you have any other ideas?

Peter Schober

unread,
Nov 11, 2013, 4:39:06 AM11/11/13
to simple...@googlegroups.com
* Jacob Poul Richardt <jacobr...@gmail.com> [2013-11-11 09:40]:
> Thanks for the suggestions, the RelayState appears to be correct, it
> is set to the original url (the url that it should return to but
> doesn't).

Make sure (by tracing the traffic) it is set by the SP, that it is
returned from the IdP verbatim and also that the web browser sends it
to the SP.
When all that is correct and the SP still sends you to the wrong URL
after session establishment there must be something else off in your
environment.
-peter

Jacob Poul Richardt

unread,
Nov 11, 2013, 5:24:39 AM11/11/13
to simple...@googlegroups.com, peter....@univie.ac.at


On Monday, 11 November 2013 10:39:06 UTC+1, Peter Schober wrote:

Make sure (by tracing the traffic) it is set by the SP, that it is
returned from the IdP verbatim and also that the web browser sends it
to the SP.
When all that is correct and the SP still sends you to the wrong URL
after session establishment there must be something else off in your
environment.
-peter

It is, that is what I saw before (thanks for mentioning SAML tracer btw).
I guess I'll try a fresh copy of simpleSAMLphp, the enviroment is a fresh virtual server, don't think there should be anything wrong there.
I must have messed something up somewhere.

Jacob Poul Richardt

unread,
Nov 13, 2013, 10:33:48 AM11/13/13
to simple...@googlegroups.com, peter....@univie.ac.at
Just wanted to drop an update here in case anyone else experience the same thing.

When I was about to reinstall simpleSAMLphp, I figured I might just try using the default settings to try and login via openidp.feide.no.
And suprise suprise, it worked.
So after a bit more exploring, I figured out that the wayf.dk idp does not return the user to the correct address, even though it forwards the RelayState parameter.
I should have seen it when Peter suggested to check RelayState, I just didn't expect the idp to return the user to the root of the url instead of the full url.

So I'm getting in touch with the Wayf.dk idp people to figure this out.

Peter Schober

unread,
Nov 13, 2013, 10:44:21 AM11/13/13
to simple...@googlegroups.com
* Jacob Poul Richardt <jacobr...@gmail.com> [2013-11-13 16:33]:
> So after a bit more exploring, I figured out that the wayf.dk idp
> does not return the user to the correct address, even though it
> forwards the RelayState parameter.
> I should have seen it when Peter suggested to check RelayState, I
> just didn't expect the idp to return the user to the root of the url
> instead of the full url.

I think you're mistaken: It is not the IdP that sends you to the
originally requested resource, it is the SP, after establishing a
security context (session). You should be able to see that when using
SAML tracer:
For the most common WebSSO protocol exchange you authenticate at the
IdP (at some point), then the IdP HTTP-POSTs a response to the SP (via
the browser), more specifically to the SP's Assertion Consumer Service
URL (/not/ the resource itself) which includes the SAML assertion and
the RelayState. The SP then processes the SAML and will eventually
redirect (as in: HTTP Location header, Status 302) the browser to the
resource (or not, in case of problems with the RelayState).

So it cannot be exactly as you describe it.
Also WAYF.dk is processing millions of logins, if people never ended
up at the right resouce I think they would have noticed.

So something else seems amiss, but it can't hurt to contact WAYF for
support anyway.
-peter

Jacob Poul Richardt

unread,
Nov 13, 2013, 11:05:55 AM11/13/13
to simple...@googlegroups.com, peter....@univie.ac.at
Hehe, yeah the wayf.dk idp works for sure.
But the idp doesn't seem to work "out of the box" like openidp.feide.no.
I guessing it's some simple config related issue, but the user really isn't returned to simplesaml, but instead to the root of the domain where simplesaml is.
This fooled me earlier since I had it configured so simplesaml was hosted at the root. But I changed that now in an effort to root out any causes (so now it's hosted at /simplesaml like the suggested setup).

I don't really now much about SAML, but maybe it's the included (in SAML) AssertionConsumerServiceURL property, the value seems to be the correct return url.

Peter Schober

unread,
Nov 13, 2013, 11:51:56 AM11/13/13
to simple...@googlegroups.com
* Jacob Poul Richardt <jacobr...@gmail.com> [2013-11-13 17:06]:
> But the idp doesn't seem to work "out of the box" like
> openidp.feide.no. I guessing it's some simple config related issue,
> but the user really isn't returned to simplesaml, but instead to the
> root of the domain where simplesaml is.

Overly simplifying a bit: If you're sent to the IdP (using a HTTP
redirect or HTTP POST including a SAML 2.0 authentication request) and
after successful authentication the IdP does anything other than
returning a SAML protocol message to the SP (at its registered
endpoints for that SP, usually via SAML metadata), that IdP is
broken. Which I find highly unlikely in the case of WAYF.dk, hence my
questioning of your account of what really happens.

All of which only you can find out, via ways I've already described.
The only other party who could help you out with this, is the IdP.
-peter

Bjorn Rohde Jensen

unread,
Nov 13, 2013, 1:50:11 PM11/13/13
to simple...@googlegroups.com
Hi guys,

We at the State and Univerity Library in Aarhus have been using this
setup in production for years without significant problems. We have
several service providers and a single identity provider registered with
wayf.dk, and we are for the most part running simplesamlphp-1.11.0 like you.

> * Jacob Poul Richardt <jacobr...@gmail.com> [2013-11-13 17:06]:
>> But the idp doesn't seem to work "out of the box" like
>> openidp.feide.no. I guessing it's some simple config related issue,
>> but the user really isn't returned to simplesaml, but instead to the
>> root of the domain where simplesaml is.

It is very close to "out of the box" in my experience. After unpacking
simplesamlph in the proper location and tweaking config.php and
authsources.php, it is just a question of metadata exchange. The only
things, we tweak manually relate to signature validation and base64
encoding of attributes.

>
> Overly simplifying a bit: If you're sent to the IdP (using a HTTP
> redirect or HTTP POST including a SAML 2.0 authentication request) and
> after successful authentication the IdP does anything other than
> returning a SAML protocol message to the SP (at its registered
> endpoints for that SP, usually via SAML metadata), that IdP is
> broken. Which I find highly unlikely in the case of WAYF.dk, hence my
> questioning of your account of what really happens.

It sounds like, it might be worth it to scrap the "connection" you
currently have registered with wayf.dk and recreate it using the
metadata from simplesamlphp's federation tab. I have found it less error
prone to recreate rather than edit or verify my metadata on wayf.dk's
registration site by hand.

Yours sincerely,

Bjorn

Jacob Poul Richardt

unread,
Nov 15, 2013, 4:39:20 AM11/15/13
to simple...@googlegroups.com, bje...@fastmail.fm
Success!

I followed your advice and tried scrapping the connecting at wayf (in their JANUS admin interface) and then just giving wayf the metadata url from the federation tab in simpleSAMLphp.
Not sure what made the difference.

Thanks you so much (and Peter as well).

Peter Schober

unread,
Nov 15, 2013, 4:47:09 AM11/15/13
to simple...@googlegroups.com
* Jacob Poul Richardt <jacobr...@gmail.com> [2013-11-15 10:39]:
> I followed your advice and tried scrapping the connecting at wayf (in their
> JANUS admin interface) and then just giving wayf the metadata url from the
> federation tab in simpleSAMLphp.
> Not sure what made the difference.

As that sounds like (black) magic please make sure to report this
issue to WAYF.dk. I'm sure they will want to look into this and
possibly fix it,
-peter
Reply all
Reply to author
Forward
0 new messages