Idp initiated logout doesnt call logout url in SP

[ikoseli]

In our current setup we have IdP with multiple SPs.

When the user logs out of IdP we send a request to:

https://[URL]/SSO/saml2/idp/SingleLogoutService.php?ReturnTo=https%3A%2F%2F[URL]

There is also a request to 

https://[URL]/SSO/module.php/core/idp/resumelogout.php?id=_b2b1c48a387e1d0afb039ae48f9cfba39bd7b

However, this doesnt send call logout URL for the SP's.

Is there a configuration step that i might have missed or do we need to code that. 

We are using our own authentication module for the IdP if that helps.

[Olav Morken]

On Wed, Jun 06, 2012 at 10:12:33 -0700, ikoseli wrote:
> In our current setup we have IdP with multiple SPs.
>
> When the user logs out of IdP we send a request to:
>

> https://[*URL*
> ]/SSO/saml2/idp/SingleLogoutService.php?ReturnTo=https%3A%2F%2F[*URL*]

>
> There is also a request to

> https://[*URL*

> ]/SSO/module.php/core/idp/resumelogout.php?id=_b2b1c48a387e1d0afb039ae48f9cfba39bd7b
>
> However, this doesnt send call logout URL for the SP's.
>
> Is there a configuration step that i might have missed or do we need to
> code that.
> We are using our own authentication module for the IdP if that helps.

It should just work, so long as you have configured SingleLogoutService
endpoints for the SPs. Also, you do not mention that you log in on any
of the SPs before you start logout on the IdP? It will only send logout
requests to the SPs that it has a session with.

Another thing is that you say "when the user logs out of the IdP". What
is meant by that? Is there a web page on the IdP where the user logs
out? Does that page by any chance delete the user's session before
redirecting to the IdP SingleLogoutService? In that case the IdP will
not have an active session for the user. (So long as your web page and
the IdP share the same session.)

Best regards,
Olav Morken
UNINETT / Feide

[ikoseli]

It should just work, so long as you have configured SingleLogoutService 
endpoints for the SPs. Also, you do not mention that you log in on any 
of the SPs before you start logout on the IdP? It will only send logout 
requests to the SPs that it has a session with. 

We have configured the SingleLogoutService endpoints for SPs. We have placed a custom authentication module that acts as IdP. There is a webpage on the IdP where the user logs out. We contact the IdP logout before the active session is deleted from the page. 

 It will only send logout requests to the SPs that it has a session with. 

The problem is since we have a custom authentication module, I am not sure where we would keep track of all the SP's that have sent us the SAML request? Do we need to account for all the SAML request and grab the entity Id such that when the user logs out of our system we use that info to log user out of the SP's?

Thank you

[Olav Morken]

On Thu, Jun 07, 2012 at 10:24:00 -0700, ikoseli wrote:
>
> >
> > It should just work, so long as you have configured SingleLogoutService
> > endpoints for the SPs. Also, you do not mention that you log in on any
> > of the SPs before you start logout on the IdP? It will only send logout
> > requests to the SPs that it has a session with.
>
>
> We have configured the SingleLogoutService endpoints for SPs. We have
> placed a custom authentication module that acts as IdP. There is a webpage
> on the IdP where the user logs out. We contact the IdP logout before the
> active session is deleted from the page.
>
> It will only send logout requests to the SPs that it has a session with.
>
>
> The problem is since we have a custom authentication module, I am not sure
> where we would keep track of all the SP's that have sent us the SAML
> request? Do we need to account for all the SAML request and grab the entity
> Id such that when the user logs out of our system we use that info to log
> user out of the SP's?

How custom is your authentication module -- are you still using the IdP
code in simpleSAMLphp to send the response? It should track the SP
sessions for you.

[ikoseli]

Yes. we are still using IdP code in simpleSAMLphp to send the response. 

however, we are not starting a new session in the custom authentication module. we are just using a cookie to validate authentication and send a response if the user is valid. 

Is the SP who has sent a SAML request supposed to be tracked in the session generated by the IdP?

Another thing I have changed is that we now store the "SP" in a table rather than the flat file. It has worked thus far.

thank you

[Olav Morken]

On Fri, Jun 08, 2012 at 06:01:47 -0700, ikoseli wrote:
> Yes. we are still using IdP code in simpleSAMLphp to send the response.

