jjg-123
commented
5 months ago 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.
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.