well-known pages

[jjg-123]

As per msalle and specs https://datatracker.ietf.org/doc/html/rfc8414#section-3 or https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig, OA4MP is not compliant in that the discovery servlet that generates all the well-known pages on the fly is not in the expected location.

[jjg-123]

The intent was that admins would have a set of redirects or rewrite rules, since OA4MP often resides behind a dedicated authorization facade (e.g. CILogon).

This needs to take into account any virtual organizations that are created. The Discovery servlet which is accessible at oauth2/.well-known will create these. Each virtual organization would require potentially a separate rewrite rule.

Document how to do this explicitly. More recent Tomcats allow for using a rewrite valve (e.g. http://tonyjunkes.com/blog/a-brief-look-at-the-rewrite-valve-in-tomcat-8/). Another option is to have a landing index.jsp in a .well-known directory for the system with a single line redirect in it like

<% response.sendRedirect("/oauth2/.well-known"); %>

This note is to explore the side effects of this and ponder if there is a simpler general solution. In particular, if OA4MP is part of a larger deploy, this machinery should not be automatic since it may interoperate badly with the ambient service.

[jjg-123]

There are two ways to do this in Tomcat. One is to have a .well-known servlet that forwards to OA4MP's Discovery servlet. This requires a second deployment of a server. The other is to allow for the rewrite valve to forward requests to the discovery servlet. This would allow for request to https://host.domain/.well-known/openid-configuration/issuer to be serviced by https://host.domain/oauth2/.well-known/openid-configuration/issuer. The latter requires some potentially serious configuration of the service before use. The former allows generally for a .well-known service to be deployed in Tomcat that happens to be OA4MP aware.