Trouble retrieving the original session - 'default-sp' not valid because we are not authenticated

[Akin]

Having some trouble with an SSO app that I'm writing where I try to retrieve the SAML session so that I can pull the user's attributes.  However, when the user is redirected to my script, the user is again redirected to the IdP discovery page.

Basically a user authentications with the client's IdP,   My SP receives the response the redirects the user to my SSO script.

In my script I try to create a session:

$saml_config = SimpleSAML_Configuration::getInstance();
$saml_session = SimpleSAML_Session::getInstance();
$valid_saml_session = $saml_session->isValid(DEFAULT_SP);

However isValid() return false.

And when the code gets down to

$as->requireAuth(array('ReturnTo' => $return_to, 'ErrorURL' => $error_url));
$saml_attributes = $as->getAttributes();

When I look at the logs I see:

Received message:
...(xml document)
Received SAML2 Response from 'https://idp.client.com'.
Has 1 candidate keys for validation.
Validation with key #0 succeeded.
Has 1 candidate keys for validation.
Validation with key #0 succeeded.
 ...(array)
Session: doLogin("default-sp")
Session: 'default-sp' not valid because we are not authenticated.
Session: 'default-sp' not valid because we are not authenticated.
Saved state: '_593f2a7e5ecc7e9df0c6cc84fe0bc922b5160b4a76:https://sp.ssowebapp.com/simplesamlphp_test/module.php/core/as_login.php?AuthId=default-sp&ReturnTo=https://sp.ssowebapp.com/sandbox/auth/saml/index.php'
idpDisco.saml: Accessing discovery service.
idpDisco.saml: returnIdParam initially set to [idpentityid]
idpDisco.saml: isPassive initially set to [FALSE]
idpDisco.saml: getSelectedIdP() returned NULL
Template: Reading [/usr/share/simplesamlphp/dictionaries/disco]
Template: Adding inline language translation for tag [idpname_https://openidp.feide.no]
Template: Adding inline language translation for tag [idpdesc_https://openidp.feide.no]
Template: Looking up [idpname_https://idp.client.com]: not translated at all.

The user is redirected to the my SP's IdP discovery page that lists the IdP in a drop down.

I've been reading that this issue may be caused by the cookie domain not being set.  So in my SP's config.php I set:

 'session.cookie.domain' => '.sp.ssowebapp.com'

Essentially what I would like to happen is that my web app retrieve the session that my SP created and pull the user's attributes and authenticate the user into my application.

Any ideas as to what else I should check to diagnose this problem?

Thanks

[Jaime Pérez Crespo]

Hi,

On 13 Jun 2014, at 19:13 pm, Akin <akin...@gmail.com> wrote:
> Having some trouble with an SSO app that I'm writing where I try to retrieve the SAML session so that I can pull the user's attributes. However, when the user is redirected to my script, the user is again redirected to the IdP discovery page.
>
> Basically a user authentications with the client's IdP, My SP receives the response the redirects the user to my SSO script.
>
> In my script I try to create a session:
>
> $saml_config = SimpleSAML_Configuration::getInstance();
> $saml_session = SimpleSAML_Session::getInstance();
> $valid_saml_session = $saml_session->isValid(DEFAULT_SP);

Why are you doing that? You shouldn’t handle SimpleSAMLphp’s session manually. Please follow this instructions:

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

Besides, where is this DEFAULT_SP constant coming from? Something you defined? Does it contain a string with the name of your authsource?

> However isValid() return false.
>
> And when the code gets down to
>
> $as->requireAuth(array('ReturnTo' => $return_to, 'ErrorURL' => $error_url));

Actually requireAuth() does exactly what you are trying to do with the call to isValid(). It will check if the user is already authenticated and return immediately if that’s the case. Apart from that, why are you passing the ReturnTo and ErrorURL parameters? Where does the $return_to variable point to?

Why do you want that? What you would normally want is that SimpleSAMLphp handles authentication for you transparently, and then use the attributes you get from it to discern which local user has authenticated and load the appropriate local session. Also bear in mind that you don’t need to “authenticate” the user into your application, and actually you can’t do that. You just identify him, and trust a third party (the IdP) to have properly verified the claimed identity.

> Any ideas as to what else I should check to diagnose this problem?

Follow the integration guide to use the normal API, and try again. If it still doesn’t work or you need something esoteric that is not covered by the common API, then ask here and we’ll try to figure out.

--
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