The Self Service should support Single Sign On using SAML. This would improve significantly the user experience and would also avoid to fix bugs like #51403 #51404 #51405
We need a fallback which works in test environments where SAML isn't possible due to lack of DNS and/or HTTPS. Maybe we can have the same login mechanism as for Portal and UMC?
What part of the self service do you mean? The password reset actually not. The forgot password also not. So leftovers are: contact information, profile. I think you can already do a SAML login and it prefills your data?! I think we should instead remove these things from the portal and implement them as UMC modules.
(In reply to Florian Best from comment #2) > What part of the self service do you mean? > The password reset actually not. > The forgot password also not. > > So leftovers are: contact information, profile. yes, these are the usecases for SSO > I think you can already do a SAML login and it prefills your data?! it prefills the login once (which in this case can't be changed), but you have to enter your password. If that fails you also have to enter your login. That's were I'd like to improve things. > I think we should instead remove these things from the portal and implement > them as UMC modules. Would that be possible and reasonable with the existing self service backend?
Created attachment 10420 [details] patch draft The Self-Service uses already SAML and connects to the local Self Service UMC module. So the problem is that we are just querying for a username/password combination which we already have. Attached is a patch draft, which would cause that these contact information are set on the DC Slave instead of the request being forwarded to the DC Master. That shouldn't be a problem. TODO: * hide the password widget from the frontend if one is already logged in. * don't send the username in the request * self.get_user_ldap_connection connects to the local ldap server. It needs to connect to the DC Master. Either add a parameter in UMC or copy the code of the function and use write=True. * check if there are dependencies like UCR variables which need to be set also on the slave. Check if there are more package dependencies.
The self service could only be used by entering the credentials as form values. Now, when being logged in into UMC via SAML or via plain login, these credentials can be used. In environments where the self-service is installed on a DC Master and on e.g. a DC Slave one need to consider, that all UCR variables, settings e.g. adjustments of the email texts now need to be set on the DC Slave as well. As this is a breaking change the behavior must be enabled explicitly by setting 'umc/self-service/allow-unauthenticated-use' to true. Conceptually this change would have required the UMC UDM module to be installed on the DC Slave. That's not possible. Therefore the method get_user_attributes had to be split into get_user_attributes_values which is executed locally while get_user_attributes_descriptions must be executed on the DC Master. univention-management-console (11.0.5-2) c06b46e28d07 | Bug #51607: allow use of the self service without reentering credentials univention-management-console.yaml b217435650f3 | YAML Bug #51607 univention-self-service.yaml b217435650f3 | YAML Bug #51607 univention-self-service (4.0.3-39) c06b46e28d07 | Bug #51607: allow use of the self service without reentering credentials
(In reply to Florian Best from comment #5) > In environments where the self-service is installed on a DC Master and > on e.g. a DC Slave one need to consider, that all UCR variables, > settings e.g. adjustments of the email texts now need to be set on the DC > Slave as well. As this is a breaking change the behavior must be enabled > explicitly by setting 'umc/self-service/allow-unauthenticated-use' to > true. This does not reflect the actual code base. Currently the feature is automatically enabled on all fresh installations of univention-self-service and explicitly disabled during updates. Additionally, if it is fundamental, that the UCR variables are set on DC slave as well, this should be added to the manual → REOPEN
(In reply to Sönke Schwardt-Krummrich from comment #6) > (In reply to Florian Best from comment #5) > > In environments where the self-service is installed on a DC Master and > > on e.g. a DC Slave one need to consider, that all UCR variables, > > settings e.g. adjustments of the email texts now need to be set on the DC > > Slave as well. As this is a breaking change the behavior must be enabled > > explicitly by setting 'umc/self-service/allow-unauthenticated-use' to > > true. > > This does not reflect the actual code base. Currently the feature is > automatically enabled on all fresh installations of univention-self-service > and explicitly disabled during updates. > > Additionally, if it is fundamental, that the UCR variables are set on DC > slave as well, this should be added to the manual → REOPEN Maybe we should change the default first with UCS 4.4-7 and not with UCS 4.4-6 errata X Otherwise the behaviour of UCS has changed with an errata update and installation processes may fail / behave differently.
I cannot save a user's profile with a SAML ticket: > 1 Fehler aufgetreten: > password: Wert ist zu kurz, seine Länge muss mindestens 1 Zeichen betragen Tested with setup with master and slave. Both systems have been updated to latest dev errata packages. 1) umc/self-service/allow-authenticated-use=false → user enters its username and password → profile is shown → user changes profile and presses "save" → profile is saved successfully 2) umc/self-service/allow-authenticated-use=true → user enters its username and password → profile is shown → user changes profile and presses "save" → profile is saved successfully 3) umc/self-service/allow-authenticated-use=true → user is logged in via SAML at Univention Portal → user switches to profile page → profile is shown → user changes profile and presses "save" → error message at the top is shown 4) umc/self-service/allow-authenticated-use=true → user is logged in !without! SAML at Univention Portal → user switches to profile page → profile is shown → user changes profile and presses "save" → error message at the top is shown → REOPEN
First test with new package version 4.0.3-43A~4.4.0.202010051033: 1) umc/self-service/allow-authenticated-use=false → user enters its username and password → profile is shown → user changes profile and presses "save" → profile is saved successfully → OK 2) umc/self-service/allow-authenticated-use=true → user enters its username and password → profile is shown → user changes profile and presses "save" → profile is saved successfully → OK 3) umc/self-service/allow-authenticated-use=true → user is logged in via SAML at Univention Portal → user switches to profile page → profile is shown → user changes profile and presses "save" → profile is saved successfully → OK 4) umc/self-service/allow-authenticated-use=true → user is logged in !without! SAML at Univention Portal → user switches to profile page → profile is shown → user changes profile and presses "save" → profile is saved successfully → OK
The changes are now only applied during new installation on UCS 4.4-7. One Javascript issue has been fixed, which caused comment #9. univention-self-service (4.0.3-43) ee3f475be93a | Bug #51607: enable behavior only in UCS 4.4-7 970836ef032b | Bug #51607: fix not sending empty credentials when saving 285a85669b97 | Bug #51607: make loading a singleton 58c4cc9009ab | Bug #51607: revert not disabling password
Currently the SAML ticket can be used to set a recovery mail address which is a security issue. This change should be reverted.
I reverted the changes for the "Protect Account" module as it did only fetch the attributes but did not display the password input box to set the values. univention-self-service (4.0.3-45) 6d2858d0c821 | Bug #51607: do not activate changes for the protect-account module
During updates from older versions of the self service, the UCR variable umc/self-service/allow-authenticated-use is explicitly set to "false". During fresh installations of the self service with UCS 4.4-6, the UCR variable is NOT set (which results in the same behaviour as "false"). During fresh installations of the self service with UCS 4.4-7 and higher, the UCR variable is set to "true". Small glitch, but I think this is okay: the UCR variable states, that the default value is "true". This is only correct starting from UCS 4.4-7. Within UCS 4.4-6 with installed errata, the default is <empty> (aka "false"). univention-self-service-master.postinst does not set umc/self-service/allow-authenticated-use. This is okay for 4.4-6 but with 4.4-7 this seems to be a problem, since the configuration of SS frontend and SS backend do not match after a fresh installation. → copy the postinst code to univention-self-service-master.postinst? → REOPEN I retested all combinations of {unauthed, legacy-authed, SAML-authed} user with umc/self-service/allow-authenticated-use={true,false} with the self service modules "protect account" and "your profile". → same results as above for "your profile" → the "protect account" autofills the username field only, if the user has a valid session → OK Apart from the above points: OK: code change OK: installation OK: update ok with 4.4-6 OK: changelog entry FIXED: advisory OK: functional change OK: package built and installable I think the merge request for 5.0-0 is still pending. Please QA the changes for the manual. [4.4-6] b72f29d26a Bug #51607: add UCRV description for umc/self-service/allow-authenticated-use [4.4-6] 74a78e1885 Bug #51607: update advisory for univention-self-service
(In reply to Sönke Schwardt-Krummrich from comment #13) > univention-self-service-master.postinst does not set > umc/self-service/allow-authenticated-use. > This is okay for 4.4-6 but with 4.4-7 this seems to be a problem, since the > configuration of SS frontend and SS backend do not match after a fresh > installation. > → copy the postinst code to univention-self-service-master.postinst? > → REOPEN I moved this into univention-self-service-passwordreset-umc.postinst. > I think the merge request for 5.0-0 is still pending. No, it's already there since the beginning in https://git.knut.univention.de/univention/ucs/-/merge_requests/7 (see Bugzilla URL field). > Please QA the changes for the manual. OK. I added them to the 5.0-0 merge request. univention-self-service (4.0.3-46) 29eaf77e2ef3 | Bug #51607: move setting of UCR variables to common postinst
(In reply to Florian Best from comment #14) > (In reply to Sönke Schwardt-Krummrich from comment #13) > > univention-self-service-master.postinst does not set > > umc/self-service/allow-authenticated-use. > > This is okay for 4.4-6 but with 4.4-7 this seems to be a problem, since the > > configuration of SS frontend and SS backend do not match after a fresh > > installation. > > → copy the postinst code to univention-self-service-master.postinst? > > → REOPEN > I moved this into univention-self-service-passwordreset-umc.postinst. Verified > > I think the merge request for 5.0-0 is still pending. > No, it's already there since the beginning in > https://git.knut.univention.de/univention/ucs/-/merge_requests/7 (see > Bugzilla URL field). OK > > Please QA the changes for the manual. > OK. I added them to the 5.0-0 merge request. > > univention-self-service (4.0.3-46) > 29eaf77e2ef3 | Bug #51607: move setting of UCR variables to common postinst OK
<https://errata.software-univention.de/#/?erratum=4.4x763>
OK, but to fully work, we also need an update to UMC
... which has already been VERIFIED to work
<https://errata.software-univention.de/#/?erratum=4.4x776>