Single Sign Out - State Lost

[doll...@gmail.com]

I have finally achieved a working proof of concept for SSO for multiple wordpress sites, using a 3rd party Auth resource with SimpleSamlPHP IDP.

The last problem I have is Single Sign Out / SSO. When I logout of WordPress, I get a simplesamlphp error:

SimpleSAML_Error_NoState: NOSTATE

Backtrace:
2 /home/jonesde/simplesamlphp/lib/SimpleSAML/Auth/State.php:263 (SimpleSAML_Auth_State::loadState)
1 /home/jonesde/simplesamlphp/modules/core/www/idp/resumelogout.php:6 (require)
0 /home/jonesde/public_html/saml/simplesaml/module.php:137 (N/A)

However, when I simply type in the URL again of the wordpress site, and hit logout once again, it works fine ( successfully logs the user out of both the local WP site and simplesaml ).

I have done some troubleshooting according to this document:

https://simplesamlphp.org/docs/stable/simplesamlphp-nostate

However, I am so new to this that I think I'm just not technically able to identify the problem.

The only thing I suspect is that the site domain is not secure, and my saml server is.. so:

Wordpress:

http://dev.domain1.com

and Saml install:

https://saml.domain2.com

I thought that may be the culprit, however, I don't know how to test that really, and I don't know if that is the problem at all. I am stuck on why it works a second time and just not the first.

TIA for comments,

Donovan

[doll...@gmail.com]

Okay, I've enabled logging. Here is my first request for SLO:

(note, I have changed to generic domains below)

----------

Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652] Saved state: '_2ccd004bfcfe6fe51567ec8c08137c477ce88388b2'
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652] Session: Valid session found with 'ddb-sfgauth'.
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652] Session: doLogout('ddb-sfgauth')
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652] Session: 'ddb-sfgauth' not valid because we are not authenticated.
Aug 27 15:34:22 simplesamlphp INFO [6dcc816652] SAML2.0 - IdP.SingleLogoutService: Accessing SAML 2.0 IdP endpoint SingleLogoutService
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652] Received message:
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652] <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_771844ef5dd5a9ff8f1d432ae0694bd97713f112" Version="2.0" IssueInstant="2017-08-27T20:34:21Z" Destination="https://saml.idpdomain.com/simplesaml/saml2/idp/SingleLogoutService.php">
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652]   <saml:Issuer>php-saml</saml:Issuer>
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652]   <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ff6f8eee2bfa0f9506633b86210f66c9487ae0aa75</saml:NameID>
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652]   <samlp:SessionIndex>_eec945de96a3db800a5acf19d0fe614a653482826d</samlp:SessionIndex>
Aug 27 15:34:22 simplesamlphp DEBUG [6dcc816652] </samlp:LogoutRequest>
Aug 27 15:34:22 simplesamlphp INFO [6dcc816652] Received SAML 2.0 LogoutRequest from: 'php-saml'
Aug 27 15:34:22 simplesamlphp NOTICE STAT [6dcc816652] saml20-idp-SLO spinit php-saml https://saml.idpdomain.com/simplesaml/saml2/idp/metadata.php
Aug 27 15:34:22 simplesamlphp ERROR [5f5aa19ec9] SimpleSAML_Error_NoState: NOSTATE
Aug 27 15:34:22 simplesamlphp ERROR [5f5aa19ec9] Backtrace:
Aug 27 15:34:22 simplesamlphp ERROR [5f5aa19ec9] 2 /home/jonesde/simplesamlphp/lib/SimpleSAML/Auth/State.php:263 (SimpleSAML_Auth_State::loadState)
Aug 27 15:34:22 simplesamlphp ERROR [5f5aa19ec9] 1 /home/jonesde/simplesamlphp/modules/core/www/idp/resumelogout.php:6 (require)
Aug 27 15:34:22 simplesamlphp ERROR [5f5aa19ec9] 0 /home/jonesde/public_html/saml/simplesaml/module.php:137 (N/A)
Aug 27 15:34:22 simplesamlphp ERROR [5f5aa19ec9] Error report with id f418e294 generated.
Aug 27 15:34:22 simplesamlphp DEBUG [5f5aa19ec9] Template: Reading [/home/jonesde/simplesamlphp/dictionaries/errors]
Aug 27 15:34:22 simplesamlphp DEBUG [5f5aa19ec9] Template: Reading [/home/jonesde/simplesamlphp/modules/core/dictionaries/no_state]
Aug 27 15:34:22 simplesamlphp DEBUG [5f5aa19ec9] Loading state: '_2ccd004bfcfe6fe51567ec8c08137c477ce88388b2'
----------------------------


