-
Notifications
You must be signed in to change notification settings - Fork 6k
SEC-2006: Allow anonymous authentication to expose Principal in HttpServletRequest #2232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Luke Taylor said: Looks like a duplicate of SEC-1082. As explained there, the intention is that method should mimic the servlet API, which returns null for an unauthenticated user. |
Paul Benedict said: Thanks Luke for responding. SEC-1082 is definitely related. I think, however, this isn't a pure duplicate because I am not asking to change the default behavior; I would like to see a switch that would enable this. I believe that I have a valid use case for this feature. I am using the Anonymous filter to allow a "guest" user (actual username) on my system. My business services are EJB and each invocation requires the user to be identified. The only way to propagate the "guest" identity to the EJB is for the appserver to see there's a getUserPrincipal() present. This is what the Spring Security help tip says for the @username attribute of : "The username that should be assigned to the anonymous request. This allows the principal to be identified, which may be important for auditing and logging." Despite the claim, getUserPrincipal() will not return the principal even though the system is functioning with authentication (just anonymous authentication). As I said, everything in the Anonymous filter works for my "guest" minus no principal. If you don't believe my use case is valid, could you explain why? If this filter is being used inappropriately, what other recourse is there to mimic anonymous users who need the principal present? |
Luke Taylor said: I'm sure your use-case is valid for your system :), but it seems like a corner case to me. I was just pointing out that this has come up before. SecurityContextHolderAwareRequestWrapper is purely intended to mimic the servlet API, which will always return null for an unauthenticated user. Adding extra flags to override this kind of behaviour makes things more complicated and is something I've grown to be wary of when a little bit of customization can achieve the same end. I'll leave it to Rob to decide what's best, since he's in charge now :). |
Rob Winch said: I agree with Luke's feedback. As this is not standard behavior if someone needs this functionality, they can easily add their own HttpServletRequestWrapper without impacting the rest of the application. NOTE: I am linking the two JIRAs because while this is not an exact duplicate of the mentioned JIRA it is very close. |
Rob Winch said: Marking as Won't Fix per previous comments. |
This issue duplicates #1333 |
Paul Benedict (Migrated from SEC-2006) said:
Configuration allows me to set the username but it will not return any Principal for ServletRequest.getUserPrincipal(). This typically makes sense except I need the Authentication object to be exposed to the appserver so my special username gets automatically propagated to the EJB context. I am unable to really use EJBs this way; I am currently needing my own version of the Anonymous filter and SecurityContextHolderAwareRequestWrapper wrapper to work around this.
The text was updated successfully, but these errors were encountered: