REST with SpringMVC - Passing params in request body

Lately I was trying to pass parameters to a SpringMVC REST service. In order to do that I used @RequestParameter annotation in a method implementing my service.

Sample service method for updating user email could look as follows:

@RequestMapping(method=RequestMethod.POST, value="/user/{username}")
public String updateUser(HttpServletResponse response,
                         @PathVariable("username") String username,
                         @RequestParameter("email") String email)
{
     // UPDATE USER EMAIL HERE
}

As you can see expected request parameter is defined as method parameter and annotated with @RequestParameter specifying the parameter name. Originally it seemed that this approach only works when parameters are passed as URL params but doesn't when params are passed in request body i.e. the following HTTP request would work:

POST http:///user/?email=test%40example.com HTTP/1.1
Host: 
(...)

whereas the following would not:

POST http:///user/ HTTP/1.1
Host: 
(...)

email=test%40example.com

When I start googling for this issue I found several opinions stating that this is a known bug and suggesting some workarounds e.g. using @RequestBody annotation and manually extracting parameter values from the body string.

However, the issue disappears if you specify the content type as one of the request headers:

Content-Type: application/x-www-form-urlencoded

After I added this to my http request both url and body params are captured with @RequestParameter annotation.

Cross-domain Single Sign On with OpenAM

OpenAM is an open-source solution for access management i.e. authentication, authorization and more. It's maintained by ForgeRock, which took over the project after Sun abandoned it. When led by Sun it was called OpenSSO.

I was recently responsible for installation & configuration of OpenAM. We use it at one of the project to provide cross-domain Single Sign On (CDSSO). At first it seemed to be a complex but relatively straightforward task but as it came out later on, it can give you a serious headache when you try to achieve smth different than default.

Below is the short summary of pros & cons:

Pros:

• It's a quite mature solution that is built upon its ancestor OpenSSO
• Experienced users can benefit from its reach configuration options
• Built-in support for multiple user data stores (LDAP, db, ...).
• Out-of-the-box support for SAML2 protocol
• Portability (100% java)
• Built-in support for multi-instance configuration (for Load Balancing)

Cons:

• Very poor documentation - most of the information about the product installation and configuration is available at the Wiki page in form of short, informal articles. Most of the useful information you find on the old OpenSSO specification pages hosted by Sun so you can never be sure if that info is still relevant with the latest version of OpenAM.
• No community - there is actually no real community of people using that solution. This means there is no fora you can search for advise. There is only an oldschool mailing list with very limited usability
• Not that flexible - although quite complex configuration is available sometimes I felt limited, especially when trying to implement smth different than defualt e.g. custom login screens.

As you have probably noticed I got a bit frustrated about the "Cons" and described them in much more details than "Pros" ;) I'm not saying it's a bad product but it certainly requires a lot of experience & knowledge of its features. The most painful part is the lack of decent documentation. We even got ourselves this Book but it covers only basic topics.

Be aware that doing anything different than default may require some custom tweaks or not even be possible. If you plan to implement something that is not described in basic tutorials consider other solution first.

If you want to use SAML 2.0 functionality offered by OpenAM I would recommend you to read my tutorial on how to achieve IdP initiated SSO and Identity Federation with OpenAM and SAML.

Here are some links to other useful resources:

1. OpenAM wiki
2. Different deployment options
3. Troubleshooting OpenAM (recommended!)

STS - Waiting for changelog lock...

Problem:

When starting TC server that comes with SpringSource Tool Suite (STS) I'm getting the following message and the serer doesn't start:
"Waiting for changelog lock..."


Solution:

Delete folder:
$TCSERVER_HOME/spring-insight-instance/insight/data
and retry. That's it.