So long as the IdP sends the response, it will add the "SP association"
to its session, and later send a logout request to that SP.

> however, we are not starting a new session in the custom authentication
> module. we are just using a cookie to validate authentication and send a
> response if the user is valid.

What do you do when you receive an authentication request?

> Is the SP who has sent a SAML request supposed to be tracked in the session
> generated by the IdP?

Logout request or authentication request?

Every SP that we send a successful authentication response to is added
to the "SP association" list. When we receive a LogoutRequest from that
SP, we remove the SP from that list. (We need to do this to avoid
sending a LogoutRequest back to the SP that starts the logout.)

> Another thing I have changed is that we now store the "SP" in a table
> rather than the flat file. It has worked thus far.

Shouldn't cause this type of problem. (Unless something with the
metadata you generate from the table is incorrect. E.g. missing
SingleLogoutService endpoint.)


Have you looked at the simpleSAMLphp log? It is logged to syslog by
default. One thing to check is that the "tracking number" matches
between the lines that are logged when sending an authentication
response and the lines that are logged when processing logout. The
tracking number is the part between '[' and ']'. E.g. "[a98649ba90]".
If that number changes, it means that the logout processing is using
a new/different session than when the authentication response was sent.

[my koseli]

 | What do you do when you receive an authentication request?

We authenticate by checking a cookie and its value against internal validator. If it cookie is not present or has invalid value we redirect to a custom page that will authenticate.

Logout request or authentication request?

Authentication request

So, when the authentication request comes in we check to see if we have a valid user logged into IdP. We then redirect to custom page where the user will authenticate (another thing i might not have mentioned is since we dont have centralized idp we always execute idp initiated login) and posts a SAML response to SP.

Have you looked at the simpleSAMLphp log? It is logged to syslog by
default.

I have not configured the SimpleSAMLphp log yet. I will do so and see if there is any warning or error.

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.

To post to this group, send email to simple...@googlegroups.com.
To unsubscribe from this group, send email to simplesamlph...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simplesamlphp?hl=en.

[ikoseli]

object(SimpleSAML_Session)[14]
private 'sessionId' => string 'd8d67c071baada555' (length=32)
private 'trackid' => string '267a841' (length=10)
private 'idp' => null
private 'authenticated' => null
private 'attributes' => null
private 'sessionindex' => null
private 'nameid' => null
private 'authority' => string 'custom-auth' (length=16)
private 'sessionstarted' => null
private 'sessionduration' => null
private 'dirty' => boolean true
private 'logout_handlers' =>
array
empty
private 'dataStore' =>
array
'core:idp-ssotime' =>
array
'saml2:dev;sp_dev' =>
array
...
private 'sessionNameId' => null
private 'logoutState' => null
private 'authState' => null
private 'associations' =>
array
'saml2:dev' =>
array
'saml: sp_dev' =>
array
...
private 'authToken' => string '9b29dade0c' (length=43)
private 'authData' =>
array
'example-external' =>
array
'Attributes' =>
array
...
'AuthnInstant' => int 1339708075
'Expire' => int 1339747675

So, when the IdP initially posts a SAML response the SP is added to the association. Right after I send the response when if I do a var_dump of session in addAssociation I saw the data above related to SP

When I hit the logout url though i cannot find the place in the code where it uses the session to logout of the SP.

[my koseli]

