Now that we've reviewed the theory, let's see how to use it. To
implement HTTP Digest Authentication, it is necessary to define
DigestProcessingFilter
in the fitler chain. The
application context will need to define the
DigestProcessingFilter
and its required
collaborators:
<bean id="digestProcessingFilter" class="org.springframework.security.ui.digestauth.DigestProcessingFilter"> <property name="userDetailsService" ref="jdbcDaoImpl"/> <property name="authenticationEntryPoint" ref="digestProcessingFilterEntryPoint"/> <property name="userCache" ref="userCache"/> </bean> <bean id="digestProcessingFilterEntryPoint" class="org.springframework.security.ui.digestauth.DigestProcessingFilterEntryPoint"> <property name="realmName" value="Contacts Realm via Digest Authentication"/> <property name="key" value="acegi"/> <property name="nonceValiditySeconds" value="10"/> </bean>
The configured UserDetailsService
is needed
because DigestProcessingFilter
must have direct
access to the clear text password of a user. Digest Authentication
will NOT work if you are using encoded passwords in your DAO. The DAO
collaborator, along with the UserCache
, are
typically shared directly with a
DaoAuthenticationProvider
. The
authenticationEntryPoint
property must be
DigestProcessingFilterEntryPoint
, so that
DigestProcessingFilter
can obtain the correct
realmName
and key
for digest
calculations.
Like BasicAuthenticationFilter
, if
authentication is successful an Authentication
request token will be placed into the
SecurityContextHolder
. If the authentication event
was successful, or authentication was not attempted because the HTTP
header did not contain a Digest Authentication request, the filter
chain will continue as normal. The only time the filter chain will be
interrupted is if authentication fails and the
AuthenticationEntryPoint
is called, as discussed in
the previous paragraph.
Digest Authentication's RFC offers a range of additional features to further increase security. For example, the nonce can be changed on every request. Despite this, Spring Security implementation was designed to minimise the complexity of the implementation (and the doubtless user agent incompatibilities that would emerge), and avoid needing to store server-side state. You are invited to review RFC 2617 if you wish to explore these features in more detail. As far as we are aware, Spring Security's implementation does comply with the minimum standards of this RFC.