0

I have a a custom authentication provider implemented in my spring MVC project. In my own over-riding authenticate() method I implement my own authentication where I construct my own UserPasswordAuthenticationToken() and return the object.

Now the userid in the above said object "UserPasswordAuthentictionToken" is anonymized, password null and the permissions are set to those that are granted to this user.

Question:
Does this cause the SecurityContextHolder or the SecurityContext in general to lose the original incoming credentials inside the Authenticate object that is passed to the overridden authenticate() method?

If it does not, what should I do to drop those original credentials and force Spring security context to hold my new anonymous authentication identifier [preferably along with other meta data ofcourse].

Ace
  • 1,501
  • 4
  • 30
  • 49
  • so the authentication provider is authenticating the user based on username and password, but then clears the username (the password is already cleared by spring security by default) and keeps the granted permissions, is this correct? if so can you let us know why this is being done (why the username is being cleared), as on a first look there would be no good reason to do that. spring security supports anonymous authentication, but that is something different than what you mention http://docs.spring.io/spring-security/site/docs/3.0.x/reference/anonymous.html – Angular University Mar 14 '14 at 22:14
  • @jhadesdev You are right in every sense. That's exactly what I am trying to do. The reason why I am doing this is to prevent using username for business logic. Not a big deal but any developers can use jdwp [Java Debug wire protocol] to get hold of username. I fear there is a security loophole with jdwp [Java debug wire protocol]. I need to read that anonymous authentication link you provided but my login page IS configured for anonymous authentication. – Ace Mar 14 '14 at 22:21

1 Answers1

0

There is actually no danger that the Java remote debugging functionality (JDWP) represents a security hole in production, because it is off by default.

The only way that this could happen would be if someone turns it on explicitly in production, but the production team would probably never allow it, and they are the only ones with administration capabilities on that machine.

To turn on debugging in production, someone would have to add these parameters to the server launch script, or set them via the console:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=<PORT>

This could not happen accidentally. You can confirm that JDWP is disabled in production by trying to create a debug remote connection to the production machine using your IDE, it should fail. Before trying, it's best to disable all breakpoints, just in case.

If JDWP is enabled in production for some reason, the production team can configure the firewall of the server to only allow connections to the JDWP port if the come from a certain acceptable list of IPs, preventing the developers from remote debugging production and accessing confidential information.

Angular University
  • 42,341
  • 15
  • 74
  • 81
  • I like your answer but when it comes to security I don't like to leave it to providence of god :) It is not too hard to 'accidentaly' push a war to production with debug lines generated into it. Id rather make an overkill with security than be sorry later on. The only time I would worry about not doing this is when the cryptography poses a performance bottleneck - either on client side or on the servers. – Ace Mar 14 '14 at 22:49
  • Having said that Im going to drag the focus back on to my question. How do I drop the original login credentials from SecurityContextHolder and replace it with my anonymous identifiers and meta-data? – Ace Mar 14 '14 at 22:51