[AAA-14] AJP protocol not supported with current Jetty, servlet attributes not populated Created: 19/Sep/14 Updated: 21/Mar/19 Resolved: 15/Dec/15 |
|
| Status: | Resolved |
| Project: | aaa |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | John Dennis | Assignee: | John Dennis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 1977 |
| Description |
|
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.). 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.). 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. |
| Comments |
| Comment by Wojciech Dec [ 20/Mar/15 ] |
|
John, I believe that you already fixed this defect, correct? |
| Comment by John Dennis [ 20/Mar/15 ] |
|
Hi Wojciech, yes this was fixed, but I don't believe it was every fully tested. |
| Comment by Wojciech Dec [ 23/Mar/15 ] |
|
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? |
| Comment by John Dennis [ 23/Mar/15 ] |
|
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: aaa-authn-api/src/main/docs/sssd_configuration.rst [1] 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. [1] 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. |
| Comment by John Dennis [ 23/Mar/15 ] |
|
opps, forgot the PDF link: |