Logout based on cookies

380 views
Skip to first unread message

Robert Myhren

unread,
Dec 3, 2012, 7:10:11 AM12/3/12
to simple...@googlegroups.com
Hi!

I have setup simplesaml and mod_mellon with mod_proxy. Works great.
In addition to that, we have created a custom loginuserpass, which grabs a session from the backend and adds this to the users session, creating a SSO functionality.
This also works great.

However, we are experiencing problems when the session from the backend expires.
I would like to log the user out of mod_mellon and simplesaml, and force them to login again, in order to receive a new session from the backend 
I have tried to detect the missing session cookie, and redirecting to /mellon/logout?ReturnTo=/
This fails with to many redirects.

Can anybody assist me with this?

BR

Robert Myhren

Jaime Pérez Crespo

unread,
Dec 14, 2012, 9:28:13 AM12/14/12
to simple...@googlegroups.com
Hi Robert,

Could you please describe a little bit further the architecture you have deployed, and how do you want to implement this logout? I understand that you are using SSP as an intermediary to some other web technology (that you call the backend) based on cookies, but still I'm a bit uncertain.

Regards,

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

--
Jaime Pérez
UNINETT / Feide

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

Robert Myhren

unread,
Feb 18, 2013, 8:58:57 AM2/18/13
to simple...@googlegroups.com
Hi!

Sorry for the slooow reply.

I use  mod_mellon in order to protect the backend server from unauthorized access. 

A sort of SSO against the backend server is done by authenticating the user using curl and forwarding this session to the user / client. I have modified the basicuserpass module to achieve this.  

This works OK, but when the session from the backend expires before the session from mod_mellon, problems arise. So I would like to detect that the session from the backend has expiered, and force a logout from mod_mellon.

So the question is; what is the best way to do this?

The backend servers are SAP.

I realize that this question might belong to the mod_mellon mailinglist, but hopefully someone here will



2012/12/14 Jaime Pérez Crespo <jaime...@uninett.no>

Jaime Pérez Crespo

unread,
Feb 19, 2013, 7:33:46 AM2/19/13
to simple...@googlegroups.com
Hi Robert,

On Feb 18, 2013, at 14:58 PM, Robert Myhren <rob...@basis-consulting.com> wrote:
Hi!

Sorry for the slooow reply.

I use  mod_mellon in order to protect the backend server from unauthorized access. 

A sort of SSO against the backend server is done by authenticating the user using curl and forwarding this session to the user / client. I have modified the basicuserpass module to achieve this.  

This works OK, but when the session from the backend expires before the session from mod_mellon, problems arise. So I would like to detect that the session from the backend has expiered, and force a logout from mod_mellon.

To be honest I still don't get what you are doing exactly. My guess is:

- You have a SAP server (what you call backend) that provides the user base (that is, it's the one who is able to authenticate users).
- You also have a proxy server to allow access to the SAP server(s). Access to the proxy itself is controlled by mod_mellon.
- mod_mellon is connected to a simpleSAMLphp IdP for authentication.
- The simpleSAMLphp IdP performs login/pass authentication by forwarding the credentials to the SAP server in a backchannel, getting a session from it.

Is this correct? I also understand that you have multiple SAP servers, and what you call a "session from the backend" is a logon ticket that allows SSO among all the SAP servers.

So the question is; what is the best way to do this?

The backend servers are SAP.

I realize that this question might belong to the mod_mellon mailinglist, but hopefully someone here will

I think there's several ways to achieve this. The first one could be lowering down the session timeout at the IdP (SSP) and mod_mellon, making them re-authenticate often, so that you can check again the session from the backend and see if it's still valid.

Another way would be to gather the backend's session lifetime somehow in your custom module, and make SSP issue its own session with the same expiration time.

But of course all of this depends on my previous assumptions being correct...

Robert Myhren

unread,
Feb 20, 2013, 3:37:14 AM2/20/13
to simple...@googlegroups.com
You are spot on:)


2013/2/19 Jaime Pérez Crespo <jaime...@uninett.no>

Hi Robert,

On Feb 18, 2013, at 14:58 PM, Robert Myhren <rob...@basis-consulting.com> wrote:
Hi!

Sorry for the slooow reply.

I use  mod_mellon in order to protect the backend server from unauthorized access. 

A sort of SSO against the backend server is done by authenticating the user using curl and forwarding this session to the user / client. I have modified the basicuserpass module to achieve this.  

This works OK, but when the session from the backend expires before the session from mod_mellon, problems arise. So I would like to detect that the session from the backend has expiered, and force a logout from mod_mellon.

To be honest I still don't get what you are doing exactly. My guess is:

