github
/
spring-security
mirror of https://github.com/spring-projects/spring-security


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145
							<!--
 * ========================================================================
 * 
 * Copyright 2004 Acegi Technology Pty Limited
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 * 
 * ========================================================================
-->

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<title>Acegi Security Suggested Steps</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>

<body>
  <h1>Suggested Steps</h1>
  <p>Presented below are the steps we encourage you to take in order to gain the most
  out of Acegi Security in a realistic timeframe.
  <ol>
    <li>Your first step is to ensure you're able to actually build Acegi Security. This is
	because if you encounter any problems the first thing we'll probably suggest you do is
	upgrade to the latest CVS HEAD. It also means you can try things out if you get stuck,
	such as adding even more logging messages to the actual Acegi Security core code.
	The good news is building is actually very easy, and
	we've gone to a lot of trouble to document what is involved. If you have a working Maven
	installation, it <i>should</i> be as simple as two commands. Have a look on the
	<a href="building.html">Building with Maven</a> page, and follow the
	"Checking Out from CVS", "Installing commons-attributes-plugin", and 
	"Building All JARs" steps. Of course, you can safely skip
	this step if you don't have time.<br><br>
	
	Estimated time: 30 minutes - 2 hours.<br><br>
	</li>
	
	<li>Next up gain a proper understanding of how the Contacts Sample application works.
	This will probably involve deploying <code>acegi-security-sample-contacts-filter.war</code>.<br><br>
	
	The actual <a target="_blank" class="newWindow" href="multiproject/acegi-security-sample-contacts/xref/index.html">java code</a>
	is a completely standard Spring application, except <code>ContactManagerBackend</code>
	which shows how we create and delete ACL permissions. The rest of the Java code has no
	security awareness, with all security services being declared in the XML files
	(don't worry, there aren't any new XML formats to learn: they're all standard Spring IoC container
	declarations or the stock-standard <code>web.xml</code>). The main
	XML files to review are
	<a target="_blank" class="newWindow" href="http://cvs.sourceforge.net/viewcvs.py/acegisecurity/acegisecurity/samples/contacts/src/main/webapp/filter/WEB-INF/applicationContext-acegi-security.xml?view=auto">applicationContext-acegi-security.xml</a> (from the filter webapp),
	<a target="_blank" class="newWindow" href="http://cvs.sourceforge.net/viewcvs.py/acegisecurity/acegisecurity/samples/contacts/src/main/webapp/common/WEB-INF/applicationContext-common-authorisation.xml?view=auto">applicationContext-common-authorisation.xml</a>,
	<a target="_blank" class="newWindow" href="http://cvs.sourceforge.net/viewcvs.py/acegisecurity/acegisecurity/samples/contacts/src/main/webapp/common/WEB-INF/applicationContext-common-business.xml?view=auto">applicationContext-common-business.xml</a> (just note we add <code>contactManagerSecurity</code> to the services layer target bean), and
	<a target="_blank" class="newWindow" href="http://cvs.sourceforge.net/viewcvs.py/acegisecurity/acegisecurity/samples/contacts/src/main/webapp/filter/WEB-INF/web.xml?view=auto">web.xml</a> (from the filter webapp).
	The XML definitions are comprehensively discussed in the
	<a href="reference.html">Reference Guide</a>.
	<br><br>
		
	To gain the most from reviewing these XML files, we suggest you start by understanding how
	authentication takes place. There's not much point knowing all about authorisation until authentication is
	really clear, especially the interaction between the <code>ContextHolder</code>, the
	authentication mechanism (such as <code>AuthenticationProcessingFilter</code>), the
	authentication commencement process (specifically <code>SecurityEnforcementFilter</code> and
	say <code>AuthenticationProcessingFilterEntryPoint</code>), and the system that manages authentication
	data between invocations (say <code>HttpSessionIntegrationFilter</code>). You don't have to
	know every detail, just basically what they do and the key differences (again, the
	reference guide should help considerably, as there are diagrams etc).
	<br><br>	
		
	Once you understand authentication in the contacts Sample application, look at how authorisation
	is handled. Start with <code>FilterSecurityInterceptor</code>'s role and how its
	regular expression or Ant paths protect URIs. Next up explore how <code>RoleVoter</code>
	works in our sample application with the <code>FilterSecurityInterceptor</code> and
	<code>MethodSecurityInterceptor</code>. Finally, review what the
	<code>BasicAclEntryVoter</code> does in our sample application, in terms of protecting
	domain objects from method invocations the principal does not have permission to.
	
	<br><br>Lastly, get an understanding of how the <code>AfterInvocationProviderManager</code>
	is being used to stop domain objects being returned to which the principal has no
	permission, and to filter <code>Collection</code>s so they don't contain domain objects to
	which the principal has no permission. By all means comment out parts of the Spring IoC XML
	and see the effect. For example, comment out the <code>AfterInvocationProviderManager</code> (of course, remove its reference
	in the <code>MethodSecurityInterceptor</code>) and see how all of the contacts get returned.
	<br><br>
	
	Please note the release ZIP files do not include the sample application Java source code. You
	will need to download from CVS if you would like to access the Java sources.<br><br>
	
	Estimated time: 1-2 days.<br><br>
	</li>
	
	<li>By now you will have a good grasp on how Acegi Security works, and all that is left to
	do is design your own application's implementation. The way we suggested you explore the Contacts Sample
	is the same way we suggest you implement security in your own application: start with authentication,
	then add basic web request URI security. Follow it with the standard role voter to protect
	method invocations. Finally, and only if your application actually needs it, introduce
	domain object security with the <code>BasicAclEntryVoter</code> and 
	<code>AfterInvocationProviderManager</code>.
	<br><br>
		
	We do not encourage you to use CAS, container adapters, BASIC authentication, transparent
	RMI invocation, run-as replacement, rich client integration or any of the other interesting features
	of Acegi Security until you've got a "bare bones" installation working with <code>DaoAuthenticationProvider</code>,
	one of Acegi Security's <code>AuthenticationDao</code>s (or your own), and your basic
	authorisation configuration. Like anything, start with something simple and build on it
	(this would be the opposite advice if you were building your own security framework,
	where you would need to cross the highest and most difficult bridges first, to check they
	are actually possible).<br><br>
	
	If you've followed the steps above, and refer back to the 
	<a href="reference.html">Reference Guide</a>, 
	<a href="http://www.springframework.org">forums</a>, and 
	<a href="faq.html">FAQ</a>
	for help, you'll find it pretty easy to implement Acegi Security in your application.
	Most importantly, you'll be using a security framework that offers you complete container
	portability, flexibility, and community support - without needing to write and maintain your
	own code.<br><br>
	
	Estimated time: 1-5 days.<br><br>
	</br>
	</li>
	
  </ol>
  
  <p>Please note the time estimates are just that: estimates. They will vary considerably depending
  on how much experience you have, particularly with Java and Spring. They will also vary depending
  on how complex your intended security-enabled application will be. Some people need to push the domain
  object instance access control list capabilities to the maximum, whilst others don't even need anything
  beyond web request URI security. The good thing is Acegi Security will either directly support your future
  needs, or provide a clearly-defined extension point for addressing them.
  
  <p>
  We welcome your feedback about how long it has actually taken you to complete each step, so we
  can update this page and help new users better assess their project timetables in the future.
  Any other tips on what you found helpful in learning Acegi Security are also very welcome.
</body>
</html>