Announcement Announcement Module
No announcement yet.
HTTP filter Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • HTTP filter

    2 questions from contact.sample app.
    1 How would I know to use an AuthenticationProcessingFilter?
    2 What glues it into the authentication app? My guess is b/c of the type filter, web.FilterSecurityInterceptor??

    I still don't know how would have known to use the AuthenticationProcessingFilter



  • #2
    You need an authentication mechanism, which is responsible for:

    1. Retrieving the principal's credential from request
    2. Testing via an AuthenticationManager they're correct
    3. If invalid, notifying user
    4. If valid, putting credentials into ContextHolder

    There are a variety of authentication mechanisms bundled with Acegi Security. They appear under net.sf.acegisecurity.ui (as they provide a user interface to authentication).

    Most applications use (but are not required to use) SecurityEnforcementFilter. This catches any Acegi Security related exceptions and either sends a "forbidden" (403) response or launches what is called an AuthenticationEntryPoint. Each authentication mechanism provides an AuthenticationEntryPoint, which does something to the HttpServletResponse so that the user can authenticate. In the case of form-based authentication, the applicable AuthenticationEntryPoint is called AuthenticationProcessingFilterEntryPoint. The implementation simply redirects to a login form. The BasicProcessingFilterEntryPoint and DigestProcessingFilterEntryPoint, on the other hand, sends differents HTTP headers to cause the user agent to authenticate via that mechanism. CasProcessingFilterEntryPoint redirects to a CAS server and advises a callback URL the CAS server will use.

    Hope this offers a bit more explanation on how everything ties together. You can also read a bit more at