e97070808f
- No longer written with a seamless transition in mind. It's probably possible, but untested, and I believe most deployments do a hard cutover anyhow. Since this is just Studio, logging everyone out is probably acceptable. - Remove decline-migration section since we don't believe anyone is likely to need this (and we're deprecating it anyhow.) - Remove `/login/` config changes, since those have already been performed in the common env and were only required for seamless migration. Remove cleanup for same reason. - Give hint about domain-changing ref ARCHBOM-1890
53 lines
3.0 KiB
ReStructuredText
53 lines
3.0 KiB
ReStructuredText
Enabling OAuth for Studio login
|
|
===============================
|
|
|
|
This is a migration guide for converting Studio login to use OAuth, for use in the Lilac to Maple upgrade.
|
|
|
|
Background
|
|
----------
|
|
|
|
As of Lilac, the Studio by default shares a session cookie with the LMS. This either forces Studio to be on a subdomain of the LMS or the LMS to set its session cookie on a wide domain, which exposes it to a potentially large number of subdomains.
|
|
|
|
Maple's configuration assumes that Studio will use LMS's OAuth2-based single-sign-on (SSO). This means that the cookies (and domains) can be decoupled to improve both flexibility and security. However, there are a few steps to take to finish this configuration (otherwise Studio logins will not work.)
|
|
|
|
Migration
|
|
---------
|
|
|
|
Studio and LMS need to be configured in each environment to enable the new flow, with the exception of devstack and sandboxes (which will autoconfigure for OAuth.) Migration involves enabling OAuth and separating the session cookies for LMS and Studio. The session cookie split will require Studio users to log in again.
|
|
|
|
Follow these steps for each deployed environment (stage, production, etc.):
|
|
|
|
#. Register an SSO OAuth2 client in LMS:
|
|
|
|
- Add OAuth2 client:
|
|
|
|
- Go to ``/admin/oauth2_provider/application/add/`` in LMS admin
|
|
- Copy the prepopulated client ID and secret to a secure place
|
|
- Leave the user field empty
|
|
- Set redirect URLs to ``<STUDIO_ROOT_URL>/complete/edx-oauth2/`` (as well as for any alternate Studio domain names)
|
|
- Set client type to ``Confidential``
|
|
- Set authorization grant type to ``Authorization code``
|
|
- Set the name to ``studio-sso`` or other name of your choice
|
|
- Select the "Skip authorization" checkbox
|
|
|
|
- Configure the client's scope:
|
|
|
|
- Go to ``/admin/oauth_dispatch/applicationaccess/add/`` in LMS admin
|
|
- Select application ``studio-sso``
|
|
- Set scopes to ``user_id``
|
|
|
|
#. Configure LMS to log out Studio when logging out by adding ``<public Studio root>/logout/`` to the LMS ``IDA_LOGOUT_URI_LIST``.
|
|
|
|
#. Configure Studio to allow completion of OAuth flow::
|
|
|
|
SOCIAL_AUTH_EDX_OAUTH2_KEY: <client id>
|
|
SOCIAL_AUTH_EDX_OAUTH2_SECRET: <client secret>
|
|
SOCIAL_AUTH_EDX_OAUTH2_URL_ROOT: <server-to-server LMS root URL> # possibly same as public LMS root URL
|
|
SOCIAL_AUTH_EDX_OAUTH2_PUBLIC_URL_ROOT: <public LMS root URL>
|
|
|
|
#. Configure Studio to initiate OAuth flow and use a separate session cookie::
|
|
|
|
SESSION_COOKIE_NAME: studio_sessionid
|
|
|
|
This cookie renaming step is also a good opportunity to change ``SESSION_COOKIE_DOMAIN`` if desired, since it allows for a clean transition without having to worry about `flaky behavior driven by order-unstable cookie-sending <https://fwielstra.github.io/2017/03/13/fun-with-cookies-and-subdomains/>`_. Narrowing the domain (or removing it, to keep subdomains from seeing the cookie) may improve the security of your deployment, but the best option depends on the exact layout of your domain names and is beyond the scope of this document.
|