https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/AAA-14 aaa <p>The ClaimAuthFilter expects authentication data provided by an HTTP proxy to populate the data served by certain ServletRequest and HttpServlet request getters (i.e. getRemoteUser(), getAuthType(), getAttribute(), etc.).</p> <p>This data was transported using the AJP protocol and extraced by the servlet AJP handlers. A migration to Jetty away from Tomcat is underway. Tomcat fully supports AJP as well as earlier Jetty versions. But Jetty has now deprecated and removed AJP protocol support. Therefore an alternate method of transporting the HTTP proxy metadata is needed as well as being able to maintain using the defined servlet API (i.e. getRemoteUser(), getAuthType(), getAttribute(), etc.).</p> <p>The proposed solution is to transport the metadata formerly carried in the AJP protocol in the HTTP protocol instead via extension HTTP headers and then add a servlet filter wrapping the HttpServletRequest which will override the methods in question to extract the data from the HTTP extension headers.</p> <p>Operating System: All<br/> Platform: All</p> AAA-14

AJP protocol not supported with current Jetty, servlet attributes not populated

Bug Resolved Done John Dennis John Dennis Fri, 19 Sep 2014 12:18:13 +0000 Thu, 21 Mar 2019 11:56:50 +0000 Tue, 15 Dec 2015 10:51:03 +0000 General 0 3 <p>John, I believe that you already fixed this defect, correct?</p> <p>Hi Wojciech, yes this was fixed, but I don't believe it was every fully tested.</p> <p>Hi John, this would seem to be fairly fundamental to the ClaimAuthFilter and thus AAA working. Given that we've moved to jetty, and AAA appear to be functioning as expected/previously, could we see this as resolved. Alternatively, what specific testing/verification would you suggest?<br/> Thanks.</p> <p>There are multiple ways one can deploy with respect to authentication. We often advocate a deployment configuration where authentication and user attribute retrieval is handled in Apache because it is an easier integration for organizations that already have existing mechanisms in place. It's also easier for simple applications which do not want to handle the complexity of associated with authentication and user attribute retrieval. This was the rationale behind providing SSSD integration. This is all spelled out in great detail in the documentation associated with this work:</p> <p>aaa-authn-api/src/main/docs/sssd_configuration.rst <span class="error">&#91;1&#93;</span></p> <p>The reason it wasn't fully tested is because not everything was fully working in aaa when I finished the work, in other words aaa had not be fully integrated in Opendaylight at the time. What needs to happen is for someone to set up this deployment configuration and exercise it. The individual pieces were all tested in isolation, but never as a completely integrated.</p> <p><span class="error">&#91;1&#93;</span> I have a PDF version of that doc on my Fedora page. I think this PDF is identical to what is in the source code referenced above. One should not depend on this link as a permanent location or current version, but (today) if you want to take a peek at the doc without having to format the rst it will help you.</p> <p>opps, forgot the PDF link:</p> <p><a href="https://jdennis.fedorapeople.org/doc/sssd_configuration.pdf" class="external-link" target="_blank" rel="nofollow noopener">https://jdennis.fedorapeople.org/doc/sssd_configuration.pdf</a></p> Development External issue ID 1977 External issue URL Rank 0|i023kf: