Bug 39815 - UMC-Webserver: KeyError during SAML logout request, Session still valid
UMC-Webserver: KeyError during SAML logout request, Session still valid
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC (Generic)
UCS 4.1
Other Linux
: P5 normal (vote)
: UCS 4.1-0-errata
Assigned To: Florian Best
Erik Damrose
:
: 39860 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-06 15:35 CET by Florian Best
Modified: 2019-01-09 13:49 CET (History)
4 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Error handling, External feedback, SAML
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2015-11-06 15:35:16 CET
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cprequest.py", line 656, in respond
    response.body = self.handler()
  File "/usr/lib/python2.7/dist-packages/cherrypy/lib/encoding.py", line 188, in __call__
    self.body = self.oldhandler(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cpdispatch.py", line 34, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "/usr/sbin/univention-management-console-web-server", line 1214, in logout
    data = self.sp.global_logout(user.saml.response.name_id)
  File "/usr/lib/python2.7/dist-packages/saml2/client.py", line 106, in global_logout
    entity_ids = self.users.issuers_of_info(name_id)
  File "/usr/lib/python2.7/dist-packages/saml2/population.py", line 42, in issuers_of_info
    return self.cache.entities(name_id)
  File "/usr/lib/python2.7/dist-packages/saml2/cache.py", line 142, in entities
    return self._db[cni].keys()
KeyError: '1=https%3A//master441.deadlock44.intranet/univention-management-console/saml/metadata,2=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Anameid-format%3Atransient,4=_d20734fef743f5fcaeca395507e4d4926bf13f23bd'
Comment 1 Florian Best univentionstaff 2015-11-10 15:47:37 CET
*** Bug 39860 has been marked as a duplicate of this bug. ***
Comment 2 Erik Damrose univentionstaff 2015-11-10 15:53:56 CET
1xMaster / 1xBackup environment. Chrome Browser on Windows 7.

Login to http://master/umc -> single sign-on on backup (visible on ucs-sso.)
Switch to backup from UMC dropdown on master
Logout on Backup -> redirect to master and backup (for logout)
Enter http://master/umc in browser -> Get a valid UMC Session! Users can be created!

On logout attempt from master the above traceback occurs.
Comment 3 Florian Best univentionstaff 2015-12-11 19:35:21 CET
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cprequest.py", line 656, in respond
    response.body = self.handler()
  File "/usr/lib/python2.7/dist-packages/cherrypy/lib/encoding.py", line 188, in __call__
    self.body = self.oldhandler(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cpdispatch.py", line 34, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "/usr/sbin/univention-management-console-web-server", line 1194, in slo
    if user.saml is None:
AttributeError: 'NoneType' object has no attribute 'saml'
Comment 4 Florian Best univentionstaff 2015-12-11 20:04:31 CET
Ok, here are multiple problems:
The first is the KeyError which has been fixed:
It happens when you acutally *are already* SAML-logged out but as the tab is still opened you can click on logout. I added a redirection to /logout so everything is fine.

The second problem is the AttributeError which happens if you log in via IP address, switch the host to another host, logout there:
You get redirected to the FQDN of that host and as your cookie is not valid there you cannot logout and redirect back to the IDP/SP to get to the next logout server.
I fixed the AttributeError to just logout locally. This has the drawback that you currently logout at SP-slave1 and get redirected to the login page of SP-master.
TODO: check if it's possible to circumvent this.

The third problem is that your UMC-session (not the UMC-SAML one) at SP-A seems still valid after the logout of SP-B.
But I guess this should be okay.
Comment 5 Florian Best univentionstaff 2015-12-14 20:28:21 CET
(In reply to Florian Best from comment #4)
> Ok, here are multiple problems:
> The first is the KeyError which has been fixed:
> It happens when you acutally *are already* SAML-logged out but as the tab is
> still opened you can click on logout. I added a redirection to /logout so
> everything is fine.
fixed as said.

> The second problem is the AttributeError which happens if you log in via IP
> address, switch the host to another host, logout there:
> You get redirected to the FQDN of that host and as your cookie is not valid
> there you cannot logout and redirect back to the IDP/SP to get to the next
> logout server.
> I fixed the AttributeError to just logout locally. This has the drawback
> that you currently logout at SP-slave1 and get redirected to the login page
> of SP-master.
> TODO: check if it's possible to circumvent this.
I could workaround this, so if the user is already logged out (or has no cookie for the FQDN) she is redirected back to the original host. I think it would not be so easy to preserve the IP and would have to be fixed in simplesamlphp.

> The third problem is that your UMC-session (not the UMC-SAML one) at SP-A
> seems still valid after the logout of SP-B.
> But I guess this should be okay.
Nothing done, if you disagree please reopen.

univention-management-console-frontend.yaml:
r66324 | YAML Bug #39815

univention-management-console-frontend (5.0.63-8):
r66323 | Bug #39815: fix error during logout
r66288 | Bug #39815: fix error during logout
Comment 6 Florian Best univentionstaff 2016-01-22 11:03:22 CET
Reported as traceback feedback.
Comment 7 Erik Damrose univentionstaff 2016-01-29 14:44:42 CET
OK: KeyError traceback is gone
OK: AttributeError traceback is gone

Reopen: I think these changes introduced a regression: SSO does not work in the following scenario, tested with IE11 and firefox:

Master + Backup
Log into master via SSO
switch to backup using the dropdown

Expected: The browser shows the UMC on backup
Observed: The UMC login windows on backup is shown
umc-web-server.log on backup shows SessionClient(0x37fafd0): _authenticated: success=True  status=200  message=None but nothing else happens.
Clicking on the SSO login link then grants UMC login.

Reopen: Another regression:
Login via http://<master-ipaddress>/umc -> SSO -> Logout

Expected: Logged out on master
Observed: Get redirected to http://<master-fqdn>/. Trying to access http://<master-ipaddress>/umc grants me a UMC session that i just logged out of.

(In reply to Florian Best from comment #4)
[...]
> The third problem is that your UMC-session (not the UMC-SAML one) at SP-A
> seems still valid after the logout of SP-B.
> But I guess this should be okay.

I still think this is dangerous and not okay. By using SSO i expect to be able to use the 'service' UMC: within the SSO session i can switch to UMCs of different servers, but i am still using the service UMC. If i logout at one endpoint, i expect that every UMC is not accessible for me anymore.

Think of another example: If i log into googlemail i can switch to the calendar, use google drive, docs, etc... If i logout at any of there services  i can not use the others unless i login again. I do not want to logout at every specific service i used.
Comment 8 Florian Best univentionstaff 2016-01-29 15:04:45 CET
(In reply to Erik Damrose from comment #7)
> OK: KeyError traceback is gone
> OK: AttributeError traceback is gone
> 
> Reopen: I think these changes introduced a regression: SSO does not work in
> the following scenario, tested with IE11 and firefox:
> 
> Master + Backup
> Log into master via SSO
> switch to backup using the dropdown
> 
> Expected: The browser shows the UMC on backup
> Observed: The UMC login windows on backup is shown
> umc-web-server.log on backup shows SessionClient(0x37fafd0): _authenticated:
> success=True  status=200  message=None but nothing else happens.
> Clicking on the SSO login link then grants UMC login.
This can't be a regression. nothing changed in the autologin. Check that firefox acceppts all SSL certificates and everywhere the FQDN is used and memcached is running.

> Reopen: Another regression:
> Login via http://<master-ipaddress>/umc -> SSO -> Logout
> 
> Expected: Logged out on master
> Observed: Get redirected to http://<master-fqdn>/. Trying to access
> http://<master-ipaddress>/umc grants me a UMC session that i just logged out
> of.
> (In reply to Florian Best from comment #4)
> [...]
> > The third problem is that your UMC-session (not the UMC-SAML one) at SP-A
> > seems still valid after the logout of SP-B.
> > But I guess this should be okay.
> 
> I still think this is dangerous and not okay. By using SSO i expect to be
> able to use the 'service' UMC: within the SSO session i can switch to UMCs
> of different servers, but i am still using the service UMC. If i logout at
> one endpoint, i expect that every UMC is not accessible for me anymore.
> 
> Think of another example: If i log into googlemail i can switch to the
> calendar, use google drive, docs, etc... If i logout at any of there
> services  i can not use the others unless i login again. I do not want to
> logout at every specific service i used.
No, this are 2 kinds of sessions. You are not anymore logged in at the IDP. But if you logout at the SP-UMC-1 then I wouldn't logout/destroy the running session at SP-UMC-2. If this would be done and one currently installs e.g. a app on SP-UMC-1 the AppCenter module process would be killed resulting in a maybe broken package state. Therefore I won't change this. The session will be destroyed after the session-timeout of 10 minutes.
Comment 9 Erik Damrose univentionstaff 2016-02-01 16:01:25 CET
(In reply to Florian Best from comment #8)
> > Observed: The UMC login windows on backup is shown
> > umc-web-server.log on backup shows SessionClient(0x37fafd0): _authenticated:
> > success=True  status=200  message=None but nothing else happens.
> > Clicking on the SSO login link then grants UMC login.
> This can't be a regression. nothing changed in the autologin. Check that
> firefox acceppts all SSL certificates and everywhere the FQDN is used and
> memcached is running.

This could be traced back to a Firefox problem and could not be reproduced every time.

> > Reopen: Another regression:
> > Login via http://<master-ipaddress>/umc -> SSO -> Logout
> > 
> > Expected: Logged out on master
> > Observed: Get redirected to http://<master-fqdn>/. Trying to access
> > http://<master-ipaddress>/umc grants me a UMC session that i just logged out
> > of.
> > (In reply to Florian Best from comment #4)
> > [...]
> > > The third problem is that your UMC-session (not the UMC-SAML one) at SP-A
> > > seems still valid after the logout of SP-B.
> > > But I guess this should be okay.
> > 
> > I still think this is dangerous and not okay. By using SSO i expect to be
> > able to use the 'service' UMC: within the SSO session i can switch to UMCs
> > of different servers, but i am still using the service UMC. If i logout at
> > one endpoint, i expect that every UMC is not accessible for me anymore.
> > 
> > Think of another example: If i log into googlemail i can switch to the
> > calendar, use google drive, docs, etc... If i logout at any of there
> > services  i can not use the others unless i login again. I do not want to
> > logout at every specific service i used.
> No, this are 2 kinds of sessions. You are not anymore logged in at the IDP.
> But if you logout at the SP-UMC-1 then I wouldn't logout/destroy the running
> session at SP-UMC-2. If this would be done and one currently installs e.g. a
> app on SP-UMC-1 the AppCenter module process would be killed resulting in a
> maybe broken package state. Therefore I won't change this. The session will
> be destroyed after the session-timeout of 10 minutes.

Ok, seems to be out of scope for this bug anyway.
Its too bad my bug was closed as a duplicate of this one and then not fixed. I will file a new one.
-> Verified
Comment 10 Janek Walkenhorst univentionstaff 2016-02-04 14:06:13 CET
<http://errata.software-univention.de/ucs/4.1/88.html>