- You have a SAP server (what you call backend) that provides the user base (that is, it's the one who is able to authenticate users).
- You also have a proxy server to allow access to the SAP server(s). Access to the proxy itself is controlled by mod_mellon.
- mod_mellon is connected to a simpleSAMLphp IdP for authentication.
- The simpleSAMLphp IdP performs login/pass authentication by forwarding the credentials to the SAP server in a backchannel, getting a session from it.
Correct, a curl session with credentials is sent to the backend 

Is this correct? I also understand that you have multiple SAP servers, and what you call a "session from the backend" is a logon ticket that allows SSO among all the SAP servers.

Correct, the logon ticket is called MYSAPSSO2 and contains the login information. 

So the question is; what is the best way to do this?

The backend servers are SAP.

I realize that this question might belong to the mod_mellon mailinglist, but hopefully someone here will

I think there's several ways to achieve this. The first one could be lowering down the session timeout at the IdP (SSP) and mod_mellon, making them re-authenticate often, so that you can check again the session from the backend and see if it's still valid.
Yes, but this is killing usablility.
 
Another way would be to gather the backend's session lifetime somehow in your custom module, and make SSP issue its own session with the same expiration time.
Could be a solution.
But is it not possible to check for either errorcodes related to a no session situation, or the absent of a session cookie?

I have tried the following:
        RewriteCond %{REQUEST_URI} !^/(simplesamlphp|mellon/.*)$
        RewriteCond %{HTTP_COOKIE} !^MYSAPSSO2$
        RewriteRule  ^/(.*)        /mellon/logout?ReturnTo=/logged_out.html  [R] 

In the absent of MYSAPSSO2 (session cookie), redirect to logout.
No working as I would like it to...

But of course all of this depends on my previous assumptions being correct...
They are:)

--
Jaime Pérez
UNINETT / Feide

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

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.

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

Jaime Pérez Crespo

unread,
Feb 20, 2013, 7:23:58 AM2/20/13
to simple...@googlegroups.com
Hi,

On Feb 20, 2013, at 09:37 AM, Robert Myhren <rob...@basis-consulting.com> wrote:
You are spot on:)

Good, I'm not getting as older as I thought :-)

I think there's several ways to achieve this. The first one could be lowering down the session timeout at the IdP (SSP) and mod_mellon, making them re-authenticate often, so that you can check again the session from the backend and see if it's still valid.
Yes, but this is killing usablility.

Yes, unless you implement a mechanism in your authentication source that checks the validity of the session you got from the backend, and establishes a new IdP session if the other one is still valid.

Another way would be to gather the backend's session lifetime somehow in your custom module, and make SSP issue its own session with the same expiration time.
Could be a solution.
But is it not possible to check for either errorcodes related to a no session situation, or the absent of a session cookie?

Well, I guess the expiration of the "backend session" is tied to the expiration of that 'MYSAPSSO2' cookie, right? Then, as long as you reach your custom auth source, and there's no such cookie, you can show the form and start a fresh authentication through the SAP back channel. And the same applies if you try to decode the 'MYSAPSSO2' cookie and you find any kind of error there.

I have tried the following:
        RewriteCond %{REQUEST_URI} !^/(simplesamlphp|mellon/.*)$
        RewriteCond %{HTTP_COOKIE} !^MYSAPSSO2$
        RewriteRule  ^/(.*)        /mellon/logout?ReturnTo=/logged_out.html  [R] 

In the absent of MYSAPSSO2 (session cookie), redirect to logout.
No working as I would like it to...

That's strange. What's the behavior you are experiencing with that? Can you trace that you are actually performing a logout request to the SSP IdP and the session there (and also in mod_mellon) is being removed?

Robert Myhren

unread,
Feb 20, 2013, 9:44:58 AM2/20/13
to simple...@googlegroups.com
An endless loop. 302.
This is due to a logical error that I am not able to get around.
But I bet its simple once I see it...:)

The problem is that, once logged out, the client is redirected once again due to the lack of MYSAPSSO2 while still outside /simplesamlphp|/mellon.
So the problem is not getting logged out, but avoid continuing being logged out once logged out:)
And my brain is stuck....

I would like to avoid the other options as long as I can, and to the checks outside SAP

Robert

  




2013/2/20 Jaime Pérez Crespo <jaime...@uninett.no>

Jaime Pérez Crespo

unread,
Feb 20, 2013, 9:53:00 AM2/20/13
to simple...@googlegroups.com
Hi,

On Feb 20, 2013, at 15:44 PM, Robert Myhren <rob...@basis-consulting.com> wrote:
An endless loop. 302.
This is due to a logical error that I am not able to get around.
But I bet its simple once I see it...:)

The problem is that, once logged out, the client is redirected once again due to the lack of MYSAPSSO2 while still outside /simplesamlphp|/mellon.
So the problem is not getting logged out, but avoid continuing being logged out once logged out:)
And my brain is stuck....

Yep, that makes sense. I guess the first time (when you first access the proxy) it works since you are automatically redirected to the IdP, but when the session expires that's a problem because you end up in a static page saying you've been logged out, and then the automatic redirection you have in the proxy starts the loop.

Maybe you can try to set a cookie in addition to triggering the logout, so the condition to logout would be having none of both cookies, the MYSAPSSO2 and the new one.

But of course that's just theory and also a quite dirty solution...

I would like to avoid the other options as long as I can, and to the checks outside SAP

I think the best thing you can do is modify your auth source in the IdP so that the duration of the SAML session (in the IdP and the SP) is tied to the duration of the MYSAPSSO2 session, if you can decode it somehow.

You could also try to redirect back to a static page once you've been logged out, that's out of the zone protected by mod_mellon and the mod_rewrite directives, I guess...
Reply all
Reply to author
Forward
0 new messages