Here is the second (successful request):
----------------------------
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9] Saved state: '_0dc8011f799b9bdb0528e65be2dab60f2d7cb5325b'
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9] Session: 'ddb-sfgauth' not valid because we are not authenticated.
Aug 27 15:38:24 simplesamlphp INFO [5f5aa19ec9] SAML2.0 - IdP.SingleLogoutService: Accessing SAML 2.0 IdP endpoint SingleLogoutService
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9] Received message:
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9] <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_1f2b058c51fc189928ad78c92b19fe64aab2251c" Version="2.0" IssueInstant="2017-08-27T20:38:24Z" Destination="https://saml.idpdomain.com/simplesaml/saml2/idp/SingleLogoutService.php">
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9]   <saml:Issuer>php-saml</saml:Issuer>
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9]   <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ff6f8eee2bfa0f9506633b86210f66c9487ae0aa75</saml:NameID>
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9]   <samlp:SessionIndex>_eec945de96a3db800a5acf19d0fe614a653482826d</samlp:SessionIndex>
Aug 27 15:38:24 simplesamlphp DEBUG [5f5aa19ec9] </samlp:LogoutRequest>
Aug 27 15:38:24 simplesamlphp INFO [5f5aa19ec9] Received SAML 2.0 LogoutRequest from: 'php-saml'
Aug 27 15:38:24 simplesamlphp NOTICE STAT [5f5aa19ec9] saml20-idp-SLO spinit php-saml https://saml.idpdomain.com/simplesaml/saml2/idp/metadata.php
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9] Sending logout response to SP 'php-saml'
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9] Sending message:
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9] <samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_9ffedb5820126fde3697ad1a7d185c270962e33ccb" Version="2.0" IssueInstant="2017-08-27T20:38:25Z" Destination="http://dev.spdomain.com/wp-login.php?saml_sls" InResponseTo="ONELOGIN_1f2b058c51fc189928ad78c92b19fe64aab2251c">
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9]   <saml:Issuer>https://saml.idpdomain.com/simplesaml/saml2/idp/metadata.php</saml:Issuer>
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9]   <samlp:Status>
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9]     <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9]   </samlp:Status>
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9] </samlp:LogoutResponse>
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9] Redirect to 610 byte URL: http://dev.spdomain.com/wp-login.php?saml_sls&SAMLResponse=fZLdTuMwEIVfJfJ9k9glTWK1RQjQqlIBaYu44Kaa2JPWyLGtjLOs9uk3CUKAhLicn%2FPNsWfWBJ0Ncu9Pfoi%2FkYJ3hMnfzjqSc2nDht5JD2RIOuiQZFTycHW3lyLNZeh99Mpb9knyswKIsI%2FGO5bsbjbsWLct6qaoRM7FqtW4XNUlaA6l5lWhRJnXK4HLpVINS56wp1G5YSNolBMNuHMUwcUxlfNykVcLUT6KXC4rKYpnltwgReMgzqpzjEFmmcY%2FqfbWUgcn%2BGccpsp32WtYWH8yLg3ncDk940iWxiHu%2FVMe%2FYY93N%2FuH37t7o%2B8FU1eVKrgreJVXYsKdFmpWjS8bnF1AdAIUXDFtuuJJWev%2FXZyQKOFKZe%2BeDeih8YaOht3ml2Q6YLFqTz3iMzokHUYQUOEydo6%2B8xbv23vECEO9DW69hqTJ7AD%2FrwPmrvlYVAKiVi2fZvwAc2%2Bu5Dtfw%3D%3D&RelayState=http%3A%2F%2Fdev.spdomain.comarray (
)
Aug 27 15:38:25 simplesamlphp DEBUG [5f5aa19ec9] Loading state: '_0dc8011f799b9bdb0528e65be2dab60f2d7cb5325b'

