Forcing logout with NativeSP

[Stephen Chan]

Hi,
I'm working on shibboleth integration for a CMS we run and wanted
to get some suggestions for the best way to proceed.

There are 2 URL's used by the CMS to handle login and login,
/Security/login and /Security/logout. Using the native SP it is
straightforward to put a Shibboleth auth-type setting on
/Security/login and have all the appropriate attributes available to
be read by the web app.

The part that I would like advice on is how to handle logout. Is
there a way to configure Apache to require _no_ shibboleth session on
/Security/logout and have the Native SP module redirect to
/Shibboleth.sso/logout with a return URL? I would like for the
NativeSP shib session to be expired by the control returns to the CMS,
so that it can simply cleanup the CMS session.

The only way that comes to mind is to setup a mod_rewrite rule that
tests for auth_type being set to Shibboleth, and then redirecting to
/Shibboleth.sso/logout?return={original url} - but I was hoping for
something that was cleaner.

Thanks,
Steve
--
To unsubscribe from this list send an email to users-un...@shibboleth.net

[Kevin P. Foote]

Are you looking for something like this?

<Location ~ "^/Security/logout">
AuthType shibboleth
ShibRequireSession Off
require shibboleth
</Location>

------
thanks
kevin.foote

On Thu, 29 Sep 2011, Stephen Chan wrote:

-> Hi,
-> I'm working on shibboleth integration for a CMS we run and wanted
-> to get some suggestions for the best way to proceed.
->
-> There are 2 URL's used by the CMS to handle login and login,
-> /Security/login and /Security/logout. Using the native SP it is
-> straightforward to put a Shibboleth auth-type setting on
-> /Security/login and have all the appropriate attributes available to
-> be read by the web app.
->
-> The part that I would like advice on is how to handle logout. Is
-> there a way to configure Apache to require _no_ shibboleth session on
-> /Security/logout and have the Native SP module redirect to
-> /Shibboleth.sso/logout with a return URL? I would like for the
-> NativeSP shib session to be expired by the control returns to the CMS,
-> so that it can simply cleanup the CMS session.
->
-> The only way that comes to mind is to setup a mod_rewrite rule that
-> tests for auth_type being set to Shibboleth, and then redirecting to
-> /Shibboleth.sso/logout?return={original url} - but I was hoping for
-> something that was cleaner.
->
-> Thanks,
-> Steve
-> --
-> To unsubscribe from this list send an email to users-un...@shibboleth.net
->

[Stephen Chan]

Yes, I was in fact thinking of something just like that but it
wasn't clear what, if any, set of directives would do the right thing.

I just tried it, and it does not seem to be clearing the shib
session, I am getting the full list of Shib attributes as well as a a
legit session ID. No redirect to the logout handler, and my session
seems as healthy as ever.

Was it supposed to work, or were you asking the question just foe
clarification?

Steve

[Kevin P. Foote]

Your location /Security/logout would be the page or code
that would start your "local" logout.

What ever application code there would handle the removal of any
application session and then in an ideal world be able to land you at
/Shibboleth.sso/logout?redirect="bla" taking care of removing your SP
session as well..

At least that is what I recall. And the basics of how it happens in
the apps we have done this for..

------
thanks
kevin.foote

[Stephen Chan]

On Thu, Sep 29, 2011 at 3:15 PM, Kevin P. Foote <kpf...@iup.edu> wrote:
> Your location /Security/logout would be the page or code
> that would start your "local" logout.

Yes, that is exactly what it is.

> What ever application code there would handle the removal of any
> application session and

It does that now.

> then in an ideal world be able to land you at
> /Shibboleth.sso/logout?redirect="bla" taking care of removing your SP
> session as well..

Sadly we are in a less than ideal world, and there are no
convenient hooks in the web app for me to installed a final redirect.
I could do it if I modified the core session handling of the
application, but I would like to avoid that.

Do you know of a way to have the mod_shib module forward to the
logout handler and return? It does this for login, and I wonder if
there is a way to make it happen for logouts.

> At least that is what I recall. And the basics of how it happens in
> the apps we have done this for..

I have tested the following configuration and it works, however it
seems somewhat brittle and I wanted something cleaner:

<Location /Security/login.php>
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>

<Location /Security/no-op.php>

AuthType shibboleth
ShibRequireSession Off
require shibboleth
</Location>

<Location /Security/logout.php>

