From a5ed80248d8c4d077e6e30ce97b1cc03e665b6bb Mon Sep 17 00:00:00 2001 From: Luke Taylor Date: Thu, 6 Mar 2008 17:15:30 +0000 Subject: [PATCH] SEC-696: Updated out of date information in site files and pom. Added aggregation of javadoc and other reports --- pom.xml | 42 +++++++- src/site/apt/building.apt | 36 +++++++ src/site/apt/index.apt | 215 ++----------------------------------- src/site/fml/faq.fml | 92 ++++++++++++++++ src/site/site.xml | 76 ++++--------- src/site/xdoc/building.xml | 40 ------- 6 files changed, 197 insertions(+), 304 deletions(-) create mode 100644 src/site/apt/building.apt create mode 100644 src/site/fml/faq.fml delete mode 100644 src/site/xdoc/building.xml diff --git a/pom.xml b/pom.xml index d03b562def..8b83e9bf90 100644 --- a/pom.xml +++ b/pom.xml @@ -48,8 +48,12 @@ jira - http://opensource.atlassian.com/projects/spring/browse/SEC + http://jira.springframework.org/browse/SEC + + bamboo + http://build.springframework.org:8085/bamboo/ + @@ -88,6 +92,13 @@ + + + Codehaus Snapshots + http://snapshots.repository.codehaus.org/ + + + Acegi Developer List @@ -118,7 +129,7 @@ benalex benalex at users.sourceforge.net - Acegi Technology Pty Limited (http://www.acegi.com.au) + SpringSource +10 @@ -138,7 +149,7 @@ luke_t luke_t at users.sourceforge.net - Monkey Machine Ltd. (http://monkeymachine.ltd.uk) + SpringSource 0 @@ -468,10 +479,16 @@ org.apache.maven.plugins maven-surefire-report-plugin 2.3.1 + + true + org.apache.maven.plugins maven-jxr-plugin + + true + + + + org.codehaus.mojo @@ -539,6 +569,7 @@ org.apache.maven.plugins maven-project-info-reports-plugin 2.0.1 + + diff --git a/src/site/apt/building.apt b/src/site/apt/building.apt new file mode 100644 index 0000000000..ef56e08f30 --- /dev/null +++ b/src/site/apt/building.apt @@ -0,0 +1,36 @@ + ------------------------ + Building the Project + ------------------------ + +Building the Project + +* Install Maven + + This project uses {{{"http://maven.apache.org/"}Maven}} as a build tool. + We recommend you to install Maven 2.0.7 or greater before trying + the following. + +* Check out the source code + + To checkout Spring Security from SVN, see our {{{"svn-usage.html"}SVN Usage}} page. + +* Building with Maven + + Often people reading this document just want to see if Spring Security will work + for their projects. They want to deploy a sample application, and perhaps play around with the + configuration a bit to see how it works. Assuming you've already checked out the code from subversion, + start up a command prompt and execute the following commands from the directory containing the project source: + ++----------------------------------------------------------------------------------------------------------------------+ + + mvn install + + cd samples/contacts + + mvn jetty:run + ++----------------------------------------------------------------------------------------------------------------------+ + + This should build the framework library jars, install them to your local Maven repository and run the "contacts" + sample application (JDK 1.5 or later is required). You should then be able to point your browser at + {{{http://localhost:8080/contacts/}}} to use the application. \ No newline at end of file diff --git a/src/site/apt/index.apt b/src/site/apt/index.apt index a8366fad1b..3ca249a5ea 100644 --- a/src/site/apt/index.apt +++ b/src/site/apt/index.apt @@ -4,207 +4,14 @@ What is Spring Security? - Spring Security is a powerful, flexible security solution for enterprise software, - with a particular emphasis on applications that use - {{{http://www.springframework.org/}Spring}}. Using Spring 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 Spring 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 Spring Security. Several other SSO solutions - are also provided by third party projects, including JOSSO and CAS. - - * <> 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. - - * <> Spring 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. - - * <> Spring 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. Spring 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), Spring Security can directly process HTTP - BASIC authentication requests as per RFC 1945. - - * <> For greater security than - offered by BASIC authentcation, Spring Security also supports Digest Authentication - (which never sends the user's password across the wire). Digest Authentication - is widely supported by modern browsers. Spring 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. - - * <> Spring Security can easily read - client-side X509 certificates for authenticating users. - - * <> Do you have an LDAP directory? Spring 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 Spring 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 Spring 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 - <<>> 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 Spring 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. - - * <> Spring 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. Spring 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. Spring 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. - - * <> Spring 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 - Spring 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 - {{{acegi-security/cobertura/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, Spring Security - has an active group of developers and users. Visit our project resources (below) - to access these services. - - * <> You can confidently use Spring Security in your project. + Spring Security is the renamed Acegi Security System for Spring, which became an official Spring + Portfolio project towards the end of 2007. It is the portolio's security offering, focused on providing a powerful and + flexible security solution for enterprise applications developed using the Spring Framework. + It is a stable and mature product - 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. + + Spring Security 2.0 builds on Acegi Security's solid foundations, adding new features such as a simplified + namespace configuration syntax. + + + ~~ TODO: Expand based on original Acegi page. \ No newline at end of file diff --git a/src/site/fml/faq.fml b/src/site/fml/faq.fml new file mode 100644 index 0000000000..7ff0d4f7d4 --- /dev/null +++ b/src/site/fml/faq.fml @@ -0,0 +1,92 @@ + + + + + General + + 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 (i.e. your methods that implement + business logic), and domain object instance security (i.e. 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 Spring Security you achieve complete portability - right down to the + WAR level. Also, Spring 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. + Spring 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. +

+ + + + + \ No newline at end of file diff --git a/src/site/site.xml b/src/site/site.xml index 7cfd4962f3..d2bd85b2ba 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -1,76 +1,42 @@ - - - Spring Security on Sourceforge - http://sourceforge.net/sflogo.php?group_id=104215&type=5 - http://sourceforge.net/projects/acegisecurity - - - Spring Security - images/logo.gif - http://acegisecurity.org/ - - + + org.springframework.maven.skins + maven-spring-skin + 1.0.4 + + + + Spring Security + http://www.springframework.org/files/logo.jpg + + http://static.springframework.org/spring-security/ + + + - - + + - - - - - - - - - - - - + + - + + - - - - - diff --git a/src/site/xdoc/building.xml b/src/site/xdoc/building.xml deleted file mode 100644 index c1ac8dc2fc..0000000000 --- a/src/site/xdoc/building.xml +++ /dev/null @@ -1,40 +0,0 @@ - - - Building - -
- - - -

This project uses Maven as project manager - and build tool. We recommend you to install Maven 2.0.5 or greater before trying - the following.

To checkout Spring Security from SVN, see our - SVN Usage page.

- - - -

Often people reading this document just want to see if Spring 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). - Assuming you've already checked out the code from subversion, start up a command prompt and - execute the following commands from the directory containing the project source:

-
    - 
    mvn install
    - 
    cd samples/contacts
    - 
    mvn jetty:run
    -
- -

This should build the framework lirary jars, install them to your local maven repository and run the "contacts" - sample application using the maven jetty plugin (JDK 1.5 or later is required to run the Jetty plugin). - You should then be able to point your browser at - http://localhost:8080/contacts/ to use the application. -

- - - -
- - - - \ No newline at end of file