Announcement Announcement Module
Collapse
No announcement yet.
Appropriate Way To Secure @ResponseBody method=Get Requests With Embedded Credentials Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Appropriate Way To Secure @ResponseBody method=Get Requests With Embedded Credentials

    Hello friends -

    I've been tasked with writing a tablet application that will live outside the firewall to communicate with a server end piece inside the firewall. For the server component, I'm working on Spring 3.1. I have successfully configured Spring-Security for the server end and several @ResponseBody style services returning with jaxb/xml marshalled data from HttpGet requests. At this time, an android tablet looks to be the likely candidate, though iOS hasn't been ruled out. (not my decision).

    Unfortunately, to expose my @ResponseBody methods for testing purposes, I excluded their paths from the spring security all together with http pattern / security="none". For a variety of reasons, it isn't likely I will be able to get my entire application exposed beyond the firewall, but specific calls will be made visible. That being said, I'm trying to find the right set of spring legos to try something like this:

    1) Tablet makes authentication request, success gets back a user definition / token.
    2) Tablet makes subsequent calls to other urls@GET with embedded user details.

    It looked like Spring-WS has something like this with the digester and embedded components, but I was hoping to find a middle ground that allowed me to keep the relative simplicity of @ResponseBody implementation and return XML data without the overhead of a full blown SOAP service layer.

    I looked briefly at the @Pre and @Post annotations, but they seem to only want to be able to deal with authentication states that won't be understood from a stateless request. I'm willing to try to write something myself to handle this, but figured I might not be clever enough in my poking around to find a solution that already exists in Springland.

    Any insight is appreciated.

    brian
Working...
X