IDP Initiated SSO - after the Response is authenticated it redirects to saml2-acs.php with no authsource

[Jack Meyer]

Hi,

I have set up a test ADFS and set up an application there that has an endpoint for

https://mydomain.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp

It gets through saml2-acs using the default-sp but I am not sure how to tell it where to go from there? It sends itself back to

https://www-staging.bigideasmath.com/simplesaml/module.php/saml/sp/saml2-acs.php

Which causes an error because no auth-source was provided. Am I missing something somewhere in my configuration? I have added a RelayState into my authsource pointing to where I want it to go after handling the SAMLResponse, but it always returns to saml2-acs.php with no auth source specified.

Thanks for any help you can provide.

-Jack

[Jack Meyer]

So it looks like that the response being sent is unsolicited and therefore saml2-acs.php sets the saml:sp:RelayState to SimpleSAML_Utilities::checkURLAllowed($response->getRelayState()) and since getRelayState() returns an empty string, it gets itself (saml2-acs.php) back as the RelayState.

So I am not sure why the RelayState I set in the default-sp is not being used instead, is it solely because this is an unsolicited response and for some reason we don't want it to use the RelayState set in the authSource?

In an ADFS 2.0 Application how do I set the relaystate? I can't seem to find anywhere in the Relying Party Trusts that I can set the RelayState. Is there some other way to do this?

[Peter Schober]

* Jack Meyer <jrm...@gmail.com> [2014-05-07 18:49]:

> So it looks like that the response being sent is unsolicited

That's merely paraphrasing the subject of this thread, no?

> So I am not sure why the RelayState I set in the default-sp is not being
> used instead, is it solely because this is an unsolicited response and for
> some reason we don't want it to use the RelayState set in the authSource?

That wouldn't make any sense as you /only/ need to supply the
RelayState yourself in the unsolicited (IDP/initiated) case. If the SP
initates, the SP will provide the RelayState.

I don't know why the RelayState parameter in your saml:SP authsource
in your SimpleSAMLphp IDP did not "work". How are you initiating the
login? According to the docs you can also add the RelayState to the
IDP-initated SSP URL, did you try that?
https://simplesamlphp.org/docs/stable/simplesamlphp-idp-more#section_4_1

Maybe there's a typo in the URL (domain or schema mismatch) that
prevents SSP from accepting the supplied value.
-peter

[Jack Meyer]

Hi,

I agree it doesn't make any sense. I tried setting the relaystate as mentioned in the documentation but that did not work. Though please realize that the IDP I am working with is not SimpleSaml, it's ADFS. The SP I have created that is receiving the IDP Initiated SSO is SimpleSaml. I used the xml metadata converter to create the entry in saml20-idp-remote.php so I believe all of that information should be correct.

I tried using a utility from Microsoft "AD FS 2.0 RelayState Generator for IDP Initiated Signon" to create the IDP url that contains the RelayState and that did not work either. I have a feeling that the version of ADFS that is on our test server doesn't have all the recent updates on it that would allow it to properly handle RelayState (according to what I found it needs Security Rollup 2 or higher, I will try to get systems to install that but I won't hold my breath. Either way, I needed a way to handle an IDP Initiation with no RelayState sent, because in real life I know that some of our clients will be in the same boat. I modified saml2-acs.php to check for an empty RelayState and if it's empty I send it to the page it needs to go to.

On another note. Many of our clients that want SSO do not allow External LDAP connections on port 389, so for SP initiated login for LDAP, I had to modify the LDAP ConfigHelper to include a private variable $port and in the constructor set it to $config->getInteger('port',389), so that I could set different LDAP ports for different IDP's via authsources.php.

Hopefully the security update will fix our testing server but only time will tell on that one. I will definitely post if that turns out to be the case.

--
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/g5_hhSxQtvE/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]

* Jack Meyer <jrm...@gmail.com> [2014-05-08 15:19]:

> I agree it doesn't make any sense. I tried setting the relaystate as
> mentioned in the documentation but that did not work. Though please realize
> that the IDP I am working with is not SimpleSaml, it's ADFS.

SimpleSAMLphp's documetation on IDP-initiated logins doesn't apply
then.

> I tried using a utility from Microsoft "AD FS 2.0 RelayState
> Generator for IDP Initiated Signon" to create the IDP url that
> contains the RelayState and that did not work either.

If you're the SP, why bother about creating RelayState for the IDP?

Whatever the institution does to make people start the session at the
IDP, people will still try to access the SP, and they will bookmark SP
resources. In which case your SP will sent RelayState to the IDP as
needed (when the IDP needs to be involved again) and the IDP is
required by the spec to return the RelayState value verbatim to the
SP.

> Either way, I needed a way to handle an IDP Initiation with no
> RelayState sent

According to the docs for the SP
https://simplesamlphp.org/docs/stable/saml:sp what you did should just
work as expected. I would suggest to file a bug report with all the
necessary details.

> On another note. Many of our clients that want SSO do not allow
> External LDAP connections on port 389, so for SP initiated login for
> LDAP, I had to modify the LDAP ConfigHelper to include a private
> variable $port and in the constructor set it to
> $config->getInteger('port',389), so that I could set different LDAP
> ports for different IDP's via authsources.php.

I have no idea what you're talking about. SAML (and IDP- or
SP-initiated is immaterial here) has nothing to do with LDAP.
And a SAML SP should have no reason to connect to anyone's LDAP except
maybe a data store of its own.
At the risk of stating the obvious: The SAML IDP should provide the
SAML SP with all the requred data in SAML attribute statements.
There simply is no need to access the IDP's LDAP DSA, as SAML has been
designed to render exactly that unnecessary.
-peter

[an...@redbullet.co.uk]

Hi Jack

I appear to have a similar issue to you. did you get to the bottom of what was causing this?

Thanks

Andy