How to disable SSO
willem
Is there a way that "saml2/idp/SSOService.php" will check credentials
regardless of earlier successfull logins?
In other words, is there an option in simplesamlphp to disable the
remembrance of an successful authentication?
We use samplesamlphp as idp and we use CAS to let the user login.
CAS is also the primary entrance to our school portal.
Links the federated services are in the portal.
This works because the service will eventually redirect to "saml2/idp/
SSOService.php", which will ask CAS if a valid user is logged in.
But... upon success, the authenticated user is unfortunately stored in
a session.
When a new user logs in on the portal (without the old one properly
closing the browser), and it starts a federated service, he or she
will be logged in as the previous user, because "saml2/idp/
SSOService.php" has that previous user authenticated in its session!
I simply want SSOService.php to *always* check what user to use with
CAS.
Is this possible?
Best Regards, Willem
Thijs Kinkhorst
On Thursday 18 November 2010 12:55:31 willem wrote:
> Is there a way that "saml2/idp/SSOService.php" will check credentials
> regardless of earlier successfull logins?
> In other words, is there an option in simplesamlphp to disable the
> remembrance of an successful authentication?
>
> We use samplesamlphp as idp and we use CAS to let the user login.
> CAS is also the primary entrance to our school portal.
> Links the federated services are in the portal.
> This works because the service will eventually redirect to "saml2/idp/
> SSOService.php", which will ask CAS if a valid user is logged in.
>
> But... upon success, the authenticated user is unfortunately stored in
> a session.
>
> When a new user logs in on the portal (without the old one properly
> closing the browser), and it starts a federated service, he or she
> will be logged in as the previous user, because "saml2/idp/
> SSOService.php" has that previous user authenticated in its session!
I'm not sure if I understand your problem correctly. So the scenario is:
- User A signs in with CAS on a public terminal.
- A doesn't close browser or sign out otherwise.
- B walks up to public terminal and opens portal, sees content of user A.
If you would force the portal to always reauthenticate the user, wouldn't that
only hide the problem? Because if B doesn't go to the portal but straight to
one of the federated services behind it, B would still have access to A's
stuff, because the session is still active, right?
Cheers,
Thijs
--
Thijs Kinkhorst <th...@uvt.nl> – LIS Unix
Universiteit van Tilburg – Library and IT Services • Postbus 90153, 5000 LE
Bezoekadres > Warandelaan 2 • Tel. 013 466 3035 • G 236 • http://www.uvt.nl
Willem Toorop
That would absolutely hide the problem!
We do everything possible to let the user close their browser after they are done.
But, besides all that, it is simply not acceptable that someone who logs into the portal and opens the webmail, sees the e-mail of the previous user.
Even if this would really be the fault of that previous user not closing the browser.
Now we can open the specific federated service forcing re-authentication from the portal.
But only, because simplesamlphp also has the user stored in its session, it never checks CAS and users are still logged into the webmail as the previous user (if there was one not closing the browser), even if this previous user logged out from the portal and thus from CAS.
It seems to me, that when CAS is used as the authentication plugin, that simplesamlphp should not store the user in a session.
Cheers, Willem
Randy Saeks
Would changing the session length to a very shourt time or setting the session save path to /dev/null be an option?
--
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.
Peter Schober
> Would changing the session length to a very shourt time or setting the
> session save path to /dev/null be an option?
Like Thijs said, this (also) will leave all accessed SAML2 service
providers vulnerable (i.e., with an open session).
-peter
Willem Toorop
In metadata/saml20-sp-remote.php I had to add
'ForceAuthn' => TRUE,
to each server provider record.
If you use an external SSO mechanism (such as CAS) as your authentication source, you do not want simplesamlphp to handle SSO also.
For this reason; wouldn't config/authsource.php be a more logical location for the 'ForceAuthn' parameter?
Maybe this should be mentioned in the CAS module documentation?
Thanks for the support! Willem
Olav Morken
> Ok, I found it!
>
> In metadata/saml20-sp-remote.php I had to add
>
> 'ForceAuthn' => TRUE,
>
> to each server provider record.
>
> If you use an external SSO mechanism (such as CAS) as your authentication
> source, you do not want simplesamlphp to handle SSO also.
> For this reason; wouldn't config/authsource.php be a more logical location
> for the 'ForceAuthn' parameter?
Not really - the authentication sources aren't consulted before we
decide that we need to authenticate the user. It might have a place
in the saml20-idp-hosted metadata file, but I'm not sure we want to go
that way.
You mentioned that this was to avoid a problem where another user logs
in with his own username in the CAS system, but is still logged in with
another user in the simpleSAMLphp session. I therefore assume that the
previous user was able to log out of CAS?
If that is the case, could you change the CAS logout to also visit:
https://<your-idp>/simplesaml/saml2/idp/SingleLogoutService.php?ReturnTo=<URL the user should land on after logging out>
That way, the user will also be logged out of all SAML 2 SPs, and the
SAML 2 IdP.
If, on the other hand, the user is logged out of CAS because of
inactivity, you should tune the 'session.duration' option in config.php
to match the lifetime of the CAS session.
> Maybe this should be mentioned in the CAS module documentation?
I'm not against updating the CAS documentation, but I don't think
telling users to add "ForceAuthn" to all SP entries is the best
approach.
Regards,
Olav Morken
UNINETT / Feide