Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving support for switching between multiple WLS #29

Open
mgkuhn opened this issue Jan 16, 2023 · 0 comments
Open

Improving support for switching between multiple WLS #29

mgkuhn opened this issue Jan 16, 2023 · 0 comments

Comments

@mgkuhn
Copy link
Contributor

mgkuhn commented Jan 16, 2023

Following the 2022-12-14 announcement that Raven will switch on multi-factor authentication (MFA) by using a Microsoft login page, we recently received from the UIS these instructions for maintaining our Raven4Life services:

Sites allowing ‘Raven for Life’ users to log in will continue to use the legacy Raven login screen, and these users will not be asked to authenticate with a second factor. If your site or application allows ‘Raven for Life’ users to log in, please contact us and provide your site’s domain (specifically authentication return URL) so we can ensure it is included in this group.

It turns out that Raven Ucam-WebAuth users will soon be forwarded by default to a Microsoft MFA login page, unless the authentication return URL provided by the WAA is on a UIS-maintained list of Raven4Life services, in which case users will be forwarded instead to legacy.raven.cam.ac.uk, which is where the original Raven WLS now resides.

Choosing this forward destination for specific URL prefixes at the UIS end, as suggested above, is rather inconvenient for application developers, as it spreads the security configuration of a site over different organizations (and also can cause a security problem related to the session cookie where the same WAA serves applications with different MFA policies, see below). Instead, it would be much nicer if an application developer could make this switch locally in their own WAA.

It appears that this local choice is already possible in mod_ucam_webauth: the WLS configured by default is

AAAuthService https://raven.cam.ac.uk/auth/authenticate.html

which will soon forward users to a Microsoft MFA login page that does not support Raven4Life, but changing that value to point instead to

AAAuthService https://legacy.raven.cam.ac.uk/auth/authenticate.html

will cause continued use of the original Raven login page with Raven4Life support. This way, the MFA-vs-Raven4Life policy can also be configured locally by changing the WLS address.

That is security-wise fine if one wants to make such a switch globally, for an entire web server.

However, it is also possible to configure different AAAuthService values for different applications within a single web site, and this can even be done by individual users within their .htaccess files. In that case, a security vulnerability may arise, because at present the session cookie generated by mod_ucam_webauth does not incorporate any information about which WLS (AAAuthService) value it is associated with. As a result, someone could e.g. log into a service https://www.dept.cam.ac.uk/raven4life-site/ and obtain a mod_ucam_webauth session cookie that would then also be valid for https://www.dept.cam.ac.uk/microsoft-mfa-site/, thereby bypassing the MFA requirement of one of these two applications by first logging into the other one.

A simple workaround is to change the cookie name and key at the same time as changing the WLS address, i.e. to always use e.g. the following three lines to switch to the new “legacy” login server:

AAAuthService https://legacy.raven.cam.ac.uk/auth/authenticate.html
AACookieName Ucam-WebAuth-Legacy-Session
AACookieKey SomeRandomSecretjdJKSDjkhssjklhJSDf

However, users may forget these, and keeping a cookie key in a .htaccess file is also security-wise rather inconvenient and problematic.

Therefore I would like to suggest that mod_ucam_webauth be modified in the following way:

  • If AAAuthService is changed to a value that deviates from the default, then automatically the default value for AACookieName should also be changed to deviate from the default, e.g. by including a hash of the AAAuthService value into the new default cookie name.
  • The current value of AAAuthService should also be incorporated into the calculation of the hash that forms the cookie value, such that cookies obtained via authentication from one WLS cannot also be used to bypass the need to authenticate on another WLS.

This would eliminate the need to always change AACookieName and AACookieKey at the same time as AAAuthService for secure operation of mod_ucam_webauth with multiple authentication services.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant