diff --git a/src/site/apt/building.apt b/src/site/apt/building.apt new file mode 100644 index 0000000000..cb438e1fd9 --- /dev/null +++ b/src/site/apt/building.apt @@ -0,0 +1,61 @@ + ----------------------- + Building Acegi Security + ----------------------- + + +Building Acegi Security System + +* Checking Out from Subversion (SVN) + + This project uses Maven as project manager + and build tool. We recommend you to install Maven 2.0.4 or greater before trying + the following. + + To checkout Acegi Security from SVN, see our {{{svn-usage.html}SVN Usage}} page. + +* Quick Build + + Often people reading this document just want to see if Acegi Security will work + for their projects. They want to deploy a sample application, and that's about it + (after all, all the reference documentation can be read online at + {{{http://acegisecurity.org}http://acegisecurity.org}}). + In this case, execute: + TODO: Update to use tutorial app and maven 2 + ++----------------------------------------------------------------------------------------------------------------------+ + cd $ACEGI_SECURITY/core (or cd %ACEGI_SECURITY%/core on Windows) + mvn install + cd $ACEGI_SECURITY/samples/contacts + maven multiwar:multiwar + copy $ACEGI_SECURITY/samples/contacts/target/acegi-security-sample-contacts-filter.war $YOUR_CONTAINER/webapps ++----------------------------------------------------------------------------------------------------------------------+ + + Then load up your web container and visit + {{{http://localhost:8080/acegi-security-sample-contacts-filter/}http://localhost:8080/acegi-security-sample-contacts-filter/}} + (or whatever location is appropriate for your web container). + +* Building All JARs + + Sometimes people are already using Acegi Security, and they just want to build the + latest code from CVS. To build all artifacts (JARs) and install them into + your local Maven repository, simply perform a SVN checkout, and then execute: + ++----------------------------------------------------------------------------------------------------------------------+ + cd $ACEGI_SECURITY + mvn install ++----------------------------------------------------------------------------------------------------------------------+ + + You can then check your <<<$HOME/.m2/repository/org/acegisecurity>>> + directory and it should contain all of the latest Acegi Security JARs. + +* Building The Site + + By "site" we mean the web site you can browse at + {{{http://acegisecurity.org}http://acegisecurity.org}}, + which includes the reference documentation and all of the Maven reports. + If you'd like a local copy, simply execute: + ++----------------------------------------------------------------------------------------------------------------------+ + cd $ACEGI_SECURITY + mvn clean site ++----------------------------------------------------------------------------------------------------------------------+ diff --git a/src/site/apt/index.apt b/src/site/apt/index.apt new file mode 100644 index 0000000000..ba754696c3 --- /dev/null +++ b/src/site/apt/index.apt @@ -0,0 +1,215 @@ + -------------------------------- + Acegi Security System for Spring + -------------------------------- + +What is Acegi Security? + + Acegi Security is a powerful, flexible security solution for enterprise software, + with a particular emphasis on applications that use + {{{http://www.springframework.org/}Spring}}. Using Acegi Security provides your + applications with comprehensive authentication, authorization, instance-based access control, + channel security and human user detection capabilities. + +Key Features + + * <> Acegi Security 1.0.0 was released in May 2006 after + more than two and a half years of use in large production software projects, 70,000+ downloads + and hundreds of community contributions. + In terms of release numbering, we also use the + {{{http://apr.apache.org/versioning.html}Apache APR Project Versioning Guidelines}} so that you can easily identify release compatibility. + + * <> All APIs are fully documented using + {{{http://acegisecurity.org/multiproject/acegi-security/apidocs/index.html}JavaDoc}}, + with almost 100 pages of + {{{./reference.html}Reference Guide}} documentation providing an easy-to-follow + introduction. Even more documentation is provided on this web site, as + shown in the left hand navigation sidebar. + + * <> View our {{{./suggested.html}suggested steps}} + for the fastest way to develop complex, security-compliant applications. + + * <> Using JA-SIG's open + source {{{http://www.ja-sig.org/products/cas/}Central Authentication Service}} (CAS), + the Acegi Security can participate + in an enterprise-wide single sign on environment. You no longer need + every web application to have its own authentication database. Nor are + you restricted to single sign on across a single web container. Advanced + single sign on features like proxy support and forced refresh of logins + are supported by both CAS and Acegi Security. + + * <> We use Spring application + contexts for all configuration, which should help Spring developers get + up-to-speed nice and quickly. + + * <> In many applications it's + desirable to define Access Control Lists (ACLs) for individual domain + object instances. We provide a comprehensive ACL package with features + including integer bit masking, permission inheritence (including + blocking), a JDBC-backed ACL repository, caching and a pluggable, + interface-driven design. + + * <> The entire security system can operate + within a single web application using the provided filters. There is no + need to make special changes or deploy libraries to your Servlet or EJB + container. + + * <> The credential + collection and authorization capabilities of your Servlet or EJB + container can be fully utilised via included "container adapters". We + currently support Catalina (Tomcat), Jetty, JBoss and Resin, with + additional containers easily added. + + * <> Many applications + need to secure data at the bean level based on any combination of + parameters (user, time of day, authorities held, method being invoked, + parameter on method being invoked....). This package gives you this + flexibility without adding security code to your Spring business + objects. + + * <> Acegi Security can not only protect + methods from being invoked in the first place, but it can also + deal with the objects returned from the methods. Included implementations + of after invocation security can throw an exception or mutate the returned + object based on ACLs. + + * <> In addition to securing + your beans, the project also secures your HTTP requests. No longer is it + necessary to rely on web.xml security constraints. Best of all, your + HTTP requests can now be secured by your choice of regular expressions + or Apache Ant paths, along with pluggable authentication, authorization + and run-as replacement managers. + + * <> Acegi Security can + automatically redirect requests across an appropriate transport channel. + Whilst flexible enough to support any of your "channel" requirements (eg + the remote user is a human, not a robot), a common channel security + feature is to ensure your secure pages will only be available over + HTTPS, and your public pages only over HTTP. Acegi Security also + supports unusual port combinations (including if accessed via an + intermediate server like Apache) and pluggable transport decision + managers. + + * <> Perfect for remoting + protocols or those web applications that prefer a simple browser pop-up + (rather than a form login), Acegi Security can directly process HTTP + BASIC authentication requests as per RFC 1945. + + * <> For greater security than + offered by BASIC authentcation, Acegi Security also supports Digest Authentication + (which never sends the user's password across the wire). Digest Authentication + is widely supported by modern browsers. Acegi Security's implementation complies + with both RFC 2617 and RFC 2069. + + * <> Authentication can be + delegated through to CA's Siteminder solution, which is common in large + corporate environments. + + * <> Acegi Security can easily read + client-side X509 certificates for authenticating users. + + * <> Do you have an LDAP directory? Acegi Security can + happily authenticate against it. + + * <> Your JSP files can use our taglib + to ensure that protected content like links and messages are only + displayed to users holding the appropriate granted authorities. The taglib + also fully integrates with Acegi Security's ACL services, and + obtaining extra information about the logged-in principal. + + * <> You + select the method used to configure your security environment. The + project supports configuration via Spring application contexts, as well + as Jakarta Commons Attributes and Java 5's annotations feature. Some users + (such as those building content management systems) pull configuration data + from a database, which exemplifies Acegi Security's flexible configuration + metadata system. + + * <> We include the ability to + retrieve your user and granted authority definitions from an XML + file, JDBC datasource or Properties file. Alternatively, you can implement the + single-method UserDetailsService interface and obtain authentication details from + anywhere you like. + + * <> Building upon Spring's + ApplicationEvent services, you can write your own listeners + for authentication-related events, along with authorisation-related events. + This enables you to implement account lockout and audit log systems, with + complete decoupling from Acegi Security code. + + * <> Our implementations + have been designed to make it very easy to use your existing + authentication schema and data (without modification). Of course, + you can also provide your own Data Access Object if you wish. + + * <> Acegi Security integrates with Spring's {{{http://ehcache.sourceforge.net}EHCACHE}} factory. + This flexibility means your database (or other authentication + repository) is not repeatedly queried for authentication + information. + + * <> Every critical aspect of the package + has been modelled using high cohesion, loose coupling, interface-driven + design principles. You can easily replace, customise or extend parts of + the package. + + * <> Every critical object dependency and + configuration parameter is validated at application context startup + time. Security configuration errors are therefore detected early and + corrected quickly. + + * <> Does your project use a rich client? Not a + problem. Acegi Security integrates with standard Spring remoting + protocols, because it automatically processes the HTTP BASIC + authentication headers they present. Add our BASIC authentication filter + to your web.xml and you're done. You can also easily use RMI or Digest + authentication for your rich clients with a simple configuration statement. + + * <> Of course, passwords in your + authentication repository need not be in plain text. We support both SHA + and MD5 encoding, and also pluggable "salt" providers to maximise + password security. Acegi Security doesn't even need to see the password + if your backend can use a bind-based strategy for authentication (such as + an LDAP directory, or a database login). + + * <> The system fully supports + temporarily replacing the authenticated principal for the duration of the web + request or bean invocation. This enables you to build public-facing + object tiers with different security configurations than your backend + objects. + + * <> Acegi Security can automatically + transfer its core authentication information from one machine to another, + using a variety of protocols including RMI and Spring's HttpInvoker. + + * <> Even though + Acegi Security can deliver authentication using a range of pluggable mechanisms + (most of which require no web container configuration), we allow you to access + the resulting Authentication object via the getRemoteUser() and other + security methods on HttpServletRequest. + + * <> A must-have of any quality security project, unit + tests are included. Our unit test coverage is very high, as shown in the + {{{multiproject/acegi-security/clover/index.html}coverage report}}. + + * <> This assists you in effectively reusing the Acegi + Security artifacts in your own Maven-based projects. + + * <> We provide a number of classes + that assist with your own unit testing of secured business objects. For + example, you can change the authentication identity and its associated + granted authorities directly within your test methods. + + * <> Whilst nothing is ever completely secure, + using an open source security package leverages the continuous design + and code quality improvements that emerge from peer review. + + * <> Well-known for its supportive community, Acegi Security + has an active group of developers and users. Visit our project resources (below) + to access these services. + + * <> You can confidently use Acegi Security in your project. + +* Project Resources + + {{{http://forum.springframework.org/}<>}} + {{{mail-lists.html}<>}} + {{{downloads.html}<>}} diff --git a/src/site/apt/svn-usage.apt b/src/site/apt/svn-usage.apt new file mode 100644 index 0000000000..28e8095195 --- /dev/null +++ b/src/site/apt/svn-usage.apt @@ -0,0 +1,41 @@ + ---------------- + Subversion Usage + ---------------- + +Subversion Usage + +* Web Access + + You can browse the Subversion repository at + {{{http://svn.sourceforge.net/viewvc/acegisecurity/}http://svn.sourceforge.net/viewvc/acegisecurity/}} + +* Anonymous SVN Access + + This project's SVN repository can be checked out through anonymous SVN with the following command: + ++----------------------------------------------------------------------------------------------------------------------+ + + svn co https://svn.sourceforge.net/svnroot/acegisecurity/trunk/acegisecurity + ++----------------------------------------------------------------------------------------------------------------------+ + +* Nightly Snapshots + + If you'd prefer not to use SVN directly, please see our {{{"downloads.html"}downloads page}} for nightly snapshots. + + +* Anonymous Access with Maven + + This project's CVS repository can be checked out through anonymous (pserver) CVS with the following command + on a single line: + ++----------------------------------------------------------------------------------------------------------------------+ + + maven scm:checkout-project + -Dmaven.scm.method=svn + -Dmaven.scm.svn.module=modulename + -Dmaven.scm.svn.root=scm:svn:https://svn.sourceforge.net/svnroot/acegisecurity/trunk/acegisecurity + -Dmaven.scm.checkout.dir=acegisecurity ++----------------------------------------------------------------------------------------------------------------------+ + + diff --git a/src/site/resources/articles.html b/src/site/resources/articles.html new file mode 100644 index 0000000000..24dab282ce --- /dev/null +++ b/src/site/resources/articles.html @@ -0,0 +1,163 @@ + + + + + + +External Web Articles covering Acegi Security + + + + +

External Web Articles covering Acegi Security

+

Here are some of the external pages mentioning Acegi Security. If you've + found another, please let us know. +

+ + diff --git a/src/site/resources/building.html b/src/site/resources/building.html new file mode 100644 index 0000000000..fe213c1aed --- /dev/null +++ b/src/site/resources/building.html @@ -0,0 +1,120 @@ + + + + + + +Building + + + + +

Building Acegi Security System

+

Checking Out from Subversion (SVN)

+

This project uses Maven as project manager + and build tool. We recommend you to install Maven 1.0.2 or greater before trying + the following. Note there are workarounds at the bottom of this page.

+

To checkout Acegi Security from SVN, see our + CVS Usage page.

+ +

Quick Build

+

Often people reading this document just want to see if Acegi Security will work + for their projects. They want to deploy a sample application, and that's about it + (after all, all the reference documentation can be read online at + http://acegisecurity.sourceforge.net). + In this case, execute:

+
    + 
    cd $ACEGI_SECURITY/core (or cd %ACEGI_SECURITY%/core on Windows)
    + 
    maven jar:install
    + 
    cd $ACEGI_SECURITY/samples/contacts
    + 
    maven multiwar:multiwar
    + 
    copy $ACEGI_SECURITY/samples/contacts/target/acegi-security-sample-contacts-filter.war $YOUR_CONTAINER/webapps
    +
+

Then load up your web container and visit + http://localhost:8080/acegi-security-sample-contacts-filter/ + (or whatever location is appropriate for your web container).

+ +

Installing commons-attributes-plugin

+

To properly integrate Commons Attributes with Maven (as required by + the Attributes Sample), + you need to install an additional plugin.

+

To install the commons-attributes-plugin, execute the following commands:

+
    + 
    cd $ACEGI_SECURITY/doc
    + 
    maven plugin:download
+    -DgroupId=commons-attributes
+    -DartifactId=commons-attributes-plugin
+    -Dversion=2.1
    +
+

The second (final) command should be executed on a single line.

+ +

Building All JARs

+

Sometimes people are already using Acegi Security, and they just want to build the + latest code from CVS. To build all artifacts (JARs) and install them into + your local Maven repository, simply perform a CVS checkout and install the + commons-attributes-plugin (as detailed above), and then + execute:

+
    + 
    cd $ACEGI_SECURITY/doc
    + 
    maven multiproject:install
    +
+

You can then check your $HOME/.maven/repository/acegisecurity + directory and it should contain all of the latest Acegi Security JARs.

+ +

Building The Site

+

By "site" we mean the web site you can browse at + http://acegisecurity.sourceforge.net, + which includes the reference documentation and all of the Maven reports. + If you'd like a local copy, simply execute: +

    + 
    cd $ACEGI_SECURITY/doc
    + 
    maven -Dpassword= changelog:create-cvspass
    + 
    maven    multiproject:clean multiproject:site
+	-Dmaven.jar.override=on 
+	-Dmaven.jar.clover-ant=1.3.3_01 
+
    +
+

As per the + Maven Changelog Plugin Documentation, + you must tell the plugin the "anonymous CVS pserver" password is blank. This is + why there is the "create-cvspass" command shown above. You should only need to + do this once.

+ +

Memory and Clover Workarounds

+

If you get an OutOfMemoryError, simply execute the following before + calling Maven:

+
    + 
    set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=512m
    +
+

If you get an [ERROR] Invalid license: Invalid license file [E1202], + this is because the maven-clover-plugin is using an old version of + clover-ant-xxx.jar. Whilst Acegi Security's project.properties + specifies a newer version, subprojects have an inheritence problem and don't pick + this up (as of the time of writing). To workaround this issue, you need to + specify those override properties on the command line. For example, to execute the + Clover reports for the core subproject, you would do the following:

+
    + 
    cd $ACEGI_SECURITY/core
    + 
    maven clover:html-report -Dmaven.jar.override=on -Dmaven.jar.clover-ant=1.3.3_01
    +
+ + + diff --git a/src/site/resources/cvs-usage.html b/src/site/resources/cvs-usage.html new file mode 100644 index 0000000000..0c00362432 --- /dev/null +++ b/src/site/resources/cvs-usage.html @@ -0,0 +1,53 @@ + + + + + +CVS usage +

CVS instructions for all modules

+

This instructions are general, check the module documentation if you need concrete instructions.

+

modulename can be for example:

+
    +
  • acegisecurity (this will check out all modules)
    • +
  • acegisecurity/core/
    • +
  • acegisecurity/adapters/cas
    • +
+

Web Access

+

+ http://svn.sourceforge.net/viewcvs.cgi/acegisecurity/ +

Anonymous Access with Maven

+

This project's CVS repository can be checked out through anonymous (pserver) CVS with the following instruction on a single line.

+
maven scm:checkout-project
+    -Dmaven.scm.method=svn
+    -Dmaven.scm.svn.module=modulename
+    -Dmaven.scm.svn.root=scm:svn:https://svn.sourceforge.net/svnroot/acegisecurity/trunk/acegisecurity
+    -Dmaven.scm.checkout.dir=acegisecurity
+

Anonymous SVN Access

+

+ This project's SVN repository can be checked out through anonymous + SVN with the following instruction set. +

+ svn co https://svn.sourceforge.net/svnroot/acegisecurity/trunk/acegisecurity

+ +

Nightly Snapshots

+

If you'd prefer not to use SVN directly, please see our downloads page for nightly snapshots.

+ + \ No newline at end of file diff --git a/src/site/resources/dbinit.txt b/src/site/resources/dbinit.txt new file mode 100644 index 0000000000..b747aa2765 --- /dev/null +++ b/src/site/resources/dbinit.txt @@ -0,0 +1,92 @@ +--- $Id: dbinit.txt 1245 2006-01-26 09:48:54Z benalex $ + +--- Sample Hypersonic SQL compatible schema and data +--- +--- All Acegi Security JDBC DAOs can be customised to use a different schema. +--- In addition, the Acegi Security JDBC DAOs do not even need to be used +--- with Acegi Security, and an entirely customised persistence strategy +--- can be employed via standard interfaces (eg in-memory, Hibernate etc). + +SET IGNORECASE TRUE; + +CREATE TABLE users ( + username VARCHAR(50) NOT NULL PRIMARY KEY, + password VARCHAR(50) NOT NULL, + enabled BIT NOT NULL +); + +CREATE TABLE authorities ( + username VARCHAR(50) NOT NULL, + authority VARCHAR(50) NOT NULL +); +CREATE UNIQUE INDEX ix_auth_username ON authorities ( username, authority ); + +ALTER TABLE authorities ADD CONSTRAINT fk_authorities_users foreign key (username) REFERENCES users(username); + +INSERT INTO users VALUES ('marissa', 'koala', true); +INSERT INTO users VALUES ('dianne', 'emu', true); +INSERT INTO users VALUES ('scott', 'wombat', true); +INSERT INTO users VALUES ('peter', 'opal', false); + +INSERT INTO authorities VALUES ('marissa', 'ROLE_TELLER'); +INSERT INTO authorities VALUES ('marissa', 'ROLE_SUPERVISOR'); +INSERT INTO authorities VALUES ('dianne', 'ROLE_TELLER'); +INSERT INTO authorities VALUES ('scott', 'ROLE_TELLER'); +INSERT INTO authorities VALUES ('peter', 'ROLE_TELLER'); + +--- Indexes auto created in HSQLDB for primary keys and unique columns + +CREATE TABLE acl_object_identity ( + id BIGINT GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY, + object_identity VARCHAR_IGNORECASE(250) NOT NULL, + parent_object BIGINT, + acl_class VARCHAR_IGNORECASE(250) NOT NULL, + CONSTRAINT unique_object_identity UNIQUE(object_identity), + FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id) +); + +CREATE TABLE acl_permission ( + id BIGINT GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY + acl_object_identity BIGINT NOT NULL, + recipient VARCHAR_IGNORECASE(100) NOT NULL, + mask INTEGER NOT NULL, + CONSTRAINT unique_recipient UNIQUE(acl_object_identity, recipient), + FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity(id) +); + +--- Mask integer 0 = no permissions +--- Mask integer 1 = administer +--- Mask integer 2 = read +--- Mask integer 6 = read and write permissions +--- Mask integer 14 = read and write and create permissions + +--------------------------------------------------------------------- +--- *** INHERITED RIGHTS FOR DIFFERENT INSTANCES AND RECIPIENTS *** +--- INSTANCE RECIPIENT PERMISSION(S) (COMMENT #INSTANCE) +--------------------------------------------------------------------- +--- 1 ROLE_SUPERVISOR Administer +--- 2 ROLE_SUPERVISOR None (overrides parent #1) +--- marissa Read +--- 3 ROLE_SUPERVISOR Administer (from parent #1) +--- scott Read, Write, Create +--- 4 ROLE_SUPERVISOR Administer (from parent #1) +--- 5 ROLE_SUPERVISOR Administer (from parent #3) +--- scott Read, Write, Create (from parent #3) +--- 6 ROLE_SUPERVISOR Administer (from parent #3) +--- scott Administer (overrides parent #3) +--------------------------------------------------------------------- + +INSERT INTO acl_object_identity VALUES (1, 'org.acegisecurity.acl.DomainObject:1', null, 'org.acegisecurity.acl.basic.SimpleAclEntry'); +INSERT INTO acl_object_identity VALUES (2, 'org.acegisecurity.acl.DomainObject:2', 1, 'org.acegisecurity.acl.basic.SimpleAclEntry'); +INSERT INTO acl_object_identity VALUES (3, 'org.acegisecurity.acl.DomainObject:3', 1, 'org.acegisecurity.acl.basic.SimpleAclEntry'); +INSERT INTO acl_object_identity VALUES (4, 'org.acegisecurity.acl.DomainObject:4', 1, 'org.acegisecurity.acl.basic.SimpleAclEntry'); +INSERT INTO acl_object_identity VALUES (5, 'org.acegisecurity.acl.DomainObject:5', 3, 'org.acegisecurity.acl.basic.SimpleAclEntry'); +INSERT INTO acl_object_identity VALUES (6, 'org.acegisecurity.acl.DomainObject:6', 3, 'org.acegisecurity.acl.basic.SimpleAclEntry'); + +INSERT INTO acl_permission VALUES (null, 1, 'ROLE_SUPERVISOR', 1); +INSERT INTO acl_permission VALUES (null, 2, 'ROLE_SUPERVISOR', 0); +INSERT INTO acl_permission VALUES (null, 2, 'marissa', 2); +INSERT INTO acl_permission VALUES (null, 3, 'scott', 14); +INSERT INTO acl_permission VALUES (null, 6, 'scott', 1); + + diff --git a/src/site/resources/downloads.html b/src/site/resources/downloads.html new file mode 100644 index 0000000000..df2827c104 --- /dev/null +++ b/src/site/resources/downloads.html @@ -0,0 +1,71 @@ + + + + + + +Acegi Security Downloads + + + + +

Acegi Security Downloads

+

If you wish to try out this project, you are probably looking for the + acegi-security-xx.zip file, which contains all of the officially + released JARs, a copy of all documentation, and two WAR artifacts. The two WAR artifacts + are from the Contacts Sample and the Tutorial Sample application. The Tutorial Sample + consists of a "bare bones" configuration that will get you up and running quickly, whereas + the Contacts Sample illustrates more advanced features.

+ +

Please note that in order to reduce download size, we only include in the + release ZIP one of the WAR artifacts produced by the Contacts Sample application. + The WAR artifact we include is suitable for standalone deployment (specifically, it + does not require a CAS server, container adapter, X509 or LDAP setup). The official release ZIP + therefore probably contains what you need, especially if you're initially + evaluating the project. If you wish to deploy the other WAR artifacts produced by + the Contacts Sample application (ie those that target CAS, container adapters, X509 or LDAP usage), + you will need to build Acegi Security from source. + +

The acegi-security-xx-src.zip is intended for use with IDEs. It does not contain the + files needed to compile Acegi Security. It also does not contain the sources to the + sample applications. If you need any of these files, please download from SVN.

+ +

Official Releases

+

The official release ZIP files are available from the + Sourceforge File Release System.

+

Maven Dependencies

+

The Acegi Security JARs are also available via the + iBiblio Maven Repository.

+

Building From Source

+

Detailed instructions on downloading from CVS and building from source + are provided on the Building with Maven + page.

+

SVN Snapshots and Daily Builds

+

+ If you don't wish to access SVN directly, we provide + nightly SVN exports for your convenience. + There is also an automated build which uploads bundle of Acegi Security jar files to the same location. + Both binary and source archives have the date of the build and the SVN revision number appended to the filename, + so you can match them up easily. +

+ + + diff --git a/src/site/resources/faq.html b/src/site/resources/faq.html new file mode 100644 index 0000000000..0c24019a8e --- /dev/null +++ b/src/site/resources/faq.html @@ -0,0 +1,287 @@ + + + + + + +Frequently Asked Questions (FAQ) on Acegi Security + + + + +

Frequently Asked Questions

+ +

What is Acegi Security?

+

Acegi Security is an open source project that provides comprehensive authentication + and authorisation services for enterprise applications based on + The Spring Framework. + 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.

+ +

Why not just use web.xml security?

+

Let's assume 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: +

    +
  1. Authentication: 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.

    2. +
  2. Web request security: 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 HTTP GET + 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.

    3. +
  3. Service layer and domain object security: 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:

    +
      +
    1. Separation of concerns: 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.
      2. +
    2. Support for rich clients and web services: 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.
      3. +
    3. Layering issues: 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 + economical (on a cost-benefit basis) to simply use a dedicated + security framework.
      4. +
    4. Authorisation code quality: 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. +
    +
    4. +
+ For simple applications, servlet specification security 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. +

+ +

How do you pronounce "Acegi"?

+

Ah-see-gee. 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.

+ +

Is it called "Acegi" or "Acegi Security"?

+

It's official name is Acegi Security System for Spring, + although we're happy for it to be abbreviated to + Acegi Security. Please don't just call it Acegi, though, + as that gets confused with the name of the company that maintains Acegi + Security.

+ +

What catches 80% of users reporting problems?

+

80% of support questions are because people have not defined + the necessary filters in web.xml, or the filters are being + mapped in the incorrect order. Check the + Reference Guide, which + has a specific section on filter ordering.

+ +

I'm sure my filters are ordered correctly. What else could be wrong?

+

The next most common source of problems stem from custom + AuthenticationDao implementations that simply don't properly + implement the interface contract. For example, they return null instead + of the user not found exception, or fail to add in the + GrantedAuthority[]s. Whilst DaoAuthenticationProvider + does its best to check the AuthenticationDao returns a valid + UserDetails, we suggest you write the + UserDetails object to the log and check it looks correct.

+ +

Common Problem #1: My application goes into an "endless loop" when I try to login, what's going on?

+

A common user problem with infinite loop and redirecting to the login page + is caused by accidently configuring the login page as a "secured" resource. + Generally make sure you mark your login page as requiring ROLE_ANONYMOUS. +

+ +

Common Problem #2: My application pages don't seem to be protected.

+

If you are securing web resources and they dont seem to be matched in the URL patterns, + check the objectDefinitionSource in the FilterSecurityInterceptor. + If you are using the CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON setting, + then the URL patterns configured MUST be in lowercase. +

+ For example, making a request ending in /someAction.do will need + to be configured as: /someaction.do (Note the case). +

+<property name="objectDefinitionSource">
+  <value>
+    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
+    PATTERN_TYPE_APACHE_ANT
+    /index.jsp=ROLE_ANONYMOUS,ROLE_USER
+    /someaction.do=ROLE_USER     			    
+  <value>
+</property>     
+
+ +

Common Problem #3: How do I disable a user after a number of failed logins?

+

A common user requirement is to disable / lock an account after a number of failed login attempts. + Acegi itself does not provide anything "out of the box", however in your application you can implement + and register an org.springframework.context.ApplicationListener. Inside your application + event listener you can then check for an instanceof the particular AuthenticationFailureEvent + and then call your application user management interface to update the user details. +

+ For example: + 

+     public void onApplicationEvent(ApplicationEvent event) {
+     
+       // check failed event
+       if(event instanceof AuthenticationFailurePasswordEvent){
+          // call user management interface to increment failed login attempts, etc.
+          . . .
+       }  
+     }
+
+ +

Common Problem #4: I am changing my password using a web controller and DAO, why is my password still not being refreshed?

+

There are three things you must do to make a user password change take affect: +

    +
  • Change the password using your authentication DAO
    • +
  • Remove the user from the User Cache (i.e. if you have a cache configured)
    • +
  • Update the SecurityContextHolder to include the new Authentication object and password
    • +
+ +

I need some help. What files should I post?

+

The most important things to post with any support requests on the + Spring Forums are your + web.xml, applicationContext.xml (or whichever + XML loads the security-related beans) as well as any custom + AuthenticationDao you might be using. For really odd problems, + also switch on debug-level logging and include the resulting log.

+ +

How do I switch on debug-level logging?

+

Acegi Security uses Commons Logging, just as Spring does. So you use the + same approach as you'd use for Spring. Most people output to Log4J, so + the following log4j.properties would work:

+ + 
+		log4j.rootCategory=WARN, stdout
+		
+		log4j.appender.stdout=org.apache.log4j.ConsoleAppender
+		log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
+		log4j.appender.stdout.layout.ConversionPattern=%d %p %c - %m%n
+		
+		log4j.category.net.sf.acegisecurity=DEBUG
+ +

How do I store custom properties, like a user's email address?

+

In most cases write an AuthenticationDao which returns + a subclass of User. Alternatively, write your own + UserDetails implementation from scratch and return that.

+ +

Why doesn't Acegi Security use JAAS?

+

Acegi Security targets enterprise applications, which are typically + multi-user, data-oriented applications that are important to + the core business. Acegi Security was designed to provide a portable and effective + security framework for this target application type. It was not designed for securing + limited privilege runtime environments, such as web browser applets.

+ +

We did consider JAAS when designing Acegi Security, but it simply + wasn't suitable for our purpose. We needed to avoid complex JRE configurations, + we needed container portability, and we wanted maximum leveraging of the Spring IoC + container. Particularly as limited privilege runtime environments were not + an actual requirement, this lead to the natural design of Acegi Security as + it exists today.

+ +

Acegi Security already provides some JAAS integration. It can today authenticate + via delegation to a JAAS login module. This means it offers the same level of JAAS + integration as many web containers. Indeed the container adapter model supported by + Acegi Security allows Acegi Security and container-managed security to happily + co-exist and benefit from each other. Any debate about Acegi Security and JAAS + should therefore centre on the authorisation issue. An evaluation of major + containers and security frameworks would reveal that Acegi Security is by no + means unusual in not using JAAS for authorisation.

+ +

There are many examples of open source applications being preferred to + official standards. A few that come to mind in the Java community include + using Spring managed POJOs (rather than EJBs), Hibernate (instead of entity beans), + Log4J (instead of JDK logging), Tapestry (instead of JSF), and Velocity/FreeMarker + (instead of JSP). It's important to recognise that many open source projects do + develop into de facto standards, and in doing so play a legitimate and beneficial + role in professional software development.

+ +

Do you welcome contributions?

+

Yes. If you've written something and it works well, please feel free to share it. + Simply email the contribution to the + acegisecurity-developers list. If you haven't yet + written the contribution, we encourage you to send your thoughts to the same + list so that you can receive some initial design feedback.

+ +

For a contribution to be used, it must have appropriate unit test coverage and + detailed JavaDocs. It will ideally have some comments for the Reference Guide + as well (this can be sent in word processor or HTML format if desired). This + helps ensure the contribution maintains the same quality as the remainder of + the project.

+ +

We also welcome documentation improvements, unit tests, illustrations, + people supporting the user community (especially on the forums), design ideas, + articles, blog entries, presentations and alike. If you're looking for something + to do, you can always email the + acegisecurity-developers list and we'll be + pleased to suggest something. :-)

+ + + diff --git a/src/site/resources/index.html b/src/site/resources/index.html new file mode 100644 index 0000000000..9d94bf14e2 --- /dev/null +++ b/src/site/resources/index.html @@ -0,0 +1,195 @@ + +Acegi Security System for Spring + + + +
+
What is Acegi Security?
 +
+
+ Acegi Security is a powerful, flexible security solution for enterprise software, + with a particular emphasis on applications that use + Spring. Using Acegi Security provides your + applications with comprehensive authentication, authorization, instance-based access control, + channel security and human user detection capabilities. +
+ +
+
Key Features
 +
+
+
    +
  • Stable and mature. Acegi Security 1.0.0 was released in May 2006 after + more than two and a half years of use in large production software projects, 70,000+ downloads + and hundreds of community contributions. + In terms of release numbering, we also use the Apache APR Project + Versioning Guidelines so that you can easily identify release + compatibility.

    +
  • Well documented: All APIs are fully documented using + JavaDoc, + with almost 100 pages of + Reference Guide documentation providing an easy-to-follow + introduction. Even more documentation is provided on this web site, as + shown in the left hand navigation sidebar.

    +
  • Fast results: View our suggested steps + for the fastest way to develop complex, security-compliant applications.

    +
  • Enterprise-wide single sign on: Using JA-SIG's open + source Central Authentication + Service (CAS), the Acegi Security can participate + in an enterprise-wide single sign on environment. You no longer need + every web application to have its own authentication database. Nor are + you restricted to single sign on across a single web container. Advanced + single sign on features like proxy support and forced refresh of logins + are supported by both CAS and Acegi Security.

    +
  • Reuses your Spring expertise: We use Spring application + contexts for all configuration, which should help Spring developers get + up-to-speed nice and quickly.

    +
  • Domain object instance security: In many applications it's + desirable to define Access Control Lists (ACLs) for individual domain + object instances. We provide a comprehensive ACL package with features + including integer bit masking, permission inheritence (including + blocking), a JDBC-backed ACL repository, caching and a pluggable, + interface-driven design.

    +
  • Non-intrusive setup: The entire security system can operate + within a single web application using the provided filters. There is no + need to make special changes or deploy libraries to your Servlet or EJB + container.

    +
  • Full (but optional) container integration: The credential + collection and authorization capabilities of your Servlet or EJB + container can be fully utilised via included "container adapters". We + currently support Catalina (Tomcat), Jetty, JBoss and Resin, with + additional containers easily added.

    +
  • Keeps your objects free of security code: Many applications + need to secure data at the bean level based on any combination of + parameters (user, time of day, authorities held, method being invoked, + parameter on method being invoked....). This package gives you this + flexibility without adding security code to your Spring business + objects.

    +
  • After invocation security: Acegi Security can not only protect + methods from being invoked in the first place, but it can also + deal with the objects returned from the methods. Included implementations + of after invocation security can throw an exception or mutate the returned + object based on ACLs.

    +
  • Secures your HTTP requests as well: In addition to securing + your beans, the project also secures your HTTP requests. No longer is it + necessary to rely on web.xml security constraints. Best of all, your + HTTP requests can now be secured by your choice of regular expressions + or Apache Ant paths, along with pluggable authentication, authorization + and run-as replacement managers.

    +
  • Channel security: Acegi Security can + automatically redirect requests across an appropriate transport channel. + Whilst flexible enough to support any of your "channel" requirements (eg + the remote user is a human, not a robot), a common channel security + feature is to ensure your secure pages will only be available over + HTTPS, and your public pages only over HTTP. Acegi Security also + supports unusual port combinations (including if accessed via an + intermediate server like Apache) and pluggable transport decision + managers.

    +
  • Supports HTTP BASIC authentication: Perfect for remoting + protocols or those web applications that prefer a simple browser pop-up + (rather than a form login), Acegi Security can directly process HTTP + BASIC authentication requests as per RFC 1945.

    +
  • Supports HTTP Digest authentication: For greater security than + offered by BASIC authentcation, Acegi Security also supports Digest Authentication + (which never sends the user's password across the wire). Digest Authentication + is widely supported by modern browsers. Acegi Security's implementation complies + with both RFC 2617 and RFC 2069.

    +
  • Computer Associates Siteminder support: Authentication can be + delegated through to CA's Siteminder solution, which is common in large + corporate environments.

    +
  • X509 (Certificate) support: Acegi Security can easily read + client-side X509 certificates for authenticating users.

    +
  • LDAP Support: Do you have an LDAP directory? Acegi Security can + happily authenticate against it.

    +
  • Tag library support: Your JSP files can use our taglib + to ensure that protected content like links and messages are only + displayed to users holding the appropriate granted authorities. The taglib + also fully integrates with Acegi Security's ACL services, and + obtaining extra information about the logged-in principal.

    +
  • Configuration via IoC XML, Commons Attributes, or JDK 5 Annotations: You + select the method used to configure your security environment. The + project supports configuration via Spring application contexts, as well + as Jakarta Commons Attributes and Java 5's annotations feature. Some users + (such as those building content management systems) pull configuration data + from a database, which exemplifies Acegi Security's flexible configuration + metadata system.

    +
  • Various authentication backends: We include the ability to + retrieve your user and granted authority definitions from an XML + file, JDBC datasource or Properties file. Alternatively, you can implement the + single-method UserDetailsService interface and obtain authentication details from + anywhere you like.

    +
  • Event support: Building upon Spring's + ApplicationEvent services, you can write your own listeners + for authentication-related events, along with authorisation-related events. + This enables you to implement account lockout and audit log systems, with + complete decoupling from Acegi Security code.

    +
  • Easy integration with existing databases: Our implementations + have been designed to make it very easy to use your existing + authentication schema and data (without modification). Of course, + you can also provide your own Data Access Object if you wish.

    +
  • Caching: Acegi Security integrates with Spring's EHCACHE factory. + This flexibility means your database (or other authentication + repository) is not repeatedly queried for authentication + information.

    +
  • Pluggable architecture: Every critical aspect of the package + has been modelled using high cohesion, loose coupling, interface-driven + design principles. You can easily replace, customise or extend parts of + the package.

    +
  • Startup-time validation: Every critical object dependency and + configuration parameter is validated at application context startup + time. Security configuration errors are therefore detected early and + corrected quickly.

    +
  • Remoting support: Does your project use a rich client? Not a + problem. Acegi Security integrates with standard Spring remoting + protocols, because it automatically processes the HTTP BASIC + authentication headers they present. Add our BASIC authentication filter + to your web.xml and you're done. You can also easily use RMI or Digest + authentication for your rich clients with a simple configuration statement.

    +
  • Advanced password encoding: Of course, passwords in your + authentication repository need not be in plain text. We support both SHA + and MD5 encoding, and also pluggable "salt" providers to maximise + password security. Acegi Security doesn't even need to see the password + if your backend can use a bind-based strategy for authentication (such as + an LDAP directory, or a database login).

    +
  • Run-as replacement: The system fully supports + temporarily replacing the authenticated principal for the duration of the web + request or bean invocation. This enables you to build public-facing + object tiers with different security configurations than your backend + objects.

    +
  • Transparent security propagation: Acegi Security can automatically + transfer its core authentication information from one machine to another, + using a variety of protocols including RMI and Spring's HttpInvoker.

    +
  • Compatible with HttpServletRequest's security methods: Even though + Acegi Security can deliver authentication using a range of pluggable mechanisms + (most of which require no web container configuration), we allow you to access + the resulting Authentication object via the getRemoteUser() and other + security methods on HttpServletRequest.

    +
  • Unit tests: A must-have of any quality security project, unit + tests are included. Our unit test coverage is very high, as shown in the + coverage report.

    +
  • Built by Maven: This assists you in effectively reusing the Acegi + Security artifacts in your own Maven-based projects.

    +
  • Supports your own unit tests: We provide a number of classes + that assist with your own unit testing of secured business objects. For + example, you can change the authentication identity and its associated + granted authorities directly within your test methods.

    +
  • Peer reviewed: Whilst nothing is ever completely secure, + using an open source security package leverages the continuous design + and code quality improvements that emerge from peer review.

    +
  • Community: Well-known for its supportive community, Acegi Security + has an active group of developers and users. Visit our project resources (below) + to access these services.

    +
  • Apache license. You can confidently use Acegi Security in your project.


+
+ +
Project Resources
 +
+
+
+ Support Forums

+ Developer Mailing List

+ Downloads +
+ diff --git a/src/site/resources/petclinic-tutorial.html b/src/site/resources/petclinic-tutorial.html new file mode 100644 index 0000000000..7b8dc85890 --- /dev/null +++ b/src/site/resources/petclinic-tutorial.html @@ -0,0 +1,222 @@ + + +Tutorial: Adding Security to Spring Petclinic + + + +

Tutorial: Adding Security to Spring Petclinic

+ +

Preparation

+ +

To complete this tutorial, you will require a servlet container (such as Tomcat) +and a general understanding of using Spring without Acegi Security. The Petclinic +sample itself is part of Spring and should help you learn Spring. We suggest you +only try to learn one thing at a time, and start with Spring/Petclinic before +Acegi Security. +

+ +

+You will also need to download: +

    +
  • Spring 2.0 M4 with dependencies ZIP file
    • +
  • Acegi Security 1.0.0
    • +
+

+ +

+Unzip both files. After unzipping Acegi Security, you'll need to unzip the +acegi-security-sample-tutorial.war file, because we need some files that are +included within it. In the code below, we'll refer to the respective unzipped +locations as %spring% and %acegi% (with the latter variable referring to the +unzipped WAR, not the original ZIP). There is no need to setup any environment +variables to complete the tutorial. +

+ +

Add required Acegi Security files to Petclinic

+ +

+We now need to put some extra files into Petclinic. The following commands should work: +

+mkdir %spring%\samples\petclinic\war\WEB-INF\lib
+copy %acegi%\acegilogin.jsp %spring%\samples\petclinic\war
+copy %acegi%\accessDenied.jsp %spring%\samples\petclinic\war
+copy %acegi%\WEB-INF\users.properties %spring%\samples\petclinic\war\WEB-INF
+copy %acegi%\WEB-INF\applicationContext-acegi-security.xml %spring%\samples\petclinic\war\WEB-INF
+copy %acegi%\WEB-INF\lib\acegi-security-1.0.0.jar %spring%\samples\petclinic\war\WEB-INF\lib
+copy %acegi%\WEB-INF\lib\oro-2.0.8.jar %spring%\samples\petclinic\war\WEB-INF\lib
+copy %acegi%\WEB-INF\lib\commons-codec-1.3.jar %spring%\samples\petclinic\war\WEB-INF\lib
+
+

+ +

Configure Petclinic's files

+ +

Edit %spring%\samples\petclinic\war\WEB-INF\web.xml and insert the following block of code. +

+<filter>
+  <filter-name>Acegi Filter Chain Proxy</filter-name>
+  <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
+  <init-param>
+    <param-name>targetClass</param-name>
+    <param-value>org.acegisecurity.util.FilterChainProxy</param-value>
+  </init-param>
+</filter>
+
+<filter-mapping>
+  <filter-name>Acegi Filter Chain Proxy</filter-name>
+  <url-pattern>/*</url-pattern>
+</filter-mapping>
+
+Next, locate the "contextConfigLocation" parameter, and add a new line into the existing param-value. +The resulting block will look like this: +
+<context-param>
+  <param-name>contextConfigLocation</param-name>
+  <param-value>
+    /WEB-INF/applicationContext-jdbc.xml
+    /WEB-INF/applicationContext-acegi-security.xml
+  </param-value>
+</context-param>
+
+

+ +

+To make it easier to experiment with the application, now edit +%spring%\samples\petclinic\war\WEB-INF\jsp\footer.jsp. Add a new "logout" link, as shown: +

+<table style="width:100%"><tr>
+  <td><A href="<c:url value="/welcome.htm"/>">Home</A></td>
+  <td><A href="<c:url value="/j_acegi_logout"/>">Logout</A></td>
+  <td style="text-align:right;color:silver">PetClinic :: a Spring Framework demonstration</td>
+</tr></table>
+
+

+ +

+Our last step is to specify which URLs require authorization and which do not. Let's +edit %spring%\samples\petclinic\war\WEB-INF\applicationContext-acegi-security.xml. +Locate the bean definition for FilterSecurityInterceptor. Edit its objectDefinitionSource +property so that it reflects the following: +

+<property name="objectDefinitionSource">
+  <value>
+    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
+    PATTERN_TYPE_APACHE_ANT
+    /acegilogin.jsp=IS_AUTHENTICATED_ANONYMOUSLY
+    /**=IS_AUTHENTICATED_REMEMBERED
+  </value>
+</property>
+
+

+ +

Start Petclinic's database

+ +

Start the Hypersonic server (this is just normal Petclinic configuration): +

+cd %spring%\samples\petclinic\db\hsqldb
+server
+
+

+ +

+Insert some data (again, normal Petclinic configuration): +

+cd %spring%\samples\petclinic
+build setupDB
+
+

+ + +

Build and deploy the Petclinic WAR file

+ +

+Use Petclinic's Ant build script and deploy to your servlet container: +

+cd %spring%\samples\petclinic
+build warfile
+copy dist\petclinic.war %TOMCAT_HOME%\webapps
+
+

+ +

Finally, start your container and try to visit the home page. +Your request should be intercepted and you will be forced to login.

+ +

Optional Bonus: Securing the Middle Tier

+

+Whilst you've now secured your web requests, you might want to stop users +from being able to add clinic visits unless authorized. We'll make it so +you need to hold ROLE_SUPERVISOR to add a clinic visit. +

+ +

+In %spring%\samples\petclinic\war\WEB-INF\applicationContext-jdbc.xml, locate +the TransactionProxyFactoryBean definition. Add an additional property after +the existing "preInterceptors" property: +

+<property name="postInterceptors" ref="methodSecurityInterceptor"/>
+
+

+ +

+Finally, we need to add in the referred-to "methodSecurityInterceptor" bean definition. +So pop an extra bean definition in, as shown below: +

+<bean id="methodSecurityInterceptor" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
+  <property name="authenticationManager"><ref bean="authenticationManager"/></property>
+  <property name="accessDecisionManager">
+    <bean class="org.acegisecurity.vote.AffirmativeBased">
+      <property name="allowIfAllAbstainDecisions" value="false"/>
+      <property name="decisionVoters">
+        <list>
+          <bean class="org.acegisecurity.vote.RoleVoter"/>
+          <bean class="org.acegisecurity.vote.AuthenticatedVoter"/>
+        </list>
+      </property>
+    </bean>
+  </property>
+  <property name="objectDefinitionSource">
+    <value>
+      org.springframework.samples.petclinic.Clinic.*=IS_AUTHENTICATED_REMEMBERED
+      org.springframework.samples.petclinic.Clinic.storeVisit=ROLE_SUPERVISOR
+    </value>
+  </property>
+</bean>
+
+

+ +

+Redeploy your web application. Use the earlier process to do that. Be careful to +ensure that the old Petclinic WAR is replaced by the new Petclinic WAR in your +servlet container. Login as "marissa", who has ROLE_SUPERVISOR. You will be able to +then view a customer and add a visit. Logout, then login as anyone other than Marissa. +You will receive an access denied error when you attempt to add a visit. +

+ +

+To clean things up a bit, you might want to wrap up by hiding the "add visit" link +unless you are authorized to use it. Acegi Security provides a tag library to help +you do that. Edit %spring%\samples\petclinic\war\WEB-INF\jsp\owner.jsp. Add +the following line to the top of the file: +

+<%@ taglib prefix="authz" uri="http://acegisecurity.org/authz" %>
+
+Next, scroll down and find the link to "add visit". Modify it as follows: +
+<authz:authorize ifAllGranted="ROLE_SUPERVISOR">
+  <FORM method=GET action="<c:url value="/addVisit.htm"/>" name="formVisitPet<c:out value="${pet.id}"/>">
+  <INPUT type="hidden" name="petId" value="<c:out value="${pet.id}"/>"/>
+  <INPUT type="submit" value="Add Visit"/>
+  </FORM>
+</authz:authorize>          
+
+

+ +

What now?

+

+These steps can be applied to your own application. Although we do suggest +that you visit http://acegisecurity.org +and in particular review the "Suggested Steps" for getting started with Acegi +Security. The suggested steps are optimized for learning Acegi Security quickly +and applying it to your own projects. It also includes realistic time estimates +for each step so you can plan your integration activities.

+ + \ No newline at end of file diff --git a/src/site/resources/policies.html b/src/site/resources/policies.html new file mode 100644 index 0000000000..ecd59067f7 --- /dev/null +++ b/src/site/resources/policies.html @@ -0,0 +1,131 @@ + + + + + + +Project Policies and Procedures + + + + +

Project Policies and Procedures Version 1.0

+

The following policies and procedures are intended to ensure that Acegi Security will + continue to achieve its project objectives and support the community in the context of an + expanding development team. + +

+ The following was unanimously supported by the community supporting following + discussion + on acegisecurity-developer. The policies and procedures below represent version 1.0 + and are effective 1 August 2005. +

    + +
  • + This project uses JIRA. Please log a task in JIRA for any changes you make to SVN, with the exception of very minor changes that users are unlikely to ever be interested in searching for and/or the change affects code that has never been in an officially released version of the project (eg ongoing changes to a new feature in SVN HEAD that hasn't been released previously).

    +
    • + +
  • + Any users running from SVN HEAD are warmly encouraged to join acegisecurity-cvs so that they can keep an eye on commit comments. Developers are encouraged to join acegisecurity-cvs and read the commit comments. If anyone has a concern with any commit, please raise it on acegisecurity-developer so that the broader community can participate (not acegisecurity-cvs). Alternatively, contact the author of the change directly if you think that would be more appropriate or diplomatic.

    +
    • + +
  • + Please make your commit comments informative, yet not too detailed. Detailed comments are ideally placed in the JIRA task. In the case of a contribution by a non-developer, please use the SVN commits to reflect who provided the contribution and add that person's name to /project.xml in the contributors section. If the contributors section does not list the name of someone who has contributed accepted code, please add them or let me know so that I can do so.

    +
    • + +
  • + If you add a major new feature, please announce it on acegisecurity-developer. That way people using the project have an idea of what is coming up in the next release, and any implementation-specific comments can be received prior to the first release when users will start expecting some degree of consistency and stability. It also encourages people to try out your new feature.

    +
    • + +
  • + Please make sure /docs/xdocs/changes.xml has a reference to JIRA for the upcoming release version. You don't need to add the name of contributors to /doc/xdocs/changes.xml, as acknowledgement is already provided via /project.xml, source code @author tags, the SVN commit message, and typically a JIRA task.

    +
    • + +
  • + Please edit /docs/xdocs/upgrade/upgrade-xx-yy.html if you make a change that is significant and you think users who are upgrading should be aware of it. Equally, users are encouraged to consult the upgrade-xx-yy.html file before they deploy subsequent official release JARs.

    +
    • + +
  • + Please use Jalopy with the /jalopy.xml file to format your Java code before checkin. This keeps our code consistent and ensures the license message is correct. There are plugins for all major IDEs.

    +
    • + +
  • + The /sandbox can be used to obtain feedback from fellow developers and the community about your code, general approach or new ideas. If you have SVN rights, please use /sandbox instead of emailing ZIP files to other developers for feedback. The community should understand that code in the sandbox is unsupported, subject to refactoring, may not have any unit tests, and may be removed at any time. The /sandbox will never be included in official release ZIPs. It's a "scratching pad" only.

    +
    • + +
  • + Unit tests are important to any security project, and we have a good history of high coverage. You can view the latest coverage report online (rebuilt every 24 hours). Please keep an eye on coverage and don't hesitate to add more unit tests. Please do not check code into /core unless it has at least an exercising unit test - use the /sandbox instead.

    +
    • + +
  • + Never check in code if the unit tests fail. This means, at minimum, successfully running "maven test:test" from /core. Always name your unit test classes so they end in "*Tests" - this ensures that Maven picks them up. If there is code in SVN which you didn't write and it is breaking the unit tests, please correct it yourself - don't leave SVN "broken" whilst waiting for the responsible developer to address it (the delay causes confusing and long-running threads on the list and forum). You can always rollback to the previous working version if in doubt of how the class works (just remember to comment the commit appropriately and let the author know).

    +
    • + +
  • + Please update the reference guide and JavaDocs for any new major features. The JavaDocs should always be correct. The reference guide may be kept updated with less rigor, although please briefly discuss any major new features. XMLmind can be used if you don't have a DocBook editor.

    +
    • + +
  • + Developers please keep an eye on the Acegi Security forum. It's a very active forum, and it takes a lot of work if not shared around. Please don't hesitate to reply to users - I try to read every thread and correct/confirm the situation if someone mentions they're unsure. I also will generally send developers an email if there's a question I can't answer as I didn't write the code.

    +
    • + +
  • + In the future, I will put to vote any proposed new developers. New developers will be firstly encouraged to attach patches to JIRA tasks to illustrate their understanding of the project, or, if they're long-time users, they might be given access without this JIRA stage if they're undertaking a major new feature.

    +
    • + +
  • + Developers should be subscribed to acegisecurity-developer. Obviously it would take significant time to read every thread, but reading the high priority messages (as indicated by the subject line) is needed to ensure we all have a way of communicating.

    +
    • + +
  • + Please do not hesitate to assign yourself any JIRA task that is unassigned, or assigned to me and not in the "In Progress" status. Also feel free to approach fellow developers to volunteer to work on tasks they might be assigned but haven't started.

    +
    • + +
  • + No code in SVN is "sacred". If you have a good idea or refactoring for an area of code that someone else wrote, raise it on acegisecurity-developer or contact the author directly. Please don't commit changes to such code unless it is a unit test failure correction, or you've firstly raised it on the acegisecurity-developer list or directly with the author.

    +
    • + +
  • + People's priorities are ever-changing, and we're all short on time. For this reason it's perfectly understandable that over time developers will move on to other things. This is not a negative reflection in any way - just part of any long-term project. If a developer no longer has the time or inclination to participate in the project , please send an email to acegisecurity-developer or myself. I will remove the SVN rights and reassign any JIRA tasks. Importantly, this helps find a new maintainer of the former developer's code (or, in very extreme cases, their code might be relocated to the sandbox or removed).

    +
    • + +
  • + Use CDATA inside XML files for multi-line properties. There is no tab/space policy for XML files, although try to maintain whatever the file is already using. The tab/space policy for Java files is managed by Jalopy.

    +
    • + +
  • + Keep the warm community spirit. The Spring community is a nice place to be - especially compared with some of the other open source communities out there where people are abused, ignored, insulted or excluded. No policy or procedure (including those above) should ever compromise operating in a considerate and diplomatic manner that respects the dignity of each individual member of the community. If in doubt, please contact me directly first. If I am ever guilty of this, please let me know and I will correct myself.

    +
    • + +
+ +

Thanks for your help in connection with the above. If you have any suggestions for improving these + policies and procedures, please use the acegisecurity-developer list to raise them. + +

+ Ben Alex
+ Project Admin + +

+ $Id: policies.html 1377 2006-04-25 00:22:00Z benalex $ + + + diff --git a/src/site/resources/powering.html b/src/site/resources/powering.html new file mode 100644 index 0000000000..53b20561e3 --- /dev/null +++ b/src/site/resources/powering.html @@ -0,0 +1,70 @@ + + + + + + +Products Using Acegi Security + + + + +

Products Using Acegi Security

+

Many open source and commercial products either use Acegi Security or at least + support it. Following is a partial list of such products. If you've integrated Acegi + Security with some other product, please let us know (preferably with a URL + to some page explaining the integration/use)... + +

Out-Of-the-Box Supported by Acegi Security

+ + +

Open Source Projects

+ + +

Commercial Deployments

+
    +
  • A global financial institution uses Acegi Security's SiteMinder integration in a physical security management application.

    • +
  • A central bank that uses Acegi Security for many of its internal applications with the CAS integration.

    • +
  • Several Australian Government departments use Acegi Security for securing SOAP-based web services and web applications.

    • +
  • Enterprise Systems and Services at Rutgers University uses Acegi Security in conjunction with JA-SIG Central Authentication Service to provide authentication and authorization capabilities to its applications including those used by staff and students as well as those utilized by web services.

    • +
  • Plus many more... ;-)

    • +
+ + + diff --git a/src/site/resources/standalone.html b/src/site/resources/standalone.html new file mode 100644 index 0000000000..831dcbfb99 --- /dev/null +++ b/src/site/resources/standalone.html @@ -0,0 +1,95 @@ + + + + + + +Acegi Security Use Without Spring + + + + +

Acegi Security Use Without Spring

+ +

Introduction

+

Sometimes we get asked can Acegi Security be used without Spring. + This page provides a detailed answer.

+ +

History

+

Acegi Security started out as a method interceptor for Spring IoC container + managed beans. Typically such beans provide services layer functions. + Over time Acegi Security grew to offer authentication services, ThreadLocal management, + web request filtering, extra AOP support, + ACL features, additional authentication mechanisms and so on (for those interested, + see our change log).

+ +

Why Use Spring

+

There's plenty written about why the + Spring Framework + is a good fit for modern applications. If you're not familiar with the benefits + Spring offers, please take a few minutes to learn more about it. In numerous + situations Spring will save you many months (or even years) of development time. + Not to mention your solutions will be better architected + (designed), better coded (implemented), and better supported (maintained) in the future. +

+ +

Acegi Security Dependencies on Spring

+

Acegi Security relies on the Spring IoC container to wire its classes, and execute lifecycle + methods such as afterPropertiesSet(). Some Acegi Security classes also + publish events to the ApplicationContext, although you could provide a mock + implementation of ApplicationContext easily enough which no-ops the method. + In other words, if you particularly didn't want Spring in your application, you could + avoid its use by writing equivalent getter, setter and lifecycle invocation processes + in standard Java code. This is a natural consequence of the Spring way of development, + which emphasises framework independence (it is not because we think there are good + reasons people would not use Spring).

+ +

If it sounds too hard (it's not) or counter-productive (it is) to replace Spring's IoC + services, don't forget you can always deploy Acegi Security and the Spring + IoC container solely for configuring Acegi Security. Spring does not mandate its + use in every part of your application. It will work quite successfully doing nothing more than + acting as a configuration mechanism for Acegi Security. Whilst some may regard this as excessive, + it's really no different than the traditional approach of every framework having its very + own XML or other proprietary configuration system. The main difference is that Spring is an + actual de facto standard, and you can gradually introduce it to other parts of your application + over time (if desired).

+ +

Acegi Security does not use any other Spring capabilities. Most notably, the + entire architecture is based around Filters, not Spring's MVC framework. + This allows it to be used with any MVC framework, or even with just straight JSPs. + Acegi Security uses the AOP Alliance and AspectJ interfaces for method interception - + it does not use any Spring-specific interfaces. As a consequence, Acegi Security is very + portable to applications that do not leverage any of Spring's capabilities. We should note + there are several very simple data access objects (DAOs) that use Spring's JDBC abstraction + layer, although each of these are defined by a simple interface and it is very common in + even native Spring-powered applications for these to be re-implemented using the application's + persistence framework of choice (eg Hibernate). + +

Conclusion

+ +

In summary, we recommend you take a look at Spring and consider using it in your + applications. Irrespective of whether you do so or not, we strongly recommend you use it + for configuration and lifecycle management of Acegi Security. If that is also not desired, + Acegi Security can easily be executed without Spring at all, providing you implement + similar IoC services. Acegi Security has very minimal dependencies directly on Spring, + with it being useful in many non-Spring applications and with non-Spring frameworks. + + diff --git a/src/site/resources/suggested.html b/src/site/resources/suggested.html new file mode 100644 index 0000000000..4fd9f2aa9d --- /dev/null +++ b/src/site/resources/suggested.html @@ -0,0 +1,133 @@ + + + + + + +Acegi Security Suggested Steps + + + + +

Suggested Steps

+

Presented below are the steps we encourage you to take in order to gain the most + out of Acegi Security in a realistic timeframe. +

    +
  1. + First of all, deploy the "Tutorial Sample", which is included in the main distribution + ZIP file. The sample doesn't do a great deal, but it does give you a template that can + be quickly and easily used to integrate into your own project.

    + + Estimated time: 30 minutes.

    +
    2. + +
  2. + Next, follow the Petclinic tutorial, which + covers how to add Acegi Security to the commonly-used Petclinic sample application + that ships with Spring. This will give you a hands-on approach to integrating + Acegi Security into your own application.

    + + Estimated time: 1 hour.

    +
    3. + +
  3. + Next, review the Reference Guide, and in particular + Part I. It has been designed to give you a solid overview. Go through the beans + defined in the "Tutorial Sample" and understand their main purpose within the overall + framework. Once you understand this, you'll have no difficulty moving on to more + complex examples. You can also experiment in the Petclinic tutorial that you + implemented in the last step.

    + + Estimated time: 1 day.

    +
    4. + +
  4. + If you have relatively simple security needs, you can probably start to integrate + Acegi Security into your application at this point. Just use the "Tutorial Sample" + as your basis (now that you understand how it works). Those with more complicated + requirements should review the "Contacts Sample" application. + This will probably involve deploying acegi-security-sample-contacts-filter.war, + which is also included in the release ZIP file.

    + + The purpose of understanding the "Contacts Sample" is to get a better feel for how method + security is implemented, particularly with domain object access control lists. This will + really round-out the rest of the framework for you.

    + + The actual java code + is a completely standard Spring application, except ContactManagerBackend + 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 web.xml). The main + XML files to review are + applicationContext-acegi-security.xml (from the filter webapp), + applicationContext-common-authorization.xml, + applicationContext-common-business.xml (just note we add contactManagerSecurity to the services layer target bean), and + web.xml (from the filter webapp). + The XML definitions are comprehensively discussed in the + Reference Guide. +

    + + Please note the release ZIP files do not include the sample application Java source code. You + will need to download from SVN if you would like to access the Java sources.

    + + Estimated time: 1-2 days.

    +
    5. + +
  5. 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. +

    + + We strongly recommend that you start your actual integration with the "Tutorial Sample". + Don't start by integrating with the "Contacts Sample", even if you have complex needs. + Most people reporting problems on the forums do so because of a configuration problem, + as they're trying to make far too many changes at once without really knowing what + they're doing. Instead, make changes one at a time, starting from the bare bones configuration + provided by the "Tutorial Sample".

    + + 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.

    + + Estimated time: 1-5 days.

    +
    +
    6. + +
+ +

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 security. The good thing is Acegi Security will either directly support your future + needs, or provide a clearly-defined extension point for addressing them. + +

+ 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. + + diff --git a/src/site/resources/upgrade/upgrade-03-04.html b/src/site/resources/upgrade/upgrade-03-04.html new file mode 100644 index 0000000000..ceb66fe29d --- /dev/null +++ b/src/site/resources/upgrade/upgrade-03-04.html @@ -0,0 +1,53 @@ + + +Acegi Security - Upgrading from version 0.3 to 0.4 + + +

Upgrading from 0.3 to 0.4

+ +

Several changes were made between version 0.3 and 0.4 of the project. +These changes increased the modularity of the code, enhanced unit testing, +made package roles clearer, and added compelling alternatives to container +adapters and using web.xml security constraints to protect HTTP resources. + +

Unfortunately, changes to the API and package locations were required. The +following should help most casual users of the project update their +applications: + +

    +
  • All references to net.sf.acegisecurity.SecurityInterceptor become + net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor.
    • + +
  • All references to net.sf.acegisecurity.MethodDefinitionAttributes become + net.sf.acegisecurity.intercept.method.MethodDefinitionAttributes.
    • + +
  • All references to net.sf.acegisecurity.adapters.AutoIntegrationFilter become + net.sf.acegisecurity.ui.AutoIntegrationFilter (see your web.xml).
    • + +
  • If you're using container adapters (extremely likely), consider replacing + them with the net.sf.acegisecurity.ui.webapp package. This will avoid + the need to have JARs in your container classloader, and is a lot cleaner. + Refer to the reference documentation or Contacts sample application.
    • + +
  • If you're using web.xml s for securing HTTP URLs + (extremely likely), consider replacing it with the + net.sf.acegisecurity.intercept.web package. This will give you considerably + more flexibility, and reuse the same concepts as you'd be familiar with + via the method security interception system. Refer to the reference + documentation or Contacts sample application.
    • + +
  • The Contacts sample application now builds two distributions: contacts.war + can be instantly deployed without configuring any container adapters, + whilst contacts-container-adapter.war still uses container adapters. The + contacts.war uses the net.sf.acegisecurity.intercept.web package to + protect HTTP URLs, rather than web.xml s.
    • + +
  • If you're using the Jetty container adapter, please check the jetty.xml + requirements in the reference documentation. There has been a minor change.
    • +
+ +

+We hope you find the new features useful in your projects. + + + diff --git a/src/site/resources/upgrade/upgrade-04-05.html b/src/site/resources/upgrade/upgrade-04-05.html new file mode 100644 index 0000000000..38c698d8d1 --- /dev/null +++ b/src/site/resources/upgrade/upgrade-04-05.html @@ -0,0 +1,59 @@ + + +Acegi Security - Upgrading from version 0.4 to 0.5 + + +

Upgrading from 0.4 to 0.5

+ +

The following should help most casual users of the project update their +applications: +

    + +
  • All filters are now loaded via FilterToBeanProxy. The FilterToBeanProxy + obtains the filter from a Spring application context via the + WebApplicationContextUtils.getApplicationContext() method. Refer to the + reference documentation to see the new configuration of filters.
    • + +
  • SecurityEnforcementFilter now requires an AuthenticationEntryPoint + and PortResolver. Refer to the reference documentation to see the + alternatives AuthenticationEntryPoint implementations available. Simply + use the PortResolverImpl for the PortResolver requirement.
    • + +
  • Any of your login or login failure pages that previously referred to + AuthenticationProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY + should now use + net.sf.acegisecurity.ui.AbstractProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY.
    • + +
  • DaoAuthenticationProvider no longer provides setters for case sensitivity + handling. The respective AuthenticationDao implementations should decide + whether or not to return User instances reflecting the exact case of the + requested username. The new PlaintextPasswordEncoder offers a setter for + ignoring the password case (defaults to require exact case matches).
    • + +
  • DaoAuthenticationProvider now provides caching. Successful authentications + return DaoAuthenticationTokens. You must set the mandatory "key" property + on DaoAuthenticationProvider so these tokens can be validated. You may + also wish to change the "refreshTokenInterval" property from the default + of 60,000 milliseconds.
    • + +
  • If you're using container adapters, please refer to the reference + documentation as additional JARs are now required in your container + classloader.
    • + +
  • Whilst not really a change needed to your program, if you're using + Acegi Security please consider joining the acegisecurity-developer mailing + list. This is currently the best way to keep informed about the project's + status and provide feedback in design discussions. You can join at + https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer. + Please continue using the Spring Users mailing list for general support.
    • +
+ +

+There are also lots of new features you might wish to consider for your +projects. These include CAS integration, pluggable password encoders +(such as MD5 and SHA), along with pluggable salt sources. We hope you find +the new features useful in your projects. + + + + diff --git a/src/site/resources/upgrade/upgrade-05-06.html b/src/site/resources/upgrade/upgrade-05-06.html new file mode 100644 index 0000000000..d372ef4331 --- /dev/null +++ b/src/site/resources/upgrade/upgrade-05-06.html @@ -0,0 +1,81 @@ + + +Acegi Security - Upgrading from version 0.3 to 0.4 + + +

Upgrading from 0.5 to 0.6

+ +

+The following should help most casual users of the project update their +applications: +

    +
  • +Locate and remove all property references to + DaoAuthenticationProvider.key and + DaoAuthenticationProvider.refreshTokenInterval.
    • + +
  • If you are using DaoAuthenticationProvider and either (i) you are using + container adapters or (ii) your code relies on the Authentication object + having its getPrincipal() return a String, you must set the new + DaoAuthenticationProvider property, forcePrincipalAsString, to true. + By default DaoAuthenticationProvider returns an Authentication object + containing the relevant User, which allows access to additional properties. + Where possible, we recommend you change your code to something like this, + so that you can leave forcePrincipalAsString to the false default:

    + + String username = authentication.getPrincipal();
    + if (authentication.getPrincipal() instanceof User) {
    + username = ((User) authentication.getPrincipal()).getUsername();
    + }
    +
    +
    • + +
  • The signature of AuthenticationDaos have changed. In concrete + implementations, modify the User to UserDetails, as shown below:

    + + public User loadUserByUsername(String username)
    + throws UsernameNotFoundException, DataAccessException {

    + + to:

    + + public UserDetails loadUserByUsername(String username)
    + throws UsernameNotFoundException, DataAccessException {

    +     + + Existing concrete implementations would be returning User, which implements + UserDetails, so no further code changes should be required. +
    • +
  • Similar signature changes (User -> UserDetails) are also required to any + custom implementations of UserCache and SaltSource.
    • + +
  • Any custom event listeners relying on AuthenticationEvent should note a + UserDetails is now provided in the AuthenticationEvent (not a User).
    • + +
  • CAS users should note the CasAuthoritiesPopulator interface signature has + changed. Most CAS users will be using DaoCasAuthoritiesPopulator, so this + change is unlikely to require any action.
    • + +
  • Please check your web.xml for whether you are using AutoIntegrationFilter. + Previously this class was loaded directly by web.xml as a filter. It is + now recommended to load it via FilterToBeanProxy and define it as a + bean in your application context. This usually involves making the entry + in web.xml match the following:

    + + <filter>
    + <filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
    + <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
    + <init-param>
    + <param-name>targetClass</param-name>
    + <param-value>net.sf.acegisecurity.ui.AutoIntegrationFilter</param-value>
    + </init-param>
    + </filter>
    +     +

    + Then add the following to applicationContext.xml:

    + + <bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter"/>
    +     +
    • +
+ + diff --git a/src/site/resources/upgrade/upgrade-06-070.html b/src/site/resources/upgrade/upgrade-06-070.html new file mode 100644 index 0000000000..717e338339 --- /dev/null +++ b/src/site/resources/upgrade/upgrade-06-070.html @@ -0,0 +1,60 @@ + + +Acegi Security - Upgrading from version 0.6 to 0.7 + + +

Upgrading from 0.6 to 0.7.0

+ +

+The following should help most casual users of the project update their +applications: +

    +
  • UserDetails now has two extra methods. Most people who have extended +Acegi Security's default User implementation of UserDetails will be fine, as +the constructor sets sensible defaults for the extra methods. People who +have written their own UserDetails implementation from scratch will need to +add the additional two methods. Returning true to both methods will normally +be correct. +
    • +
  • AutoIntegrationFilter has been removed. User should instead use + HttpSessionIntegrationFilter (in most cases), or HttpRequestIntegrationFilter + (if using most container adapters) or JbossIntegrationFilter (if using the + JBoss container adapter).
    • + +
  • MethodDefinitionMap, which is usually used by MethodSecurityInterceptor + for its objectDefinitionSource property, has been changed. From 0.7.0, when + MethodDefinitionMap is queried for configuration attributes associated with + secure MethodInvocations, it will use any method matching in the method + invocation class (as it always has) plus any method matching any interface + the MethodInvocation class directly implements. So consider a PersonManager + interface, a PersonManagerImpl class that implements it, and a definition of + PersonManager.findAll=ROLE_FOO. In this example, any query for either + PersonManager.findAll OR PersonManagerImpl.findAll will return ROLE_FOO. + As we have always encouraged definition against the interface names (as per + this example), this change should not adversely impact users. This change + was necessary because of the new MethodDefinitionSourceAdvisor (see below). + Refer to the MethodDefinitionMap JavaDocs for further clarification.
    • + +
  • MethodDefinitionSourceAdvisor can now be used instead of defining proxies + for secure business objects. The advisor is fully compatible with both + MethodDefinitionMap and MethodDefinitionAttributes. Using an advisor allows + caching of which methods the MethodSecurityInterceptor should handle, thus + providing a performance benefit as MethodSecurityInterceptor is not called + for public (non-secure) objects. It also simplifies configuration.
    • + +
  • MethodSecurityInterceptor has moved from + net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor to + net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor. + A simple find and replace will suffice to update your application contexts.
    • + +
  • All of the EH-CACHE cache implementations provided with Acegi Security have + now been refactored to use a net.sf.ehcache.Cache obtained from + EhCacheManagerFactoryBean, which is included with Spring 1.1.1 and above. + See http://opensource.atlassian.com/confluence/spring/display/DISC/Caching+the+result+of+methods+using+Spring+and+EHCache + for more about this bean, or the Contacts sample application for how to + configure the EH-CACHE implementations provided with Acegi Security. + Note the "cache" property is now required, and the old internally-managed + cache properties have been removed.
    • +
+ + diff --git a/src/site/resources/upgrade/upgrade-070-080.html b/src/site/resources/upgrade/upgrade-070-080.html new file mode 100644 index 0000000000..cdf3c41b0a --- /dev/null +++ b/src/site/resources/upgrade/upgrade-070-080.html @@ -0,0 +1,46 @@ + + +Acegi Security - Upgrading from version 0.7.0 to 0.8.0 + + +

Upgrading from 0.7.0 to 0.8.0

+ +

+The following should help most casual users of the project update their +applications: + +

    + +
  • HttpSessionIntegrationFilter has been removed. Use net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter instead. + Note you will need to set the mandatory "context" property to something like "net.sf.acegisecurity.context.security.SecureContextImpl". + It's not the default because we want no dependencies between the context package and the rest of Acegi Security.

    • + +
  • Filter ordering has changed. See the reference guide for confirmation of the correct ordering. Basically you should have + HttpSessionContextIntegrationFilter appear before any of your authentication mechanisms.

    • + +
  • IoC container hosted filter chains can now be used instead of lengthy web.xml declarations. See the reference guide or the + Contacts Sample for further information.

    • + +
  • Certain classes have been moved to new packages: ContextHolderAwareRequestWrapper (and its filter), + AuthenticationSimpleHttpInvokerRequestExecutor, ContextPropagatingRemoteInvocation, + SecureContext (and its implementation). These classes were moved as part of refactorings aimed at + improving the simplicity of the project's design.

    • + +
  • If you wish to use the new ConcurrentSessionController you must declare the HttpSessionEventPublisher context listener in your + web.xml

    • + +
  • The JaasAuthenticationCallbackHandler interface has had it's setAuthentication method removed. + The handle method now takes both the Callback and Authentication objects as arguments.

    • + +
  • Added AuthenticationException to the AutenticationEntryPoint.commence method signature.

    • + +
  • Added AccessDeniedException to the SecurityEncorcementFilter.sendAccessDeniedError method signature.

    • + +
  • The Authentication.getDetails() no longer returns simply the IP address used for authentication. + It now returns a WebAuthenticationDetails instance, which contains the IP address, session information, + and can be extended to store further details.

    • + +
+ + + diff --git a/src/site/resources/upgrade/upgrade-080-090.html b/src/site/resources/upgrade/upgrade-080-090.html new file mode 100644 index 0000000000..c8cd60efde --- /dev/null +++ b/src/site/resources/upgrade/upgrade-080-090.html @@ -0,0 +1,100 @@ + + +Acegi Security - Upgrading from version 0.8.0 to 0.9.0 + + +

Upgrading from 0.8.0 to 0.9.0

+ +

+The following should help most casual users of the project update their +applications: + +

    + +
  • The most significant change in 0.9.0 is that ContextHolder and all of its + related classes have been removed. This significant change was made for the sake of consistency + with the core Spring project's approach of a single ThreadLocal per use case, + instead of a shared ThreadLocal for multiple use cases as the previous + ContextHolder allowed. This is an important change in 0.9.0. Many applications + will need to modify their code (and possibly web views) if they directly interact with the old + ContextHolder. The replacement security ThreadLocal is called + + SecurityContextHolder and provides a single getter/setter for a + SecurityContext. + SecurityContextHolder guarantees to never return a null SecurityContext. + SecurityContext provides single getter/setter for Authentication.

    + + To migrate, simply modify all your code that previously worked with ContextHolder, + SecureContext and Context to directly call SecurityContextHolder + and work with the SecurityContext (instead of the now removed Context + and SecureContext interfaces).

    + + For example, change:
    + + SecureContext ctx = SecureContextUtils.getSecureContext();
    +     + to:
    + + SecurityContext ctx = SecurityContextHolder.getContext();
    +     +
    + and change:
    + + <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter">
    + <property name="context"><value>net.sf.acegisecurity.context.security.SecureContextImpl</value></property>
    + </bean>
    +     + to:
    + + <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter">
    + <property name="context"><value>net.sf.acegisecurity.context.SecurityContextImpl</value></property>
    + </bean>
    +     +
    + + We apologise for the inconvenience, but on a more positive note this means you receive strict + type checking, you no longer need to mess around with casting to and from Context + implementations, your applications no longer need to perform checking of null and + unexpected Context implementation types.

    • + +
  • AbstractProcessingFilter has changed its getter/setter approach used for customised + authentication exception directions. See the + AbstractProcessingFilter JavaDocs to learn more.

    • + +
  • AnonymousProcessingFilter now has a removeAfterRequest property, which defaults to true. This + will cause the anonymous authentication token to be set to null at the end of each request, thus + avoiding the expense of creating a HttpSession in HttpSessionContextIntegrationFilter. You may + set this property to false if you would like the anoymous authentication token to be preserved, + which would be an unusual requirement.

    • + +
  • Event publishing has been refactored. New event classes have been added, and the location of + LoggerListener has changed. See the net.sf.acegisecurity.event package.
    +
    + For example, change:
    + + <bean id="loggerListener" class="net.sf.acegisecurity.providers.dao.event.LoggerListener"/>
    +     + to:
    + + <bean id="loggerListener" class="net.sf.acegisecurity.event.authentication.LoggerListener"/> +

    +
    • + +
  • Users of the <authz:authentication> JSP tag will generally need to set the operation + property equal to "username", as reflection is now used to retrieve the property displayed.

    • + +
  • + Users of net.sf.acegisecurity.wrapper.ContextHolderAwareRequestFilter should note that it has been + renamed to net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.

    +
    • + +
  • + The concurrent session support handling has changed. Please refer to the Reference Guide to + review the new configuration requirements.

    +
    • + + +
+ + + diff --git a/src/site/resources/upgrade/upgrade-090-100.html b/src/site/resources/upgrade/upgrade-090-100.html new file mode 100644 index 0000000000..93f82cf7ea --- /dev/null +++ b/src/site/resources/upgrade/upgrade-090-100.html @@ -0,0 +1,121 @@ + + + + + + +Acegi Security - Upgrading from version 0.8.0 to 1.0.0 + + +

Upgrading from 0.9.0 to 1.0.0

+ +

+The following should help most casual users of the project update their +applications: +

+ +

Changes 0.9.0 to RC1

+ +
    + +
  • The top level package name has changed. Simply find "net.sf.acegisecurity" and replace with +"org.acegisecurity".
    • + +
  • +DaoAuthenticationProvider has a property, authenticationDao. This property should now be renamed to +userDetailsService. +
    • + +
  • +In JSPs, each "authz" taglib prefix must be changed from uri="http://acegisecurity.sf.net/authz" +to uri="http://acegisecurity.org/authz". +
    • + +
  • net.sf.acegisecurity.providers.dao.AuthenticationDao is now org.acegisecurity.userdetails.UserDetailsService. +The interface signature has not changed. Similarly, User and UserDetails have moved into the latter's package as well. +If you've implemented your own AuthenticationDao, you'll need to change the class it's implementing and quite likely +the import packages for User and UserDetails. In addition, if using JdbcDaoImpl or InMemoryDaoImpl please +note they have moved to this new package.
    • + +
  • Acegi Security is now localised. In net.sf.acegisecurity you will find a messages.properties. It is +suggested to register this in your application context, perhaps using ReloadableResourceBundleMessageSource. +If you do not do this, the default messages included in the source code will be used so this change is +not critical. The Spring LocaleContextHolder class is used to determine the locale of messages included in +exceptions. At present only the default messages.properties is included (which is in English). If +you localise this file to another language, please consider attaching it to a +new JIRA task +so that we can include it in future Acegi Security releases.
    • + +
+ + +

Changes RC1 to RC2

+ + +
    + +
  • +org.acegisecurity.ui.rememberme.RememberMeProcessingFilter now requires an authenticationManager property. This will generally +point to an implementation of org.acegisecurity.providers.ProviderManager. +
    • + +
  • +org.acegisecurity.intercept.web.AuthenticationEntryPoint has moved to a new location, +org.acegisecurity.ui.AuthenticationEntryPoint. +
    • + +
  • +org.acegisecurity.intercept.web.SecurityEnforcementFilter has moved to a new location and name, +org.acegisecurity.ui.ExceptionTranslationFilter. In addition, the "filterSecurityInterceptor" +property on the old SecurityEnforcementFilter class has been removed. This is because +SecurityEnforcementFilter will no longer delegate to FilterSecurityInterceptor as it has in the +past. Because this delegation feature has been removed (see SEC-144 for a background as to why), +please add a new filter definition for FilterSecurityInterceptor to the end of your +FilterChainProxy. Generally you'll also rename the old SecurityEnforcementFilter entry in your +FilterChainProxy to ExceptionTranslationFilter, more accurately reflecting its purpose. +If you are not using FilterChainProxy (although we recommend that you do), you will need to add +an additional filter entry to web.xml and use FilterToBeanProxy to access the FilterSecurityInterceptor. +
    • + +
  • +If you are directly using SecurityContextHolder.setContext(SecurityContext) - which is not +very common - please not that best practise is now to call SecurityContextHolder.clearContext() +if you wish to erase the contents of the SecurityContextHolder. Previously code such as +SecurityContextHolder.setContext(new SecurityContextImpl()) would have been used. The revised +method internally stores null, which helps avoids redeployment issue caused by the previous +approaches (see SEC-159 for further details). +
    • + +
+ + +

Changes RC2 to Final

+ + +
    + +
  • +AbstractProcessingFilter.onUnsuccessfulAuthentication(HttpServletRequest, HttpServletResponse) +has changed it signature (SEC-238). If subclassing, please override the new signature. +
    • + +
  • +ExceptionTranslationFilter no longer provides a sendAccessDenied() method. Use the +new AccessDeniedHandler instead if custom handling is required. +
    • + +
  • +There have been some changes to the LDAP provider APIs to allow for future improvements, as detailed in +SEC-264. These +should only affect users who have written their own extensions to the provider. The general LDAP +classes are now in the packages org.acegisecurity.ldap and the org.acegisecurity.userdetails.ldap +package has been introduced. The search and authentication classes now return an +LdapUserDetails +instance. The LdapAuthoritiesPopulator interface and its default implementation now both make use of +LdapUserDetails. Any customized versions should be updated to use the new method signatures. +
    • + +
+ + + diff --git a/src/site/site.xml b/src/site/site.xml new file mode 100644 index 0000000000..4be287e3ab --- /dev/null +++ b/src/site/site.xml @@ -0,0 +1,88 @@ + + + + + + + Acegi Security + http://sourceforge.net/sflogo.php?group_id=104215&type=5 + http://acegisecurity.sourceforge.net + + + http://acegisecurity.org/logo.gif + http://acegisecurity.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/site/xdocs/changes.xml b/src/site/xdocs/changes.xml new file mode 100644 index 0000000000..fbcd223651 --- /dev/null +++ b/src/site/xdocs/changes.xml @@ -0,0 +1,293 @@ + + + + + + + Acegi Security changes + + + + All changes are in JIRA at http://opensource2.atlassian.com/projects/spring/secure/ReleaseNote.jspa?projectId=10040 + + + All changes are in JIRA at http://opensource2.atlassian.com/projects/spring/secure/ReleaseNote.jspa?projectId=10040 + + + All changes are in JIRA at http://opensource2.atlassian.com/projects/spring/secure/ReleaseNote.jspa?projectId=10040 + + + All changes are in JIRA at http://opensource2.atlassian.com/projects/spring/secure/ReleaseNote.jspa?projectId=10040 + + + HttpSessionContextIntegrationFilter elegantly handles IOExceptions and ServletExceptions within filter chain (see http://opensource.atlassian.com/projects/spring/browse/SEC-20) + + + HttpSessionContextIntegrationFilter elegantly handles IOExceptions and ServletExceptions within filter chain (see http://opensource.atlassian.com/projects/spring/browse/SEC-20) + + + AbstractIntegrationFilter elegantly handles IOExceptions and ServletExceptions within filter chain (see http://opensource.atlassian.com/projects/spring/browse/SEC-20) + + + Correct location of AuthenticationSimpleHttpInvokerRequestExecutor in clientContext.xml + TokenBasedRememberMeServices changed to use long instead of int for tokenValiditySeconds (SPR-807) + Handle null Authentication.getAuthorities() in AuthorizeTag + PasswordDaoAuthenticationProvider no longer stores String against Authentication.setDetails() + Update commons-codec dependency to 1.3 + AbstractProcessingFilter no longer has setters for failures, it uses the exceptionMappings property + Update to match Spring 1.2-RC2 official JAR dependencies + AuthenticationProcessingFilter now provides an obtainUsername method + Correct PathBasedFilterInvocationDefinitionMap compatibility with Spring 1.2-RC2 + Refactoring to leverage Spring's Assert class and mocks where possible + + + X509 (certificate-based) authentication support + UserDetails now advises locked accounts, with corresponding DaoAuthenticationProvider events and enforcement + ContextHolderAwareRequestWrapper methods return null if user is anonymous + AbstractBasicAclEntry improved compatibility with Hibernate + User now provides a more useful toString() method + Update to match Spring 1.1.5 official JAR dependencies (NB: now using Servlet 2.4 and related JSP/taglib JARs) + SecurityEnforcementFilter caused NullPointerException when anonymous authentication used with BasicProcessingFilterEntryPoint + FilterChainProxy now supports replacement of ServletRequest and ServetResponse by Filter beans + Corrected Authz parsing of whitespace in GrantedAuthoritys + TokenBasedRememberMeServices now respects expired users, expired credentials and disabled users + HttpSessionContextIntegrationFilter now handles HttpSession invalidation without redirection + StringSplitUtils.split() ignored delimiter argument + DigestProcessingFilter now provides userCache getter and setter + Contacts Sample made to work with UserDetails-based Principal + Documentation improvements + Test coverage improvements + + + Added Digest Authentication support (RFC 2617 and RFC 2069) + Added pluggable remember-me services + Added pluggable mechnism to prevent concurrent login sessions + FilterChainProxy added to significantly simplify web.xml configuration of Acegi Security + AuthenticationProcessingFilter now provides hook for extra credentials (eg postcodes) + New WebAuthenticationDetails class now used by processing filters for Authentication.setDetails() + Additional debug-level logging + Improved Tapestry support in AbstractProcessingFilter + Made ConfigAttributeDefinition and ConfigAttribute Serializable + User now accepts blank passwords (null passwords still rejected) + FilterToBeanProxy now searches hierarchical bean factories + User now accepted blank passwords (null passwords still rejected) + ContextHolderAwareRequestWrapper now provides a getUserPrincipal() method + HttpSessionIntegrationFilter no longer creates a HttpSession unnecessarily + FilterSecurityInterceptor now only executes once per request (improves performance with SiteMesh) + JaasAuthenticatinProvider now uses System.property "java.security.auth.login.config" + JaasAuthenticationCallbackHandler Authentication is passed to handle method setAuthentication removed + Added AuthenticationException to the AutenticationEntryPoint.commence method signature + Added AccessDeniedException to the SecurityEncorcementFilter.sendAccessDeniedError method signature + FilterToBeanProxy now addresses lifecycle mismatch (IoC container vs servlet container) issue + Significantly refactor "well-known location model" to authentication processing mechanism and HttpSessionContextIntegrationFilter model + Correct issue with JdbcDaoImpl default SQL query not using consistent case sensitivity + Improve Linux and non-Sun JDK (specifically IBM JDK) compatibility + Log4j now included in generated WAR artifacts (fixes issue with Log4j listener) + Correct NullPointerException in FilterInvocationDefinitionSource implementations + + + Major CVS repository restructure to support Maven and eliminate libraries + Major improvements to Contacts sample application (now demos ACL security) + Added AfterInvocationManager to mutate objects return from invocations + Added BasicAclEntryAfterInvocationProvider to ACL evaluate returned Object + Added BasicAclEntryAfterInvocationCollectionFilteringProvider + Added security propagation during RMI invocations (from sandbox) + Added security propagation for Spring's HTTP invoker + Added BasicAclEntryVoter, which votes based on AclManager permissions + Added AspectJ support (especially useful for instance-level security) + Added MethodDefinitionSourceAdvisor for performance and autoproxying + Added MethodDefinitionMap querying of interfaces defined by secure objects + Added AuthenticationProcessingFilter.setDetails for use by subclasses + Added 403-causing exception to HttpSession via SecurityEnforcementFilter + Added net.sf.acegisecurity.intercept.event package + Added BasicAclExtendedDao interface and JdbcExtendedDaoImpl for ACL CRUD + Added additional remoting protocol demonstrations to Contacts sample + Added AbstractProcessingFilter property to always use defaultTargetUrl + Added ContextHolderAwareRequestWrapper to integrate with getRemoteUser() + Added attempted username to view if processed by AuthenticationProcessingFilter + Added UserDetails account and credentials expiration methods + Added exceptions and events to support new UserDetails methods + Added new exceptions to JBoss container adapter + Improved BasicAclProvider to only respond to specified ACL object requests + Refactored MethodDefinitionSource to work with Method, not MethodInvocation + Refactored AbstractFilterInvocationDefinitionSource to work with URL Strings alone + Refactored AbstractSecurityInterceptor to better support other AOP libraries + Improved performance of JBoss container adapter (see reference docs) + Made DaoAuthenticationProvider detect null in Authentication.principal + Improved JaasAuthenticationProvider startup error detection + Refactored EH-CACHE implementations to use Spring IoC defined caches instead + AbstractProcessingFilter now has various hook methods to assist subclasses + DaoAuthenticationProvider better detects AuthenticationDao interface violations + The User class has a new constructor (the old constructor is deprecated) + Fixed ambiguous column references in JdbcDaoImpl default query + Fixed AbstractProcessingFilter to use removeAttribute (JRun compatibility) + Fixed GrantedAuthorityEffectiveAclResolver support of UserDetails principals + Fixed HttpSessionIntegrationFilter "cannot commit to container" during logoff + Moved MethodSecurityInterceptor to ...intercept.method.aopalliance package + Documentation improvements + Test coverage improvements + + + Resolved to use http://apr.apache.org/versioning.html for future versioning + Added additional DaoAuthenticationProvider event when user not found + Added Authentication.getDetails() to DaoAuthenticationProvider response + Added DaoAuthenticationProvider.hideUserNotFoundExceptions (default=true) + Added PasswordAuthenticationProvider for password-validating DAOs (eg LDAP) + Added FilterToBeanProxy compatibility with ContextLoaderServlet (lazy inits) + Added convenience methods to ConfigAttributeDefinition + Improved sample applications' bean reference notation + Clarified contract for ObjectDefinitionSource.getAttributes(Object) + Extracted removeUserFromCache(String) to UserCache interface + Improved ConfigAttributeEditor so it trims preceding and trailing spaces + Refactored UsernamePasswordAuthenticationToken.getDetails() to Object + Fixed MethodDefinitionAttributes to implement ObjectDefinitionSource change + Fixed EH-CACHE-based caching implementation behaviour when cache exists + Fixed Ant "release" target not including project.properties + Fixed GrantedAuthorityEffectiveAclsResolver if null ACLs provided to method + Documentation improvements + + + Added domain object instance access control list (ACL) packages + Added feature so DaoAuthenticationProvider returns User in Authentication + Added AbstractIntegrationFilter.secureContext property for custom contexts + Added stack trace logging to SecurityEnforcementFilter + Added exception-specific target URLs to AbstractProcessingFilter + Added JdbcDaoImpl hook so subclasses can insert custom granted authorities + Added AuthenticationProvider that wraps JAAS login modules + Added support for EL expressions in the authz tag library + Added failed Authentication object to AuthenticationExceptions + Added signed JARs to all official release builds (see readme.txt) + Added remote client authentication validation package + Added protected sendAccessDeniedError method to SecurityEnforcementFilter + Updated Authentication to be serializable (Weblogic support) + Updated JAR to Spring 1.1 RC 1 + Updated to Clover 1.3 + Updated to HSQLDB version 1.7.2 Release Candidate 6D + Refactored User to net.sf.acegisecurity.UserDetails interface + Refactored CAS package to store UserDetails in CasAuthenticationToken + Improved organisation of DaoAuthenticationProvider to facilitate subclassing + Improved test coverage (now 98.3%) + Improved JDBC-based tests to use in-memory database rather than filesystem + Fixed Linux compatibility issues (directory case sensitivity etc) + Fixed AbstractProcessingFilter to handle servlet spec container differences + Fixed AbstractIntegrationFilter to resolve a Weblogic compatibility issue + Fixed CasAuthenticationToken if proxy granting ticket callback not requested + Fixed EH-CACHE handling on web context refresh + Documentation improvements + + + Added samples/quick-start + Added NullRunAsManager and made default for AbstractSecurityInterceptor + Added event notification (see net.sf.acegisecurity.providers.dao.event) + Updated JAR to Spring 1.0.2 + Updated JAR to Commons Attributes CVS snapshot from Spring 1.0.2 release + Updated GrantedAuthorityImpl to be serializable (JBoss support) + Updated Authentication interface to present extra details for a request + Updated Authentication interface to subclass java.security.Principal + Refactored DaoAuthenticationProvider caching (refer to reference docs) + Improved HttpSessionIntegrationFilter to manage additional attributes + Improved URL encoding during redirects + Fixed issue with hot deploy of EhCacheBasedTicketCache (used with CAS) + Fixed issue with NullPointerExceptions in taglib + Removed DaoAuthenticationToken and session-based caching + Documentation improvements + Upgrade Note: DaoAuthenticationProvider no longer has a "key" property + + + Added single sign on support via Yale Central Authentication Service (CAS) + Added full support for HTTP Basic Authentication + Added caching for DaoAuthenticationProvider successful authentications + Added Burlap and Hessian remoting to Contacts sample application + Added pluggable password encoders including plaintext, SHA and MD5 + Added pluggable salt sources to enhance security of hashed passwords + Added FilterToBeanProxy to obtain filters from Spring application context + Added support for prepending strings to roles created by JdbcDaoImpl + Added support for user definition of SQL statements used by JdbcDaoImpl + Added definable prefixes to avoid expectation of "ROLE_" GrantedAuthoritys + Added pluggable AuthenticationEntryPoints to SecurityEnforcementFilter + Added Apache Ant path syntax support to SecurityEnforcementFilter + Added filter to automate web channel requirements (eg HTTPS redirection) + Updated JAR to Spring 1.0.1 + Updated several classes to use absolute (not relative) redirection URLs + Refactored filters to use Spring application context lifecycle support + Improved constructor detection of nulls in User and other key objects + Fixed FilterInvocation.getRequestUrl() to also include getPathInfo() + Fixed Contacts sample application tags + Established acegisecurity-developer mailing list + Documentation improvements + + + Added HTTP session authentication as an alternative to container adapters + Added HTTP request security interceptor (offers considerable flexibility) + Added security taglib + Added Clover test coverage instrumentation (currently 97.2%) + Added support for Catalina (Tomcat) 4.1.30 to in-container integration tests + Added HTML test and summary reporting to in-container integration tests + Updated JARs to Spring Framework release 1.0, with associated AOP changes + Updated to Apache License version 2.0 + Updated copyright with permission of past contributors + Refactored unit tests to use mock objects and focus on a single class each + Refactored many classes to enable insertion of mock objects during testing + Refactored core classes to ease support of new secure object types + Changed package layout to better describe the role of contained items + Changed the extractor to extract additional classes from JBoss and Catalina + Changed Jetty container adapter configuration (see reference documentation) + Improved AutoIntegrationFilter handling of deployments without JBoss JARs + Fixed case handling support in data access object authentication provider + Documentation improvements + + + Added "in container" unit test system for container adapters and sample app + Added library extractor tool to reduce the "with deps" ZIP release sizes + Added unit test to the attributes sample + Added Jalopy source formatting + Modified all files to use net.sf.acegisecurity namespace + Renamed springsecurity.xml to acegisecurity.xml for consistency + Reduced length of ZIP and JAR filenames + Clarified licenses and sources for all included libraries + Updated documentation to reflect new file and package names + Setup Sourceforge.net project and added to CVS etc + + + Added Commons Attributes support and sample (thanks to Cameron Braid) + Added JBoss container adapter + Added Resin container adapter + Added JDBC DAO authentication provider + Added several filter implementations for container adapter integration + Added SecurityInterceptor startup time validation of ConfigAttributes + Added more unit tests + Refactored ConfigAttribute to interface and added concrete implementation + Enhanced diagnostics information provided by sample application debug.jsp + Modified sample application for wider container portability (Resin, JBoss) + Fixed switch block in voting decision manager implementations + Removed Spring MVC interceptor for container adapter integration + Documentation improvements + + + Initial public release + + + diff --git a/src/site/xdocs/index.xml b/src/site/xdocs/index.xml new file mode 100644 index 0000000000..6645f0bed7 --- /dev/null +++ b/src/site/xdocs/index.xml @@ -0,0 +1,239 @@ + + + + + Acegi Security System for Spring + + + + +
+
+
+

Acegi Security is a powerful, flexible security solution for enterprise software, + with a particular emphasis on applications that use + Spring. Using Acegi Security provides your + applications with comprehensive authentication, authorization, instance-based access control, + channel security and human user detection capabilities. +

+
+ + +
+
    +
  • Stable and mature. + Acegi Security 1.0.0 was released in May 2006 after + more than two and a half years of use in large production software projects, 70,000+ downloads + and hundreds of community contributions. + In terms of release numbering, we also use the Apache APR Project + Versioning Guidelines so that you can easily identify release + compatibility. +
    • +
  • Well documented: All APIs are fully documented using + JavaDoc, + with almost 100 pages of + Reference Guide documentation providing an easy-to-follow + introduction. Even more documentation is provided on this web site, as + shown in the left hand navigation sidebar.

    +
    • +
  • Fast results: View our suggested steps + for the fastest way to develop complex, security-compliant applications.

    +
    • +
  • Enterprise-wide single sign on: Using JA-SIG's open + source Central Authentication + Service (CAS), the Acegi Security can participate + in an enterprise-wide single sign on environment. You no longer need + every web application to have its own authentication database. Nor are + you restricted to single sign on across a single web container. Advanced + single sign on features like proxy support and forced refresh of logins + are supported by both CAS and Acegi Security.

    +
    • +
  • Reuses your Spring expertise: We use Spring application + contexts for all configuration, which should help Spring developers get + up-to-speed nice and quickly.

    +
    • +
  • Domain object instance security: In many applications it's + desirable to define Access Control Lists (ACLs) for individual domain + object instances. We provide a comprehensive ACL package with features + including integer bit masking, permission inheritence (including + blocking), a JDBC-backed ACL repository, caching and a pluggable, + interface-driven design.

    +
    • +
  • Non-intrusive setup: The entire security system can operate + within a single web application using the provided filters. There is no + need to make special changes or deploy libraries to your Servlet or EJB + container.

    +
    • +
  • Full (but optional) container integration: The credential + collection and authorization capabilities of your Servlet or EJB + container can be fully utilised via included "container adapters". We + currently support Catalina (Tomcat), Jetty, JBoss and Resin, with + additional containers easily added.

    +
    • +
  • Keeps your objects free of security code: Many applications + need to secure data at the bean level based on any combination of + parameters (user, time of day, authorities held, method being invoked, + parameter on method being invoked....). This package gives you this + flexibility without adding security code to your Spring business + objects.

    +
    • +
  • After invocation security: Acegi Security can not only protect + methods from being invoked in the first place, but it can also + deal with the objects returned from the methods. Included implementations + of after invocation security can throw an exception or mutate the returned + object based on ACLs.

    +
    • +
  • Secures your HTTP requests as well: In addition to securing + your beans, the project also secures your HTTP requests. No longer is it + necessary to rely on web.xml security constraints. Best of all, your + HTTP requests can now be secured by your choice of regular expressions + or Apache Ant paths, along with pluggable authentication, authorization + and run-as replacement managers.

    +
    • +
  • Channel security: Acegi Security can + automatically redirect requests across an appropriate transport channel. + Whilst flexible enough to support any of your "channel" requirements (eg + the remote user is a human, not a robot), a common channel security + feature is to ensure your secure pages will only be available over + HTTPS, and your public pages only over HTTP. Acegi Security also + supports unusual port combinations (including if accessed via an + intermediate server like Apache) and pluggable transport decision + managers.

    +
    • +
  • Supports HTTP BASIC authentication: Perfect for remoting + protocols or those web applications that prefer a simple browser pop-up + (rather than a form login), Acegi Security can directly process HTTP + BASIC authentication requests as per RFC 1945.

    +
    • +
  • Supports HTTP Digest authentication: For greater security than + offered by BASIC authentcation, Acegi Security also supports Digest Authentication + (which never sends the user's password across the wire). Digest Authentication + is widely supported by modern browsers. Acegi Security's implementation complies + with both RFC 2617 and RFC 2069.

    +
    • +
  • Computer Associates Siteminder support: Authentication can be + delegated through to CA's Siteminder solution, which is common in large + corporate environments.

    +
    • +
  • X509 (Certificate) support: Acegi Security can easily read + client-side X509 certificates for authenticating users.

    +
    • +
  • LDAP Support: Do you have an LDAP directory? Acegi Security can + happily authenticate against it.

    +
    • +
  • Tag library support: Your JSP files can use our taglib + to ensure that protected content like links and messages are only + displayed to users holding the appropriate granted authorities. The taglib + also fully integrates with Acegi Security's ACL services, and + obtaining extra information about the logged-in principal.

    +
    • +
  • Configuration via IoC XML, Commons Attributes, or JDK 5 Annotations: You + select the method used to configure your security environment. The + project supports configuration via Spring application contexts, as well + as Jakarta Commons Attributes and Java 5's annotations feature. Some users + (such as those building content management systems) pull configuration data + from a database, which exemplifies Acegi Security's flexible configuration + metadata system.

    +
    • +
  • Various authentication backends: We include the ability to + retrieve your user and granted authority definitions from an XML + file, JDBC datasource or Properties file. Alternatively, you can implement the + single-method UserDetailsService interface and obtain authentication details from + anywhere you like.

    +
    • +
  • Event support: Building upon Spring's + ApplicationEvent services, you can write your own listeners + for authentication-related events, along with authorisation-related events. + This enables you to implement account lockout and audit log systems, with + complete decoupling from Acegi Security code.

    +
    • +
  • Easy integration with existing databases: Our implementations + have been designed to make it very easy to use your existing + authentication schema and data (without modification). Of course, + you can also provide your own Data Access Object if you wish.

    +
    • +
  • Caching: Acegi Security integrates with Spring's EHCACHE factory. + This flexibility means your database (or other authentication + repository) is not repeatedly queried for authentication + information.

    +
    • +
  • Pluggable architecture: Every critical aspect of the package + has been modelled using high cohesion, loose coupling, interface-driven + design principles. You can easily replace, customise or extend parts of + the package.

    +
    • +
  • Startup-time validation: Every critical object dependency and + configuration parameter is validated at application context startup + time. Security configuration errors are therefore detected early and + corrected quickly.

    +
    • +
  • Remoting support: Does your project use a rich client? Not a + problem. Acegi Security integrates with standard Spring remoting + protocols, because it automatically processes the HTTP BASIC + authentication headers they present. Add our BASIC authentication filter + to your web.xml and you're done. You can also easily use RMI or Digest + authentication for your rich clients with a simple configuration statement.

    +
    • +
  • Advanced password encoding: Of course, passwords in your + authentication repository need not be in plain text. We support both SHA + and MD5 encoding, and also pluggable "salt" providers to maximise + password security. Acegi Security doesn't even need to see the password + if your backend can use a bind-based strategy for authentication (such as + an LDAP directory, or a database login).

    +
    • +
  • Run-as replacement: The system fully supports + temporarily replacing the authenticated principal for the duration of the web + request or bean invocation. This enables you to build public-facing + object tiers with different security configurations than your backend + objects.

    +
    • +
  • Transparent security propagation: Acegi Security can automatically + transfer its core authentication information from one machine to another, + using a variety of protocols including RMI and Spring's HttpInvoker.

    +
    • +
  • Compatible with HttpServletRequest's security methods: Even though + Acegi Security can deliver authentication using a range of pluggable mechanisms + (most of which require no web container configuration), we allow you to access + the resulting Authentication object via the getRemoteUser() and other + security methods on HttpServletRequest.

    +
    • +
  • Unit tests: A must-have of any quality security project, unit + tests are included. Our unit test coverage is very high, as shown in the + coverage report.

    +
    • +
  • Built by Maven: This assists you in effectively reusing the Acegi + Security artifacts in your own Maven-based projects.

    +
    • +
  • Supports your own unit tests: We provide a number of classes + that assist with your own unit testing of secured business objects. For + example, you can change the authentication identity and its associated + granted authorities directly within your test methods.

    +
    • +
  • Peer reviewed: Whilst nothing is ever completely secure, + using an open source security package leverages the continuous design + and code quality improvements that emerge from peer review.

    +
    • +
  • Community: Well-known for its supportive community, Acegi Security + has an active group of developers and users. Visit our project resources (below) + to access these services.

    +
    • +
  • Apache license. You can confidently use Acegi Security in your project.

    • + +

+ + +
+ +
+

+ Support Forums

+ Developer Mailing List

+ Downloads +

+
+ + + + \ No newline at end of file diff --git a/src/site/xdocs/reference.xml b/src/site/xdocs/reference.xml new file mode 100644 index 0000000000..42c087e1d0 --- /dev/null +++ b/src/site/xdocs/reference.xml @@ -0,0 +1,69 @@ + + + + + + + + Reference Documentation + + + +
+ + + + + + + + + + + + + + + + + +
DocumentDescription
+ Reference Guide HTML Single Page + + The reference guide in a single html page. +
+ Reference Guide PDF + + The PDF version of the reference guide. +
+ +
+ +