--------------------------------------

It looks like the problem is in this step:
Aug 27 15:34:22 simplesamlphp NOTICE STAT [6dcc816652] saml20-idp-SLO spinit php-saml https://saml.idpdomain.com/simplesaml/saml2/idp/metadata.php
Aug 27 15:34:22 simplesamlphp ERROR [5f5aa19ec9] SimpleSAML_Error_NoState: NOSTATE

took a look at the metadata.php and am not sure why I'm losing the state.

[Jaime Perez Crespo]

Hi Donovan,

The second request is not working either. It’s just that the session is invalid already, then SimpleSAMLphp is nice enough to just send a response back instead of displaying an error, so that things don’t break.

In any case, it’s quite difficult to know what could be happening without any more information about your configuration, the overall setup, etc. Take a look at these:

https://simplesamlphp.org/docs/stable/simplesamlphp-nostate

https://github.com/simplesamlphp/simplesamlphp/wiki/State-Information-Lost

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[doll...@gmail.com]

Hi Jamie, I guess it is interesting to know that it is not working the second time either.. though the end-result to the user appears as if it is.

I'm at a loss on where to look where the problem is. I'm playing around with session cookies, but just don't know what I'm doing, or rather, don't know where to start.

[doll...@gmail.com]

I finally figured this out. I hope this helps someone save days of troubleshooting.

In the custom auth module I created based off the SSP example, in path: > lib > Auth > Source > External.php

I had:
session_unset();
session_destroy();

session_destroy was the problem.

It works as it should now using only session_unset();

[Jaime Perez Crespo]

Hi Donovan,

On 5 Sep 2017, at 19:34 PM, doll...@gmail.com wrote:
> I finally figured this out. I hope this helps someone save days of troubleshooting.
>
> In the custom auth module I created based off the SSP example, in path: > lib > Auth > Source > External.php
>
> I had:
> session_unset();
> session_destroy();
>
> session_destroy was the problem.

Thanks for the feedback.

You shouldn’t be using the session_*() functions directly. Instead, you should use the SimpleSAML_Session class. How are you authenticating the user?

[doll...@gmail.com]

On Thursday, September 7, 2017 at 3:49:34 AM UTC-5, Jaime Pérez wrote:

Hi Donovan,

On 5 Sep 2017, at 19:34 PM, doll...@gmail.com wrote:
> I finally figured this out. I hope this helps someone save days of troubleshooting.
>
> In the custom auth module I created based off the SSP example, in path: > lib > Auth > Source > External.php
>
> I had:
> session_unset();
> session_destroy();
>
> session_destroy was the problem.

Thanks for the feedback.

You shouldn’t be using the session_*() functions directly. Instead, you should use the SimpleSAML_Session class. How are you authenticating the user?

Hi Jamie, The simplesamlphp example auth itself uses those functions...

exampleauth > lib > Auth > Source > External.php

line 253, function logout().

For auth, I'm populating PHP's SESSION, then writing the attributes from that.

Donovan

[Jaime Perez Crespo]

Hi again,

On 8 Sep 2017, at 16:19 PM, doll...@gmail.com wrote:
> Hi Jamie,

It’s Jaime, btw, Spanish name :-)

> The simplesamlphp example auth itself uses those functions…

> exampleauth > lib > Auth > Source > External.php
> line 253, function logout().

Uhm, I don’t see session_unset() or session_destroy() used there. Can you share the example code you are following?

> For auth, I'm populating PHP's SESSION, then writing the attributes from that.

So, you mean the user already has a valid PHP session in place and you are just using it? How is that session created, out of curiosity?

