readme.txt 2.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051
  1. ===============================================================================
  2. QUICK-START SAMPLE
  3. ===============================================================================
  4. Acegi Security's flexibility can be a bit daunting. Because projects only have
  5. so much budget, and people only have so much time, often the complexity of
  6. getting started can seem too high a price to pay. The quick-start sample is
  7. designed to provide you the basic building blocks needed to be added to your
  8. existing application.
  9. Quick-start is not executable or deployable. It's just a convenient, simple
  10. place where you can see what needs to be added to your web application's
  11. existing files and directories.
  12. What you _will_ need to change in the quick-start configuration:
  13. - It protects a /secure directory from HTTP requests. The /secure directory
  14. is included (along with a debug.jsp you might find useful), but can be
  15. deleted as soon as you are up and running. You'll need to setup your own
  16. URLs to protect in the applicationContext.xml. Search for the
  17. FilterInvocationInterceptor bean.
  18. What you _may_ need to change in the quick-start configuration:
  19. - It uses an in-memory list of users as your authentication repository. This
  20. means you edit the XML file to add users, change their roles etc. If you'd
  21. prefer to use a database, remove the InMemoryDaoImpl from the
  22. applicationContext.xml, and add in a JdbcDaoImpl bean. For an example of
  23. using the JdbcDaoImpl, search the reference guide.
  24. What does this buy you? Not a great deal more than using the Servlet spec
  25. (although we do support regular expressions and Ant paths for URL matching)!
  26. Seriously, you can use the Servlet spec to protect URLs, so why bother?
  27. The quick-start sample provides you the BASE security building blocks for
  28. your application. Whilst there's nothing wrong with using it instead of the
  29. Servlet spec security just for the better path support or avoiding the
  30. multitude of container authentication configurations, most people will use it
  31. because this foundation allows you to simply tweak configuration if you wish
  32. to:
  33. - Protect your business beans (search for MethodSecurityInterceptor in docs)
  34. - Use enterprise-wide single sign on (see CAS section in docs)
  35. - Use custom authorization voters (see Authorization section in docs)
  36. - Deploy custom authentication providers (see Authentication section in docs)
  37. - Perform BASIC authentication (search for BasicProcessingFilter in docs)
  38. - Automate HTTPS redirection (see Channel Security section in docs)
  39. Good luck! Don't forget we're happy to help. See the end of the docs for
  40. contact details.
  41. $Id$