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
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:
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.
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:
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 iswhich will soon forward users to a Microsoft MFA login page that does not support Raven4Life, but changing that value to point instead to
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
AAAuthServicevalues for different applications within a single web site, and this can even be done by individual users within their.htaccessfiles. In that case, a security vulnerability may arise, because at present the session cookie generated bymod_ucam_webauthdoes not incorporate any information about which WLS (AAAuthService) value it is associated with. As a result, someone could e.g. log into a servicehttps://www.dept.cam.ac.uk/raven4life-site/and obtain amod_ucam_webauthsession cookie that would then also be valid forhttps://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:
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_webauthbe modified in the following way:AAAuthServiceis changed to a value that deviates from the default, then automatically the default value forAACookieNameshould also be changed to deviate from the default, e.g. by including a hash of theAAAuthServicevalue into the new default cookie name.AAAuthServiceshould 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
AACookieNameandAACookieKeyat the same time asAAAuthServicefor secure operation ofmod_ucam_webauthwith multiple authentication services.