The PR #22416 completes the work started in #19453 to use the LMS login and registration for Studio, rather than Studio providing its own implementation.
LMS login and registration are being used for the following reasons:
LMS logistration properly handles all SSO integrations.
A single logistration is simpler to maintain and understand.
Allows Studio to work more like all other IDAs that use LMS logistration.
The original switch to use LMS logistration for Studio also added the toggle DISABLE_STUDIO_SSO_OVER_LMS to provide the community some additional time for switching. This temporary toggle is being removed, which at this point means all deployments will use the LMS logistration.
This change requires sharing cookies across LMS and Studio. Should that prove to be a problem for certain Open edX instances, there are notes of possible alternative solutions.
See #19845 (comment). Feel free to continue the discussion in this topic.
Why is that the case? This is not how SSO usually works, is it?
I think it’s a shame that the studio and the LMS have to share a common domain name. It seems like an unnecessary constraint on platform deployment. Are there other components of the LMS/CMS that require that the CMS reside at a subdomain of the LMS?
I imagine it is because it was a simple solution that got us to a shared login page given CMS is part of edx-platform with a shared database.
@Felipe noted the following possible alternatives on one of the PRs:
convert the studio auth into a real SSO third party authentication using Oauth2
use the plugins mechanism to create authentication view for studio (can be done independently by the community. No need to merge anything to the core)
Either of these could be pursued. It is unclear whether the oauth2 solution we use with the other IDAs will play nicely with the fact that the users already exist in the db.
We also have similar constraints around subdomains with the JWT cookies and our new microfrontends for now.