Spring/spring-security
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

More documentation updates.

Browse Source
This commit is contained in:
Ben Alex
2004-12-23 00:15:00 +00:00
parent b2e035424a
commit c8055b57d7
5 changed files with 159 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

111
doc/xdocs/faq.html
View File

@@ -29,8 +29,105 @@
<body>
<h1>Frequently Asked Questions</h1>
<h2>What is Acegi Security?</h2>
<p>Acegi Security is an open source project that provide comprehensive authentication
and authorisation services for enterprise applications based on
<a href="http://www.springframework.org">The Spring Framework</a>.
Acegi Security can authenticate using a variety of pluggable providers, and
can authorise both web requests and method invocations.
Acegi Security provides an integrated security approach across
these various targets, and also offers access control list (ACL) capabilities to
enable individual domain object instances to be secured. At an implementation
level, Acegi Security is managed through Spring's inversion of control and
lifecycle services, and actually enforces security using interception through
servlet Filters and Java AOP frameworks. In terms of AOP framework support, Acegi
Security currently supports AOP Alliance (which is what the
Spring IoC container uses internally) and AspectJ, although additional frameworks
can be easily supported.</p>
<h2>Why not just use web.xml security?</h2>
<p>Let's assuming you're developing an enterprise application based on Spring.
There are four security concerns you typically need to address: authentication,
web request security, service layer security (ie your methods that implement
business logic), and domain object instance security (ie different domain objects
have different permissions). With these typical requirements in mind:
<ol>
<li><b>Authentication</b>: The servlet specification provides an approach
to authentication. However, you will need to configure the container
to perform authentication which typically requires editing of
container-specific "realm" settings. This makes a non-portable
configuration, and if you need to write an actual Java class to implement
the container's authentication interface, it becomes even more non-portable.
With Acegi Security you achieve complete portability - right down to the
WAR level. Also, Acegi Security offers a choice of production-proven
authentication providers and mechanisms, meaning you can switch your
authentication approaches at deployment time. This is particularly
valuable for software vendors writing products that need to work in
an unknown target environment.<br><br></li>
<li><b>Web request security:</b> The servlet specification provides an
approach to secure your request URIs. However, these URIs can only be
expressed in the servlet specification's own limited URI path format.
Acegi Security provides a far more comprehensive approach. For instance,
you can use Ant paths or regular expressions, you can consider parts of the
URI other than simply the requested page (eg you can consider request
parameters), and you can implement your own runtime source of configuration
data. This means your web request security can be dynamically changed during
the actual execution of your webapp.<br><br></li>
<li><b>Service layer and domain object security:</b> The absence of support
in the servlet specification for services layer security or domain object
instance security represent serious limitations for multi-tiered
applications. Typically developers either ignore these requirements, or
implement security logic within their MVC controller code (or even worse,
inside the views). There are serious disadvantages with this approach:<br><br>
<ol>
<li><i>Separation of concerns:</i> Authorization is a
crosscutting concern and should be implemented as such.
MVC controllers or views implementing authorization code
makes it more difficult to test both the controller and
authorization logic, more difficult to debug, and will
often lead to code duplication.</li>
<li><i>Support for rich clients and web services:</i> If an
additional client type must ultimately be supported, any
authorization code embedded within the web layer is
non-reusable. It should be considered that Spring remoting
exporters only export service layer beans (not MVC
controllers). As such authorization logic needs to be
located in the services layer to support a multitude of
client types.</li>
<li><i>Layering issues:</i> An MVC controller or view is simply
the incorrect architectural layer to implement authorization
decisions concerning services layer methods or domain object
instances. Whilst the Principal may be passed to the services
layer to enable it to make the authorization decision, doing
so would introduce an additional argument on every services
layer method. A more elegant approach is to use a ThreadLocal
to hold the Principal, although this would likely increase
development time to a point where it would become more e
conomical (on a cost-benefit basis) to simply use a dedicated
security framework.</li>
<li><i>Authorisation code quality:</i> It is often said of web
frameworks that they "make it easier to do the right things,
and harder to do the wrong things". Security frameworks are
the same, because they are designed in an abstract manner for
a wide range of purposes. Writing your own authorization code
from scratch does not provide the "design check" a framework
would offer, and in-house authorization code will typically
lack the improvements that emerge from widespread deployment,
peer review and new versions.
</ol>
</li>
</ol>
For simple applications, servlet specification may just be enough.
Although when considered within the context of web container portability,
configuration requirements, limited web request security flexibility, and
non-existent services layer and domain object instance security, it becomes
clear why developers often look to alternative solutions.
</p>
<h2>How do you pronounce "Acegi"?</h2>
<p><i>Ah-see-gee</i>. Said quickly, without emphasis on any part.</p>
<p><i>Ah-see-gee</i>. Said quickly, without emphasis on any part.
Acegi isn't an acronym, name of a Greek God or anything similarly
impressive - it's just letters #1, #3, #5, #7 and #9 of the alphabet.</p>
<h2>Is it called "Acegi" or "Acegi Security"?</h2>
<p>It's official name is <i>Acegi Security System for Spring</i>,
@@ -39,7 +136,7 @@
as that gets confused with the name of the company that maintains Acegi
Security.</p>
<h2>Why catches 80% of users reporting problems?</h2>
<h2>What catches 80% of users reporting problems?</h2>
<p>80% of support questions are because people have not defined
the necessary filters in <code>web.xml</code>, or the filters are being
mapped in the incorrect order. Check the
@@ -55,11 +152,6 @@
<code>UserDetails</code> object generated by your <code>AuthenticationDao</code>
to the log and check it looks correct.</p>
<h2>How do I store custom properties, like a user's email address?</h2>
<p>In most cases write an <code>AuthenticationDao</code> which returns
a subclass of <code>User</code>. Alternatively, write your own
<code>UserDetails</code> implementation from scratch and return that.</p>
<h2>I need some help. What files should I post?</h2>
<p>The most important things to post with any support requests on the
<a href="http://forum.springframework.org">Spring Forums</a> are your
@@ -82,6 +174,11 @@
log4j.category.net.sf.acegisecurity=DEBUG</pre>
<h2>How do I store custom properties, like a user's email address?</h2>
<p>In most cases write an <code>AuthenticationDao</code> which returns
a subclass of <code>User</code>. Alternatively, write your own
<code>UserDetails</code> implementation from scratch and return that.</p>
<h2>Why doesn't Acegi Security use JAAS?</h2>
<p>Acegi Security targets <i>enterprise applications</i>, which are typically
multi-user, data-oriented applications that are important to