In any case, I don’t think it’s easy to do that out of the box, unless SimpleSAMLphp is using a session backend other than PHP (that is, memcache, SQL, or something else). If you want to use external PHP sessions to authenticate, but at the same time have SimpleSAMLphp use the PHP session handler, you’ll need to commit SSP’s session, close it, load the session where you get authentication status from, save what you need in local variables, commit, close, and load SSP’s session again.

Not very convenient, I know, but...

[doll...@gmail.com]

Jaime,
You said:
'You shouldn’t be using the session_*()'.

My comments point was that the examples use many of those functions.

Anyway, can I be honest here?? I appreciate your responses today.. but in the many days I spent on this, I had basically no help and was left to figure it out on my own (which I did). I realize that nobody is required to give support here, but I think new users could really use better help on this forum (to make SSP a success).. just my opinion.

Regarding php sessions and their related functions.. if we are not supposed to use them, then perhaps the examples should not use them. Ultimately, my Auth and my install of SimpleSAMLphp works now. My Auth is very much like the example:External. 

My latest question had to do with SSO. It appears that SSP needs the session set to be able to finish logout (without throwing a "no state" error)... So, answer: don't use session_destroy() in the logout function, but feel free to empty the array (session_unset()).

Sincerely,
Donovan

[Jaime Perez Crespo]

Hi Donovan!

On 8 Sep 2017, at 20:56 PM, doll...@gmail.com wrote:
> Jaime,
> You said:
> 'You shouldn’t be using the session_*()'.
>
> My comments point was that the examples use many of those functions.
>
> Anyway, can I be honest here?? I appreciate your responses today.. but in the many days I spent on this, I had basically no help and was left to figure it out on my own (which I did). I realize that nobody is required to give support here, but I think new users could really use better help on this forum (to make SSP a success).. just my opinion.

First of all, I appreciate your opinion. But you need to take into account too that this is an open source project, with particularly low resources, and as such both development and support here is always “best effort”. Every hour I spend answering questions here is an hour of my workday that I don’t get to spend on actually making the project better for everyone by fixing bugs or developing it further. Currently, we have 113 issues and 46 pull requests pending, that without taking into account the SAML2 library.

I know support could be much better, as well as our responsiveness regarding issues and pull requests, as well as the development of the software in general. However, everything here (the software and user support) is given for free. We simply cannot afford giving full professional support to every user who pops up here, much less doing so for free. Remember that we publish a list of companies offering paid support on our website, in case you feel like you need better support than the best effort offered here.

You also need to take into account that your use case is a pretty uncommon case. You are not just using the software, you are extending it and customizing it, and as such you are supposed to know what you are doing. Your problems were much beyond what’s common user support, including your own use case and your own code. So in that case we can offer you guidance, but we can’t just point to a line in a code that doesn’t belong to the software and say: “there’s the error”. We’ll try our best to help, but if you are doing your own authentication source, you are pretty much on your own, and you should have knowledge enough to debug the issues yourself (as you did).

> Regarding php sessions and their related functions.. if we are not supposed to use them, then perhaps the examples should not use them.

That’s a good point.

That’s just an example, though, but definitely outdated. The way the PHP session handler works was slightly changed recently, so that SimpleSAMLphp sessions are kept apart from any other existing sessions. If you want to use the PHP session handler *and* other PHP sessions at the same time, then the example will just not work. In any case, as you may understand, it’s absolute impossible in practice to keep track of all documentation, examples and resources that we have in place every time we change something. We can’t just have everything in our heads, and this is a good example of that problem. Given that it is just an example, it’s not a surprise to me that it went unnoticed.

> Ultimately, my Auth and my install of SimpleSAMLphp works now. My Auth is very much like the example:External.

I’m glad to hear that.

> My latest question had to do with SSO. It appears that SSP needs the session set to be able to finish logout (without throwing a "no state" error)... So, answer: don't use session_destroy() in the logout function, but feel free to empty the array (session_unset()).

