Basic and Digest authentication for a RESTful Service with Spring Security 3.1, part 6 | Javalobby

Basic and Digest authentication for a RESTful Service with Spring Security 3.1, part 6 | Javalobby

• Bootstrapping a web application with Spring 3.1 and Java based Configuration
• Building a RESTful Web Service with Spring 3.1 and Java based Configuration
• Securing a RESTful Web Service with Spring Security 3.1
• RESTful Web Service Discoverability
• REST Service Discoverability with Spring

• Basic and Digest authentication
• <http-basic />
• BasicAuthenticationFilter
• BasicAuthenticationEntryPoint
• Satisfying the stateless constraint – getting rid of sessions
• One of the main constraints of the RESTful architectural style is that the client-server communication is fully stateless, as theoriginal dissertation reads:
• 5.1.3 Stateless
• We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
• Configuration of Digest Authentication
• Unfortunately there is no support in the security namespace to automatically configure the digest authentication the way basic authentication can be configured with <http-basic>. Because of that, the necessary beans had to be defined and wired manually into the security configuration.
• Anonymous request
• Request with authentication credentials

Conclusion

This article covered the configuration and implementation of both Basic and Digest authentication for a RESTful service, using mostly Spring Security 3.0 namespace support as well as some new features added by Spring Security 3.1. In the next articles I will focus on OAuth authentication. In the meantime, check out the github project.

InfoQ: APIs Can Be a Pain

InfoQ: APIs Can Be a Pain: Boris Lublinsky
APIs are a Pain: SUBBU ALLAMARAJU
The Object Network

About Allamaraju

http://www.flickr.com/photos/subbu_allamaraju/3583889734/

Subbu Allamaraju | LinkedIn

I work with code, networking and Web protocols, REST and HTTP. Based on the work I did at Yahoo!, I wrote "RESTful Web Services Cookbook", published by O'Reilly in 2010.

RESTful Web Services Cookbook - O'Reilly Media

Points by Allamaraju

Writing HTTP client code to talk to APIs is verbose, repetitive, chatty and slow. This is in addition to addressing latency and bandwidth constraints and core functionality of the client app – such as building a snappy UI or supporting some other business use case.

• First - the interface mismatch
• Second - writing client code is slow, repetitive and verbose
• Third - Getting enhancements you need from producer teams slows you down
• Fourth - request for use cases like this are chatty
• Fifth - consistent RESTful APIs don't matter as much as we think

Solution by Allamaraju

• Bring down number of lines of code to call APIs
• Automatically orchestrate API call as needed
• Create new consumer-centric APIs that wrap existing producer-centric APIs
• Cut down bandwidth usage and latency

Best of all, this platform will soon be on github.

Beyond the Node: Arkestration with Noah | Javalobby

Beyond the Node: Arkestration with Noah | Javalobby


I like these words:

No longer can we treat our infrastucture as a mass of isolated systems.



It's the first time I see Noah.

Noah is an application that provides a RESTful centralized service for managing various aspects of dependent resources and distributed components. It can be used as service registry, a configuration store and much more. It can integrate with existing tools such as Puppet, Chef and Nagios as well as your own applications.

The REST with Spring series

Bootstrapping a web application with Spring 3.1 and Java based Configuration, part 1 | baeldung
Others:

• Part 2 – Building a RESTful Web Service with Spring 3.1 and Java based Configuration
• Part 3 – Securing a RESTful Web Service with Spring Security 3.1
• Part 4 – RESTful Web Service Discoverability
• Part 5 – REST Service Discoverability with Spring

Spring 3.1.0.BUILD-SNAPSHOT

• The Spring framework snapshot repository is included so that Maven will be able to access the latest Spring snapshots – 3.1.0.BUILD-SNAPSHOT. 
• http://maven.springframework.org/snapshot
• I’m using the snapshots for this post because some really useful stuff has been added since 3.1.0.M2, especially in the area of Java based configuration for MVC. 
• For the purposes of this post however, 3.1.0.M2 works fine, as none of the new additions are in use for the bootstrapping part. 
• In order to use this version, the snapshot repository should be replaced with:
• http://maven.springframework.org/milestone

CGLIB

• Why CGLIB is a dependency?
• The entire configuration cannot function without it.
• If removed, Spring will throw:
• java.lang.IllegalStateException:
• CGLIB is required to process @Configuration classes.
• Either add CGLIB to the classpath or remove the following @Configuration bean definitions
• @Configuration
• Effective
• Configuration classes should not be final
• They should have a constructor with no arguments
• 4. The IoC container, 4.12 - Java-based container configuration
• @ImportResource
• Is used to import the existing XML based Spring configuration.
• This may be configuration which is still being migrated from XML to Java
• Or simply legacy configuration that you wish to keep.
• Either way, importing into the Container is essential for a successful migration, allowing small steps without too much risk.
• Equivalent XML annotation:
• <import resource="classpath*:/rest_config.xml"/>