146 lines
8.9 KiB
HTML
146 lines
8.9 KiB
HTML
<!--
|
|
* ========================================================================
|
|
*
|
|
* 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>
|