It doesn’t need to be set (as in available via $_SESSION), but it needs to exist (be there stored in the backend). Obviously, if the SimpleSAMLphp session is gone, there’s no way for the software to know who are you and where are you supposed to be logged out from. If you use session_destroy(), well, that literally destroys the session, making it impossible for SimpleSAMLphp to recover it later, and leading to missing state errors when trying to logout. If, on the other hand, you use session_unset(), the $_SESSION variable is unset but the session is not destroyed, so you don’t affect SSP’s session. Remember also that SSP needs to have its own session completely separate from any other, so if you are looking for a particular session where to find authentication status, that *shouldn't* be SSP’s session. Since calling session_destroy() destroys SSP’s session, you are likely doing it wrong. You should commit & close the existing session (SSP’s), load the one where authentication status should be available (using named sessions), and then you can destroy it safely if you wish.

—

[doll...@gmail.com]

Understood Jaime. My vent was more a wish from a new user perspective. I've worked in a position perhaps similar to yours before and understand the difficulties. Thanks for the comments.

It doesn’t need to be set (as in available via $_SESSION), but it needs to exist (be there stored in the backend). Obviously, if the SimpleSAMLphp session is gone, there’s no way for the software to know who are you and where are you supposed to be logged out from. If you use session_destroy(), well, that literally destroys the session, making it impossible for SimpleSAMLphp to recover it later, and leading to missing state errors when trying to logout. If, on the other hand, you use session_unset(), the $_SESSION variable is unset but the session is not destroyed, so you don’t affect SSP’s session.

Right.

 

Remember also that SSP needs to have its own session completely separate from any other, so if you are looking for a particular session where to find authentication status, that *shouldn't* be SSP’s session. Since calling session_destroy() destroys SSP’s session, you are likely doing it wrong. You should commit & close the existing session (SSP’s), load the one where authentication status should be available (using named sessions), and then you can destroy it safely if you wish.

Well, I'm not sure I understand what you are saying exactly here, but I believe I am in compliance with what you are saying. I am not overwriting or messing with any of the existing SSP session values. I am simply adding an array of attributes (with a unique prefix) to it (from my user / group database of authority).. so, something like:

$newdata = array(
    'auth_userid' => $aReturn['subscriberinfo']['saml_userid'],
    'auth_customer_num' => $aReturn['subscriberinfo']['saml_customer_num'],
    'auth_username' => $aReturn['subscriberinfo']['saml_username'],
    'auth_password' => $aReturn['subscriberinfo']['saml_password'],
    'auth_group' => $aReturn['subscriberinfo']['saml_group'],
    'auth_brandcodes' => $aReturn['subscriberinfo']['saml_brandcodes'],
    'auth_status' => $aReturn['subscriberinfo']['saml_status'],
    'auth_sub_expire' => $aReturn['subscriberinfo']['saml_sub_expire'],
    'auth_firstname' => $aReturn['subscriberinfo']['saml_firstname'],
    'auth_lastname' => $aReturn['subscriberinfo']['saml_lastname'],
    'auth_zip' => $aReturn['subscriberinfo']['saml_zip'],
    'auth_phone' => $aReturn['subscriberinfo']['saml_phone'],
    'auth_email' => $aReturn['subscriberinfo']['saml_email'],
    'auth_lastlogin_dt' => date('Y-m-d H:i:s'),
    'auth_lastmodified_dt' => date('Y-m-d H:i:s'),
    'auth_lastmodby' => "login",
    'auth_verify_code' => $aReturn['subscriberinfo']['saml_verifycode'],
    'auth_verified' => $aReturn['subscriberinfo']['saml_verified'],
    'auth_verified_dt' => $aReturn['subscriberinfo']['saml_verified_dt'],
    'auth_name' => $vname
);

// set above info to $_SESSION
if( !isset( $_SESSION ) ) {
    session_start();
}

foreach($newdata as $key => $value) {
    $_SESSION[$key] = $value;
}

Seems to be working well so far.

Donovan

