|
@@ -0,0 +1,138 @@
|
|
|
|
+<!--
|
|
|
|
+ * ========================================================================
|
|
|
|
+ *
|
|
|
|
+ * 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" 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-authorization.xml?view=auto">applicationContext-common-authorization.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 authorization 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>
|
|
|
|
+
|
|
|
|
+ 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 reference guide, forums, and FAQ
|
|
|
|
+ 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>
|