Actually on second look when i call my IdP logout url  (https://myurl.com/sso/saml2/idp/SingleLogoutService.php) without the ReturnTo parameter I get:

Backtrace:
1 /home/bin/p/sso/1.7/www/_include.php:37 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: Exception: Unable to find the current binding.
Backtrace:
2 /home//bin/p/sso/1.7/lib/SAML2/Binding.php:80 (SAML2_Binding::getCurrentBinding)
1 /home//bin/p/sso/1.7/modules/saml/lib/IdP/SAML2.php:335 (sspmod_saml_IdP_SAML2::receiveLogoutMessage)
0 /home//bin/p/sso/1.7/www/saml2/idp/S

Could this have something to do with not being able to logout of SPs that are in "associations"?

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.

To view this discussion on the web visit https://groups.google.com/d/msg/simplesamlphp/-/F27Ps-CZm-IJ.

[Olav Morken]

On Thu, Jun 14, 2012 at 16:19:27 -0600, my koseli wrote:
> Actually on second look when i call my IdP logout url (
> https://myurl.com/sso/saml2/idp/SingleLogoutService.php) without the
> ReturnTo parameter I get:
>
> Backtrace:
> 1 /home/bin/p/sso/1.7/www/_include.php:37 (SimpleSAML_exception_handler)
> 0 [builtin] (N/A)
> Caused by: Exception: Unable to find the current binding.
> Backtrace:
> 2 /home//bin/p/sso/1.7/lib/SAML2/Binding.php:80
> (SAML2_Binding::getCurrentBinding)
> 1 /home//bin/p/sso/1.7/modules/saml/lib/IdP/SAML2.php:335
> (sspmod_saml_IdP_SAML2::receiveLogoutMessage)
> 0 /home//bin/p/sso/1.7/www/saml2/idp/S
>
> Could this have something to do with not being able to logout of SPs
> that are in "associations"?

No, this is simply your IdP complaining that it received an invalid
request. If you call SingleLogoutService without either a SAML 2.0
LogoutRequest, a SAML 2.0 LogoutResponse or a ReturnTo parameter
(indicating IdP-initiated logout), the IdP does not know what to do
with the request, and produces that error.

[my koseli]

No, this is simply your IdP complaining that it received an invalid
request. If you call SingleLogoutService without either a SAML 2.0
LogoutRequest, a SAML 2.0 LogoutResponse or a ReturnTo parameter
(indicating IdP-initiated logout), the IdP does not know what to do
with the request, and produces that error.

When the IdP initiates the logout then does it need to send a formal samlrequest to " https://myurl.com/sso/saml2/idp/SingleLogoutService.php&[SAMLREQUEST]" rather than just redirecting to url?

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.

[ikoseli]

Hi Guys,

I changed the cookiename to match the custom login however that didnt work.

One thing I noticed is that when I changed the following:

• When I change from LOG_ERR to LOG_DEBUG the IdP sends logout request to SP. However, when I switch to LOG_ERR I get error.
  
• I have also added following to metadata/saml20-idp-hosted.php
• 'logouttype' => 'traditional',
• added ReturnTo parameter to SSO Logout url
• added "default-disable" in my custom authentication module.

The problem is I am not sure why the logging level makes a difference in sending out the logout request to SP. Any idea??

When logging in

Jun 25 19:33:58 SSO DEBUG [8eb661c3de] Session: doLogin("example-ext")
Jun 25 19:33:58 SSO DEBUG [8eb661c3de] Session: Valid session found with 'example-ext'.
Jun 25 19:33:58 SSO DEBUG [8eb661c3de] Session: Valid session found with 'example-ext'.
Jun 25 19:33:58 SSO DEBUG [8eb661c3de] Filter config for dev->dev: array (  0 =>   sspmod_core_Auth_Process_LanguageAdaptor::__set_state(array(     'langattr' => 'preferredLanguage',     'priority' => 30,  )),  1 =>   sspmod_core_Auth_Process_StatisticsWithAttribute::__set_state(array(     'attribute' => 'realm',     'typeTag' => 'saml20-idp-SSO',     'priority' => 45,  )),  2 =>   sspmod_core_Auth_Process_AttributeLimit::__set_state(array(     'allowedAttributes' =>     array (    ),     'isDefault' => false,     'priority' => 50,  )),  3 =>   sspmod_core_Auth_Process_UserAdd::__set_state(array(     'replace' => false,     'attributes' =>     array (    ),     'priority' => 62,  )),  4 =>   sspmod_core_Auth_Process_LanguageAdaptor::__set_state(array(     'langattr' => 'preferredLanguage',     'priority' => 99,  )),)
Jun 25 19:33:58 SSO NOTICE STAT [8eb661c3de] saml20-idp-SSO-first dev dev NA
Jun 25 19:33:58 SSO NOTICE STAT [8eb661c3de] saml20-idp-SSO dev dev NA
Jun 25 19:33:59 SSO INFO [8eb661c3de] Sending SAML 2.0 Response to 'dev'

ON LOGOUT 

Saved state: '_7f0f44348b2f528996d2acfcbd77f'
Jun 25 19:55:41 SSO DEBUG [8eb661c3de] Session: doLogout('example-ext')

Sincerely

On Wednesday, June 20, 2012 12:07:28 PM UTC-6, Tim Henrich wrote:

I had a similar problem to this due to PHP session cookie names.  If you're using a custom login, make sure your session.phpsession.cookiename (in conf/config.php) matches what your custom login is using, otherwise it will appear as though it can't find the SP association(s) because, well, it can't.

-Tim

To unsubscribe from this group, send email to simplesamlphp+unsubscribe@googlegroups.com.

[ikoseli]

UPDATE:

So,  I removed the "default-disable" file from my module and it seems to work. I am guessing I must have everything else in place correctly.

[Olav Morken]

On Mon, Jun 25, 2012 at 20:18:51 -0700, ikoseli wrote:
> *Hi Guys,*

> I changed the cookiename to match the custom login however that didnt work.
>
> One thing I noticed is that when I changed the following:
>
>

> - When I change from *LOG_ERR* to *LOG_DEBUG* the IdP sends logout
> request to SP. However, when I switch to *LOG_ERR *I get error.
> - I have also added following to metadata/saml20-idp-hosted.php
> - 'logouttype' => 'traditional',
> - added ReturnTo parameter to SSO Logout url
> - added "*default-disable*" in my custom authentication module.
>
> *The problem is I am not sure why the logging level makes a difference in
> sending out the logout request to SP. Any idea??*

The logging level shouldn't make a difference. Have you looked at your
web server's error log (or wherever you have configured PHP to log it's
errors? It could be that some code is triggering a fatal error in PHP.

[ikoseli]

Olav and Tim,

Thank you for your patience.

I have found whats happening.

When the initial SimpleSAMLSessionID cookie is set it is set under "domain.com".

When the logout is called due to the way our system is set it tries to do so under the sub-domain "sub.domain.com" so it doesnt find the cookie set by "domain.com" and this ends up setting cookie for "sub.domain.com" instead of updating the cooking under "domain.com".

Is there a way where we can use the cookies set for the main domain when logging out? I will look at the config to see if there is a config option.

Thank you

mykoseli

[Olav Morken]

On Tue, Jul 10, 2012 at 21:16:47 -0700, ikoseli wrote:
> Olav and Tim,
> Thank you for your patience.
>
> I have found whats happening.
>

> *When the initial SimpleSAMLSessionID cookie is set it is set under
> "domain.com".*
> *When the logout is called due to the way our system is set it tries to do

> so under the sub-domain "sub.domain.com" so it doesnt find the cookie set
> by "domain.com" and this ends up setting cookie for "sub.domain.com"

> instead of updating the cooking under "domain.com".*
> *
> *
> *Is there a way where we can use the cookies set for the main domain when
> logging out? I will look at the config to see if there is a config option.*

It should use the same cookie settings both when logging in and logging
out. If that is not the case, you have something strange in your
configuration.

[Tim Henrich]

Mykoseli,

It sounds like the way you're setting your PHP session cookies may be a bit off.

Here's how I've set ours up:

This is included in our main app that also serves as our IdP:

(these should override anything in php.ini)

session_set_cookie_params(0, '/', 'domain.com', false, false);

session_name('session_name');

session_start();

simplesaml/config/config.php:
'session.phpsession.cookiename' => 'session_name'

The above settings affect both our SAML login and SingleLogoutService

Our SP on subdomain.domain.com has its own session cookie and entirely different implementation of SAML.

As long as your main PHP session cookie on domain.com is available to both your custom login and logout, I believe it should work correctly.

-Tim

[my koseli]

Hi Tim

you are exactly right. I saw that SimpleSAMLSessionID cookie was set against "www.domain.com" rather than "domain.com" and for the logout page the url was set to "www.sub.domain.com". When logout was triggered it was not able to get the cookie set against the "domain.com" so it ended up creating another cookie for "www.sub.domain.com". I changed the SessionHandlerCookie.php file in simplesaml library to set cookie against "domain.com" rather than "www.domain.com" which seems to have resolved the issue.

Does that sound ok to you guys?

thanks

mykoseli

--

You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.

To view this discussion on the web visit https://groups.google.com/d/msg/simplesamlphp/-/AL4wrdC-FikJ.

To post to this group, send email to simple...@googlegroups.com.

To unsubscribe from this group, send email to simplesamlph...@googlegroups.com.

[Tim Henrich]

Mykoseli,

I would make the necessary change in simplesaml/config/config.php instead of modifying the library itself.

-Tim

To unsubscribe from this group, send email to simplesamlphp+unsubscribe@googlegroups.com.