[Peter Schober]

* doll...@gmail.com <doll...@gmail.com> [2017-09-08 20:56]:

> I realize that nobody is required to give support here, but I think
> new users could really use better help on this forum (to make SSP a
> success).. just my opinion.

That's easy to agree with.
Suggestions on how to achieve always welcome.

Those who know the answers to your problems and do not contribute them
(assuming any even exist; Jaime already explained why your problem is
not the universal case) are somewhat unlikely to do so only because
you think it would help you.
But I guess one can only ask and remind others that community support
without a community of people providing support isn't all that much.

You can leave out the "to make SSP a success" part, though. There's no
universl measure what consistutes success (and likely SSP has long
achieved it) and people won't be pressured into providing support here
only because you say the project won't be successful otherwise.

-peter

[Jaime Perez Crespo]

Hi again!

On 12 Sep 2017, at 17:17 PM, doll...@gmail.com wrote:
> Understood Jaime. My vent was more a wish from a new user perspective. I've worked in a position perhaps similar to yours before and understand the difficulties. Thanks for the comments.
>

>> Remember also that SSP needs to have its own session completely separate from any other, so if you are looking for a particular session where to find authentication status, that *shouldn't* be SSP’s session. Since calling session_destroy() destroys SSP’s session, you are likely doing it wrong. You should commit & close the existing session (SSP’s), load the one where authentication status should be available (using named sessions), and then you can destroy it safely if you wish.
>
> Well, I'm not sure I understand what you are saying exactly here, but I believe I am in compliance with what you are saying. I am not overwriting or messing with any of the existing SSP session values. I am simply adding an array of attributes (with a unique prefix) to it (from my user / group database of authority).. so, something like:

No, unless you are closing SSP’s session and opening a new one before that. What I’m trying to say is: SimpleSAMLphp must have its own session (its own object in the backend storage, its own cookie with a different session name, its own session ID), and you should never use that session directly. If you are reusing that session to store all the data you enumerate, then SSP’s session is not independent. When you get called in your auth source, SSP must have initialized a session already, and that session will be available in the $_SESSION superglobal. Before you check for that data you enumerate (or before adding it to the $_SESSION variable), you need to close the session, and open a different one that holds the authentication info.

In the end, there’s a very simple way to find out if you are doing it right or not. How many cookies you have in your IdP? One or two? If you have two, SSP’s one and the one you use to authenticate the user (that also contains the data you describe), then you are doing it right.

Hope that clarifies a bit my previous explanation :-)

--

[doll...@gmail.com]

Hi Jaime, I'm taking the time to try and understand here.

I have two session cookies (it appears) at the IDP level:
SimpleSAML
and
SimpleSAMLAuthToken

In my config.php, I have these related things set:

/*
 * Option to override the default settings for the session cookie name
 */
'session.cookie.name' => 'SimpleSAMLSessionID',

/*
 * Options to override the default settings for php sessions.
 */
'session.phpsession.cookiename' => 'SimpleSAML',
'session.phpsession.savepath' => null,
'session.phpsession.httponly' => true,

/*
 * Option to override the default settings for the auth token cookie
 */
'session.authtoken.cookiename' => 'SimpleSAMLAuthToken',

Not sure why I'm not seeing a 'SimpleSAMLSessionID' cookie in my browser.

Anyway, thanks. I'm cautious to make changes, because things seem to be working.. but I do want to understand things better and do want to make sure I'm doing it right.

Donovan

[siri...@gmail.com]

Kind of an old post, but the explicit code you must call before you modify your own session is:

$session = SimpleSAML_Session::getSessionFromRequest();
$session->cleanup();

This returns you back to your own session. Then you can call:

session_unset();
session_destroy();

If you call session_unset() without those two lines you're unsetting the SimpleSAMLphp session, not yours. (And calling session_destroy() just destroyed their session which is a bad idea and will cause all kinds of problems). Anytime you call a SimpleSAMLphp command it replaces your session with their own, so remember if you want to then modify your own session you must cleanup first.