Univention Bugzilla – Bug 53207
Allow disabling of the fallback to UCS login
Last modified: 2021-06-14 07:25:48 CEST
In order to be IT Grundschutz compliant there has to be a single implementation of the web based login to UCS. Currently as a fallback there is the UCS login (/univention/login) used when the login /simplesamlphp/[..] cannot be reached by the client (browser). We need an option to disable to fallback.
Please be more specific, what is actually required. Maybe post the BSI-Grundschutz phrase about it. Should /univention/login/ only not be available for users? Shouldn't a link exists to it? Does the functionality behind it needs to be disabled? /univention/login/ and /simplesamlphp/ are different services, (on different hosts). At the end, when logging into UMC both mechanism use /univention/auth which uses one PAM stack.
The following paragraphs vom from "BSI Grundschutz APP.3.1 Webanwendungen": From APP.3.1.A1: "Es MUSS eine zentrale Authentisierungskomponente verwendet werden, die möglichst mit etablierten Standardkomponenten umgesetzt wurde." From APP.3.1.M1: "Die Authentisierungslogik sollte nur an einer Stelle und nicht mehrfach im Programmcode realisiert werden." The code related to /univention/login/ must not be triggered in any case, when the UCS login is disabled as requested in this ticket.
(In reply to Thorsten from comment #2) > The code related to /univention/login/ must not be triggered in any case, > when the UCS login is disabled as requested in this ticket. This means that all machine-to-machine communication is not possible anymore. e.g. the global App-Center, e.g. UCS@school functionality, e.g. changing IP addresses of the servers, etc. pp.
(In reply to Florian Best from comment #3) > This means that all machine-to-machine communication is not possible > anymore. e.g. the global App-Center, e.g. UCS@school functionality, e.g. > changing IP addresses of the servers, etc. pp. The mentioned cases make use of the browser/webbased authentication? This is all about the user not being able to have both options from the browser (the login form, but also the component receiving and processing the data from the login form).
(In reply to Thorsten from comment #4) > (In reply to Florian Best from comment #3) > > This means that all machine-to-machine communication is not possible > > anymore. e.g. the global App-Center, e.g. UCS@school functionality, e.g. > > changing IP addresses of the servers, etc. pp. > The mentioned cases make use of the browser/webbased authentication? yes.
From my perspective we can close this issue, as we try to move the project to UCS5 and UCS5 does not longer support AFAIK automated fallback to the UMC login.