cambridgeuniversity / mod_ucam_webauth Goto Github PK

RAVEN038 in master TODO list

RAVEN057 in the master TODO list

RAVEN101 in master TODO list

Apple have removed OpenSSL from MacOS, so m_u_w can no longer be built there. Presumably they have some replacement technology for supporting SSL/TLS (with mod_ssl or otherwise) and perhaps m_u_w could be adapted to work with this?

Current alternatives are to use Homebrew Apache, to move to mod_shib (but does that work on current MacOS, and if so how?), or to move to a Linux server.

RAVEN109 in master TODO list

There are a variety of open issues and bugfix PRs, dating back three years now.

Is UIS/@cambridgeuniversity still maintaining mod_ucam_webauth?

I note that https://raven.cam.ac.uk/project/#aa says:

University Information Services maintains and supports:

• an Ucam WebAuth authentication handler for Apache [i.e. mod_ucam_webauth]
• a Java toolkit implementing Ucam WebAuth functionality

(I assume the above URL is still maintained...)

Admittedly the prominent banner at the top of that page says "[t]he WebAuth protocol should not be used for new sites or applications", but this does not necessarily mean that UIS has withdrawn support for it or prevented its use. Indeed there are plenty of existing sites and applications today using the deprecated protocol against the UIS-run Raven service.

What is the plan for mod_ucam_webauth and the protocol it speaks?

RAVEN058 in master TODO list

RAVEN033 in master TODO list

RAVEN019 in master TODO list

If an HTTP POST triggers authentication (whether or not this results in a authentication challenge) then the redirect via the authentication server causes the POST to be retried as a GET. This could confuse an application that distinguishes between the two, but more importantly results in the loss of any posted content. If this was, for example, a carefully-composed blog post then the loss is likely to be annoying.

Currently the module just writes a log record when this happens to make it easier to diagnose resulting events.

In principle it might be possible to store the POSTed content locally before triggering the redirect to the authentication server and then pick it up again following successful authentication and simulate the submission of the original POST. Care would be needed to securely and reliably match the stored POST data with the corect authentication response.

Simple approaches, such as storing POST data either in the URLs query string or in the params field of the authentication request aren't generally practical given that POST data can be large (file upload, for example).

By default, when authorization fails (e.g., due to a Require user ... directive blocking access), Apache replies with status 401 and says:

Unauthorized

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.

The mention of wrong passwords is misleading with Raven, because if the Raven password entered had been wrong, the WLS/IdP would have said so already to the user. Therefore, the mod_ucam_webauth module overrides Apache's default 401 message with:

Error - authorization required

Access to the web page or other resource you are trying to obtain is restricted. The identity that you have established (mgk25) is not currently allowed access. Please contact the administrator of the web server that provides the page (webmaster@localhost) for further information.

However, Apache lacks a proper API for mod_ucam_webauth to override this message, so the current implementation of this override remains a fragile hack, as became evident with issue #11.

Since Apache 2.3.11, there has been a much neater solution: the AuthzSendForbiddenOnFailure directive. AuthzSendForbiddenOnFailure On causes Apache to report an authorization failure with status 403 instead of 401, resulting in the perfectly appropriate (if a bit brief) default message

Forbidden

You don't have permission to access ... on this server.

Therefore, I propose to remove from mod_ucam_webauth all the mechanics for overriding the 401 message, and instead advise users to set AuthzSendForbiddenOnFailure On along with AuthType Ucam-WebAuth. At their discretion, users may also want to add an ErrorDocument 403 ... directive to explain better the local authorization policy, e.g. whom to contact to get the desired permission.

Debian 10 "buster" is now officially released, so it would be great to have the corresponding deb added to the releases page.

The lack of keys in packages confuses people. The logic of excluding them was that for security the people installing the package should separately acquire and verify the keys rather than trusting a potentially dodgy, perhaps unsigned package.

But there a fair argument that if the package is dodgy then you've lost anyway because the key verification code may itself have been compromised.

RAVEN106 in master TODO list

RAVEN092 in master TODO list

RAVEN096 in master TODO list

Looks like they are the HTML for a Raven login page.

What is the point of the Windows/ folder in this git repo? It just contains old binaries.

Cosnider the following working config:

<VirtualHost *:80>
ServerName dev.example.com
ServerAlias alpha.example.com beta.example.com
# get the server name from the Host: header
UseCanonicalName Off

VirtualDocumentRoot /var/www/%0

<Directory /var/www/%0/>
  Options -Indexes +FollowSymLinks +MultiViews
  AllowOverride All
  Require all granted
</Directory>

#<Location />
#  AuthType Ucam-WebAuth
#  Require valid-user
#</Location>

LogLevel notice
ErrorLog ${APACHE_LOG_DIR}/dev-error.log
CustomLog ${APACHE_LOG_DIR}/dev-access.log combined

</VirtualHost>

Note the 3 fqdn's and the disabled canonical names. This uses vhost_alias to allow variables in document root. Works perfectly fine, serving the correct document root for each of the 3 fqdn's.

Now, if I uncomment the Location + Auth lines above, then Raven works fine when accessing dev.example.com, authenticates then redirects back to dev.example.com.

However, when trying beta.example.com or alpha.example.com, the Webauth module wrongly sets dev.example.com in the request, then authenticates at Raven, then goes back to dev.example.com (instead of beta or alpha).

GET /?WLS-Response=3!200!!20200704T221324Z!uwa3V7Q.Iv9IGtgDrjlRR6Ro!http%3A%2F%2Fdev.example.com%2F!crsid99!current!pwd!!86400!!2!MbRDxYi.9Du0eYkepc1fmGlm22lfwAeWCs2N.138wahAxWR6Jr.zaMDwOCcW0iurQYNF.x6l5jZPTxnk-h5RYASnJtzUgPs695tvn3WyEtDBzcybupu1YB8g5ok51iYqFEkWF8UNuElu2zoASJ8XiwUePMYyXTZBH5C-ce7ItC0_ HTTP/1.1

^^^ note the dev.example.com instead of beta.example.com

It seems the Webauth module is wrongly detecting the hostname as the canonical name, rather than reading it from Apache's %HTTP_HOST.

Feels like a bug as I'd expect it to work in this setting too. I haven't found a configuration setting to force Webauth to set a specific hostname (I could have forced it to %0)

RAVEN076 in master TODO list

RAVEN094 in master TODO list

RAVEN059 in master TODO list

While testing Apache plugins isn't easy, a comprehensive test suit is really needed for this code. Without it, it's difficult to check if a proposed change will break anything which makes accepting pull requests difficult.