AuthType shibboleth
ShibRequireSession Off
require shibboleth
</Location>

<Directory blah...blah...blah/Security>
RewriteEngine on
RewriteCond %{AUTH_TYPE} =shibboleth
RewriteCond %{REMOTE_USER} ^.+$
RewriteRule ^(logout\.php.*)
/Shibboleth.sso/Logout?return=https://me.mydomain.tld/Security/${ [R]
</Directory>

It would be nice if that rewrite rule didn't have to be written for
every location - is there some support for this in the NativeSP?

Steve

[Cantor, Scott]

On 9/29/11 7:56 PM, "Stephen Chan" <syc...@lbl.gov> wrote:
>
> Do you know of a way to have the mod_shib module forward to the
>logout handler and return? It does this for login, and I wonder if
>there is a way to make it happen for logouts.

No, but I'm also not sure how that would look. I guess you mean like a
rule saying "if this URL is accessed, trigger a logout redirect". No, I
haven't ever thought of that, you could file a RFE for that.

>It would be nice if that rewrite rule didn't have to be written for
>every location - is there some support for this in the NativeSP?

No, mostly because logout of a local app is not terribly useful, and
because your situation is pretty unusual. Almost all apps have a logout
hook of some kind if they do anything at all.

-- Scott

[Stephen Chan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/29/11 5:23 PM, Cantor, Scott wrote:
>
> No, mostly because logout of a local app is not terribly useful,

    I understand what you are saying from a Web SSO perspective, but in our particular use case, it happens to be useful.

> and
> because your situation is pretty unusual. Almost all apps have a
> logout hook of some kind if they do anything at all.

   This app does have a logout hook, and it was very useful for calling the session logout code for SimpleSAMLPHP. I'd like to convert the app to the native SP and use the same hook, however a browser redirect introduces a lot more side effects than was originally planned for this logout hook. I can still use the hook, I just wanted to explore other options - such as expiring the SP session before even calling the CMS logout code.

    Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6FQ9wACgkQcVd2YI1BWAip+gCfUS5mniDApJlHGIazogcFzCEO
w9EAn2FOWJMr4LlXVh/zeEv4eswA8jq/
=Je0s
-----END PGP SIGNATURE-----

[Cantor, Scott]

On 9/30/11 12:21 AM, "Stephen Chan" <syc...@lbl.gov> wrote:
>
> This app does have a logout hook, and it was very useful for
> calling the session logout code for SimpleSAMLPHP. I'd like to
> convert the app to the native SP and use the same hook, however a
> browser redirect introduces a lot more side effects than was
> originally planned for this logout hook. I can still use the hook, I
> just wanted to explore other options - such as expiring the SP
> session before even calling the CMS logout code.

Expiring the session is basically just the cookie. You could walk the set
of cookies supplied to the page and clear them all. Or perhaps everything
but the set your CMS is managing. I wouldn't ever document those cookies
explicitly, but if you based it on the set that the client happened to
supply you, clearing those would be guaranteed to include the SP cookie.

I don't think a feature that "protects" a URL with a logout is something
very many people would use, but if you had in mind something like:

<Location /applogout>
AuthType shibboleth
ShibRequestSetting requireLogout /applogout
require shibboleth
</Location>

i.e. If a session exists, redirect to default LogoutInitiator with
"return" set to the final parameter, otherwise pass request through.

That would be fairly simple to add. Weird, but not a major undertaking.

But honestly I'm not sure a rewrite isn't just as simple, and it works
now, with all SP versions.

[Stephen Chan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/29/11 9:36 PM, Cantor, Scott wrote:
> Expiring the session is basically just the cookie. You could walk the
> set of cookies supplied to the page and clear them all. Or perhaps
> everything but the set your CMS is managing. I wouldn't ever document
> those cookies explicitly, but if you based it on the set that the
> client happened to supply you, clearing those would be guaranteed to
> include the SP cookie.

   I considered doing that earlier but wasn't sure if bypassing the logout handler was well advised. So just clearing the cookies containing "_shibsession_" would do the trick? I don't necessarily know all the cookies generated by the app and its collection of subpackages.

> I don't think a feature that "protects" a URL with a logout is
> something very many people would use, but if you had in mind
> something like:
>
> <Location /applogout> AuthType shibboleth ShibRequestSetting
> requireLogout /applogout require shibboleth </Location>
>
> i.e. If a session exists, redirect to default LogoutInitiator with
> "return" set to the final parameter, otherwise pass request through.
>
> That would be fairly simple to add. Weird, but not a major
> undertaking.
>
> But honestly I'm not sure a rewrite isn't just as simple, and it
> works now, with all SP versions.

   A rewrite rule can do the job, but then you have to craft the rewrite rule to take into account the actual servername being used, the current URL you are using, any parameters passed along in the query string. It is all easy stuff, but lots of details with opportunities for typos, and parsing rewrite rules is less intuitive than the sample directives you listed above.

   Plus, there is a certain clean symmetry to having a logout redirect as the complement to the login redirect. But in all honesty, if _shibsession_ cookies can be targeted, I would happily avoid having to redirect the browser.

   Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6FaMkACgkQcVd2YI1BWAjAhwCcDeQnq0KJ7diF62y2JQZ/bGYH
rqUAoI/cK89rDS4pfbpsfZNNAB8+lbGX
=GH7d
-----END PGP SIGNATURE-----

[Cantor, Scott]

On 9/30/11 2:59 AM, "Stephen Chan" <syc...@lbl.gov> wrote:
>
> I considered doing that earlier but wasn't sure if bypassing the
> logout handler was well advised. So just clearing the cookies
> containing "_shibsession_" would do the trick? I don't necessarily
> know all the cookies generated by the app and its collection of
> subpackages.

You may not clean the cookie solely based on the name. I will not
guarantee that the name will be the same, that¹s not a public API. If you
don't know the other cookies enough to know which are which, then no, that
would not work.

As far as what's advisable, if you don't care about freeing the session
from memory before it's kicked out by heuristics, then clearing the cookie
is enough to orphan the session.

[Stephen Chan]

On Fri, Sep 30, 2011 at 10:14 AM, Cantor, Scott <cant...@osu.edu> wrote:
> You may not clean the cookie solely based on the name. I will not
> guarantee that the name will be the same, that¹s not a public API. If you
> don't know the other cookies enough to know which are which, then no, that
> would not work.

Okay - something to consider may be an attribute like
"Shib-sessionCookies" that enumerates the cookie names, so that apps
can clear them out "surgically". On the face of it, it seems easy to
implement.

> As far as what's advisable, if you don't care about freeing the session
> from memory before it's kicked out by heuristics, then clearing the cookie
> is enough to orphan the session.

Thanks. I may just take my chances with deleting any cookies that
isn't a PHP session cookie.

Steve

[Cantor, Scott]

On 9/30/11 2:16 PM, "Stephen Chan" <syc...@lbl.gov> wrote:

> Okay - something to consider may be an attribute like
>"Shib-sessionCookies" that enumerates the cookie names, so that apps
>can clear them out "surgically". On the face of it, it seems easy to
>implement.

Yes, it would be. You can suggest anything you like in Jira. I don't track
or remember requests sent to the list.

I think you're vastly overstating the frequence of cases in which the
standard redirect flow is a problem, though. This has literally never been
an issue. Even Confluence can handle it.

-- Scott

[Stephen Chan]

On Fri, Sep 30, 2011 at 11:23 AM, Cantor, Scott <cant...@osu.edu> wrote:
> On 9/30/11 2:16 PM, "Stephen Chan" <syc...@lbl.gov> wrote:
>
>>   Okay - something to consider may be an attribute like
>>"Shib-sessionCookies" that enumerates the cookie names, so that apps
>>can clear them out "surgically". On the face of it, it seems easy to
>>implement.
>
> Yes, it would be. You can suggest anything you like in Jira. I don't track
> or remember requests sent to the list.

Okay, request submitted.

> I think you're vastly overstating the frequence of cases in which the
> standard redirect flow is a problem, though. This has literally never been
> an issue. Even Confluence can handle it.

Well, I don't think I've made any claims of the frequency of this
beyond my own request :-)

But I think that if these were available, they would be useful to
others as well.

Thanks for the guidance on handling logout, hopefully my updates to
the Silverstripe Shibboleth module will make back into the
distribution and Silverstripe will get some more usage in the
Shib/SAML community.

Steve

[Cantor, Scott]

On 10/3/11 2:55 PM, "Stephen Chan" <syc...@lbl.gov> wrote:
> Okay, request submitted.

It may turn out that the cookie thing isn't so easy, but the other feature
probably isn't too hard.

-- Scott