diff --git a/doc/docbook/images/ACLSecurity.gif b/doc/docbook/images/ACLSecurity.gif new file mode 100644 index 0000000000..7a0d0aa823 Binary files /dev/null and b/doc/docbook/images/ACLSecurity.gif differ diff --git a/doc/docbook/images/AccessDecisionVoting.gif b/doc/docbook/images/AccessDecisionVoting.gif new file mode 100644 index 0000000000..5e95bf9f96 Binary files /dev/null and b/doc/docbook/images/AccessDecisionVoting.gif differ diff --git a/doc/docbook/images/AfterInvocation.gif b/doc/docbook/images/AfterInvocation.gif new file mode 100644 index 0000000000..4a27abd650 Binary files /dev/null and b/doc/docbook/images/AfterInvocation.gif differ diff --git a/doc/docbook/images/Authentication.gif b/doc/docbook/images/Authentication.gif new file mode 100644 index 0000000000..2111d2e380 Binary files /dev/null and b/doc/docbook/images/Authentication.gif differ diff --git a/doc/docbook/images/BasicAclProvider.gif b/doc/docbook/images/BasicAclProvider.gif new file mode 100644 index 0000000000..4eb4934ff6 Binary files /dev/null and b/doc/docbook/images/BasicAclProvider.gif differ diff --git a/doc/docbook/images/Context.gif b/doc/docbook/images/Context.gif new file mode 100644 index 0000000000..9d63b197ff Binary files /dev/null and b/doc/docbook/images/Context.gif differ diff --git a/doc/docbook/images/SecurityInterception.gif b/doc/docbook/images/SecurityInterception.gif new file mode 100644 index 0000000000..a8f0150ca7 Binary files /dev/null and b/doc/docbook/images/SecurityInterception.gif differ diff --git a/doc/docbook/index.xml b/doc/docbook/index.xml index 1573f2bac6..dc9768b86c 100644 --- a/doc/docbook/index.xml +++ b/doc/docbook/index.xml @@ -26,7 +26,7 @@ Reference Documentation - 0.7-SNAPSHOT + 0.7.0-SNAPSHOT @@ -73,7 +73,7 @@ Introduction The Acegi Security System for Spring provides authentication and - authorization capabilities for Spring-powered projects, with full + authorization capabilities for Spring-powered projects, with optional integration with popular web containers. The security architecture was designed from the ground up using "The Spring Way" of development, which includes using bean contexts, interceptors and interface-driven @@ -91,8 +91,9 @@ Throughout the Acegi Security System for Spring, the user, system or agent that needs to be authenticated is referred to as a "principal". The security architecture does not have a notion of roles or groups, - which you may be familiar with from other security - implementations. + which you may be familiar with from other security implementations, + although equivalent functionality is fully accommodated by Acegi + Security. Current Status @@ -156,7 +157,16 @@ Key Components - The Acegi Security System for Spring essentially comprises seven + Most enterprise applications have four basic security + requirements. First, they need to be able to authenticate a principal. + Second, they need to be able to secure web requests. Third, enterprise + applications need to be able to secure services layer methods. + Finally, quite often an enterprise application will need to secure + domain object instances. Acegi Security provides a comprehensive + framework for achieving all of these four common enterprise + application security requirements. + + The Acegi Security System for Spring essentially comprises eight key functional parts: @@ -193,23 +203,51 @@ A "secure object" interceptor, which coordinates the - authentication, authorization, run-as replacement and execution of - a given operation. + authentication, authorization, run-as replacement, after + invocation handling and execution of a given operation. + + + + An AfterInvocationManager which can + modify an Object returned from a "secure + object" invocation, such as removing Collection + elements a principal does not have authority to access. An acess control list (ACL) management package, which can be - used to obtain ACLs for domain object instances. + used to obtain the ACLs applicable for domain object + instances. - Secure objects refer to any type of object that can have - security applied to it. A secure object must provide some form of - callback, so that the security interceptor can transparently do its - work as required, and callback the object when it is time for it to - proceed with the requested operation. If secure objects cannot provide - a native callback approach, a wrapper needs to be written so this - becomes possible. + A "secure object" interceptor executes most of the Acegi + Security key classes and in doing so delivers the framework's major + features. Given its importance, Figure 1 shows the key relationships + and concrete implementations of + AbstractSecurityInterceptor. + + + + + + + + Figure 1: The key "secure object" model + + + + Each "secure object" interceptor (hereinafter called a "security + interceptor") works with a particular type of "secure object". So, + what is a secure object? Secure objects refer to any type of object + that can have security applied to it. A secure object must provide + some form of callback, so that the security interceptor can + transparently do its work as required, and callback the object when it + is time for it to proceed with the requested operation. If secure + objects cannot provide a native callback approach, a wrapper needs to + be written so this becomes possible. Each secure object has its own package under net.sf.acegisecurity.intercept. Every other package @@ -221,20 +259,21 @@ directly. For example, it would be possible to build a new secure object to secure calls to a messaging system that does not use MethodInvocations. Most Spring applications will - simply use the three currently supported secure object types - (MethodInvocation, JoinPoint and + simply use the three currently supported secure object types (AOP + Alliance MethodInvocation, AspectJ + JoinPoint and web request FilterInterceptor) with complete transparency. - Each of the seven key parts is discussed in detail throughout - this document. + Each of the eight key parts of Acegi Security are discussed in + detail throughout this document. Supported Secure Objects - The Acegi Security System for Spring currently supports three - secure objects. + As shown in the base of Figure 1, the Acegi Security System for + Spring currently supports three secure objects. The first handles an AOP Alliance MethodInvocation. This is the secure object type @@ -340,6 +379,17 @@ for Spring uses the request context to pass around the authentication request and response. + + + + + + + Figure 2: The ContextHolder + + + A request context is a concrete implementation of the Context interface, which exposes a single method: @@ -454,19 +504,28 @@ - Return any result received from the secure object - execution. + If an AfterInvocationManager is defined, + pass it the result of the secure object execution so that it may + throw an AccessDeniedException or mutate the + returned object if required. + + + + Return any result received from the + AfterInvocationManager, or if no + AfterInvocationManager is defined, simply + return the result provided by the secure object execution. Whilst this may seem quite involved, don't worry. Developers interact with the security process by simply implementing basic interfaces (such as AccessDecisionManager), which - are fully documented below. + are fully discussed below. The AbstractSecurityInterceptor handles the - majority of the flow listed above. Each secure object has its own - security interceptor which subclasses + majority of the flow listed above. As shown in Figure 1, each secure + object has its own security interceptor which subclasses AbstractSecurityInterceptor. Each of these secure object-specific security interceptors are discussed below. @@ -495,6 +554,7 @@ <property name="authenticationManager"><ref bean="authenticationManager"/></property> <property name="accessDecisionManager"><ref bean="accessDecisionManager"/></property> <property name="runAsManager"><ref bean="runAsManager"/></property> + <property name="afterInvocationManager"><ref bean="afterInvocationManager"/></property> <property name="objectDefinitionSource"> <value> net.sf.acegisecurity.context.BankManager.delete*=ROLE_SUPERVISOR,RUN_AS_SERVER @@ -508,8 +568,10 @@ AuthenticationManager, AccessDecisionManager and RunAsManager, which are each discussed in separate - sections below. The MethodSecurityInterceptor is - also configured with configuration attributes that apply to different + sections below. In this case we've also defined an + AfterInvocationManager, although this is entirely + optional. The MethodSecurityInterceptor is also + configured with configuration attributes that apply to different method signatures. A full discussion of configuration attributes is provided in the High Level Design section of this document. @@ -635,6 +697,7 @@ <property name="authenticationManager"><ref bean="authenticationManager"/></property> <property name="accessDecisionManager"><ref bean="accessDecisionManager"/></property> <property name="runAsManager"><ref bean="runAsManager"/></property> + <property name="afterInvocationManager"><ref bean="afterInvocationManager"/></property> <property name="objectDefinitionSource"> <value> net.sf.acegisecurity.context.BankManager.delete*=ROLE_SUPERVISOR,RUN_AS_SERVER @@ -784,7 +847,7 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean { Spring: AuthenticationProcessingFilterEntryPoint for commencing a form-based authentication, BasicProcessingFilterEntryPoint for commencing a - Http Basic authentication process, and + HTTP Basic authentication process, and CasProcessingFilterEntryPoint for commencing a Yale Central Authentication Service (CAS) login. The AuthenticationProcessingFilterEntryPoint and @@ -919,8 +982,21 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean { authorities that have been granted to the principal. The principal and its credentials are populated by the client code, whilst the granted authorities are populated by the - AuthenticationManager. The Acegi Security System - for Spring includes several concrete Authentication + AuthenticationManager. + + + + + + + + Figure 3: Key Authentication Architecture + + + + As shown in Figure 3, the Acegi Security System for Spring + includes several concrete Authentication implementations: @@ -1177,7 +1253,10 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean { User will be used directly or subclassed, although special circumstances (such as object relational mappers) may require users to write their own UserDetails implementation - from scratch. + from scratch. UserDetails is often used to store + additional principal-related properties (such as their telephone + number and email address), so they can be easily used by web + views. Given AuthenticationDao is so simple to implement, it should be easy for users to retrieve authentication @@ -1626,7 +1705,21 @@ public boolean supports(Class clazz); AccessDecisionManager to control all aspects of authorization, the Acegi Security System for Spring includes several AccessDecisionManager implementations that are - based on voting. Using this approach, a series of + based on voting. Figure 4 illustrates the relevant classes. + + + + + + + + Figure 4: Voting Decision Manager + + + + Using this approach, a series of AccessDecisionVoter implementations are polled on an authorization decision. The AccessDecisionManager then decides whether or not @@ -1676,12 +1769,12 @@ public boolean supports(Class clazz); weighting, whilst a deny vote from a particular voter may have a veto effect. - There is one concrete AccessDecisionVoter - implementation provided with the Acegi Security System for Spring. The - RoleVoter class will vote if any ConfigAttribute - begins with ROLE_. It will vote to grant access if - there is a GrantedAuthority which returns a - String representation (via the + There are two concrete AccessDecisionVoter + implementations provided with the Acegi Security System for Spring. + The RoleVoter class will vote if any + ConfigAttribute begins with ROLE_. It will vote to + grant access if there is a GrantedAuthority which + returns a String representation (via the getAuthority() method) exactly equal to one or more ConfigAttributes starting with ROLE_. If there is no exact match of any @@ -1692,7 +1785,61 @@ public boolean supports(Class clazz); RoleVoter is case sensitive on comparisons as well as the ROLE_ prefix. - It is possible to implement a custom + BasicAclEntryVoter is the other concrete voter included with + Acegi Security. It integrates with Acegi Security's + AclManager (discussed later). This voter is + designed to have multiple instances in the same application context, + such as: + + <bean id="aclContactReadVoter" class="net.sf.acegisecurity.vote.BasicAclEntryVoter"> + <property name="processConfigAttribute"><value>ACL_CONTACT_READ</value></property> + <property name="processDomainObjectClass"><value>sample.contact.Contact</value></property> + <property name="aclManager"><ref local="aclManager"/></property> + <property name="requirePermission"> + <list> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.READ"/> + </list> + </property> +</bean> + +<bean id="aclContactDeleteVoter" class="net.sf.acegisecurity.vote.BasicAclEntryVoter"> + <property name="processConfigAttribute"><value>ACL_CONTACT_DELETE</value></property> + <property name="processDomainObjectClass"><value>sample.contact.Contact</value></property> + <property name="aclManager"><ref local="aclManager"/></property> + <property name="requirePermission"> + <list> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.DELETE"/> + </list> + </property> +</bean> + + In the above example, you'd define + ACL_CONTACT_READ or + ACL_CONTACT_DELETE against some methods on a + MethodSecurityInterceptor or + AspectJSecurityInterceptor. When those methods are + invoked, the above applicable voter defined above would vote to grant + or deny access. The voter would look at the method invocation to + locate the first argument of type + sample.contact.Contact, and then pass that + Contact to the AclManager. The + AclManager will then return an access control list + (ACL) that applies to the current Authentication. + Assuming that ACL contains one of the listed + requirePermissions, the voter will vote to grant + access. If the ACL does not contain one of the permissions defined + against the voter, the voter will vote to deny access. + BasicAclEntryVoter is an important class as it + allows you to build truly complex applications with domain object + security entirely defined in the application context. If you're + interested in learning more about Acegi Security's ACL capabilities + and how best to apply them, please see the ACL and "After Invocation" + sections of this reference guide, and the Contacts sample + application. + + It is also possible to implement a custom AccessDecisionVoter. Several examples are provided in the Acegi Security System for Spring unit tests, including ContactSecurityVoter and @@ -1713,23 +1860,39 @@ public boolean supports(Class clazz); - Authorization Tag Library + Authorization-Related Tag Libraries - The Acegi Security System for Spring comes bundled with a JSP - tag library that eases JSP writing. The tag library is known as - authz. + The Acegi Security System for Spring comes bundled with several + JSP tag libraries that eases JSP writing. The tag libraries are known + as authz and provide a range of different + services. - This library allows you to easy develop JSP pages which - reference the security environment. For example, - authz allows you to determine if a principal holds - a particular granted authority, holds a group of granted authorities, - or does not hold a given granted authority. + All taglib classes are included in the core + acegi-security-xx.jar file, with the + authz.tld located in the JAR's + META-INF directory. This means for JSP 1.2+ web + containers you can simply include the JAR in the WAR's + WEB-INF/lib directory and it will be available. If + you're using a JSP 1.1 container, you'll need to declare the JSP + taglib in your web.xml file, and include + authz.tld in the WEB-INF/lib + directory. The following fragment is added to + web.xml: + + <taglib> + <taglib-uri>http://acegisecurity.sf.net/authz</taglib-uri> + <taglib-location>/WEB-INF/authz.tld</taglib-location> +</taglib> - Usage + AuthorizeTag + + AuthorizeTag is used to include content if + the current principal holds certain + GrantedAuthoritys. The following JSP fragment illustrates how to use the - authz taglib: + AuthorizeTag: <authz:authorize ifAllGranted="ROLE_SUPERVISOR"> <td> @@ -1737,40 +1900,8 @@ public boolean supports(Class clazz); </td> </authz:authorize> - This code was copied from the Contacts sample - application. - - What this code says is: if the principal has been granted - ROLE_SUPERVISOR, allow the tag's body to be output. - - - - Installation - - Installation is a simple matter. Simply copy the - acegi-security-taglib.jar file into your - application's WEB-INF/lib folder. The tag library - includes it's TLD, which makes it easier to work with JSP 1.2+ - containers. - - If you are using a JSP 1.1 container, you will need to declare - the JSP tag library in your application's web.xml - file, with code such as this: - - <taglib> - <taglib-uri>http://acegisecurity.sf.net/authz</taglib-uri> - <taglib-location>/WEB-INF/authz.tld</taglib-location> -</taglib> - - For JSP 1.1 containers you will also need to extract the - authz.tld file from the - acegi-security-taglib.jar file and put it into - your application's WEB-INF/lib folder. Use a - regular Zip tool, or Java's JAR utility. - - - - Reference + This tag would cause the tag's body to be output if the + principal has been granted ROLE_SUPERVISOR. The authz:authorize tag declares the following attributes: @@ -1819,6 +1950,50 @@ public boolean supports(Class clazz); ifAllGranted, and finally, ifAnyGranted. + + + AuthenticationTag + + AuthenticationTag is used to simply output + the current principal to the web page. + + The following JSP fragment illustrates how to use the + AuthenticationTag: + + <authz:authentication operation="principal"/> + + This tag would cause the principal's name to be output. The + taglib properly supports the various types of principals that can + exist in the Authentication object, such as a + String or UserDetails + instance. + + The "operation" attribute must always be "principal". This may + be expanded in the future, such as obtaining other + Authentication-related properties such as email + address or telephone numbers. + + + + AclTag + + AclTag is used to include content if the + current principal has a ACL to the indicated domain object. + + The following JSP fragment illustrates how to use the + AclTag: + + <authz:acl domainObject="${contact}" hasPermission="16,1"> + <td><A HREF="<c:url value="del.htm"><c:param name="contactId" value="${contact.id}"/></c:url>">Del</A></td> +</authz:acl> + + This tag would cause the tag's body to be output if the + principal holds either permission 16 or permission 1 for the + "contact" domain object. The numbers are actually integers that are + used with AbstractBasicAclEntry bit masking. + Please refer tro the ACL section of this reference guide to + understand more about the ACL capabilities of Acegi Security. + @@ -1852,6 +2027,115 @@ public boolean supports(Class clazz); + + After Invocation Handling + + + Overview + + Whilst the AccessDecisionManager is called by + the AbstractSecurityInterceptor before proceeding + with the secure object invocation, some applications need a way of + modifying the object actually returned by the secure object + invocation. Whilst you could easily implement your own AOP concern to + achieve this, Acegi Security provides a convenient hook that has + several concrete implementations that integrate with its ACL + capabilities. + + Figure 4 illustrates Acegi Security's + AfterInvocationManager and its concrete + implementations. + + + + + + + + Figure 4: After Invocation Implementation + + + + Like many other parts of Acegi Security, + AfterInvocationManager has a single concrete + implementation, AfterInvocationProvider, which + polls a list of AfterInvocationProviders. Each + AfterInvocationProvider is allowed to modify the + return object or throw an AccessDeniedException. + Indeed multiple providers can modify the object, as the result of the + previous provider is passed to the next in the list. Let's now + consider our ACL-aware implementations of + AfterInvocationProvider. + + + + ACL-Aware AfterInvocationProviders + + A common services layer method we've all written at one stage or + another looks like this: + + public Contact getById(Integer id); + + Quite often, only principals with permission to read the + Contact should be allowed to obtain it. In this + situation the AccessDecisionManager approach + provided by the AbstractSecurityInterceptor will + not suffice. This is because the identity of the + Contact is all that is available before the secure + object is invoked. The + BasicAclAfterInvocationProvider delivers a + solution, and is configured as follows: + + <bean id="afterAclRead" class="net.sf.acegisecurity.afterinvocation.BasicAclEntryAfterInvocationProvider"> + <property name="aclManager"><ref local="aclManager"/></property> + <property name="requirePermission"> + <list> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.READ"/> + </list> + </property> +</bean> + + In the above example, the Contact will be + retrieved and passed to the + BasicAclEntryAfterInvocationProvider. The provider + will thrown an AccessDeniedException if one of the + listed requirePermissions is not held by the + Authentication. The + BasicAclEntryAfterInvocationProvider queries the + AclManager to determine the ACL that applies for + this domain object to this Authentication. + + Similar to the + BasicAclEntryAfterInvocationProvider is + BasicAclEntryAfterInvocationCollectionFilteringProvider. + It is designed to remove Collection elements for + which a principal does not have access. It never thrown an + AccessDeniedException - simply silently removes the + offending elements. The provider is configured as follows: + + <bean id="afterAclCollectionRead" class="net.sf.acegisecurity.afterinvocation.BasicAclEntryAfterInvocationCollectionFilteringProvider"> + <property name="aclManager"><ref local="aclManager"/></property> + <property name="requirePermission"> + <list> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/> + <ref local="net.sf.acegisecurity.acl.basic.SimpleAclEntry.READ"/> + </list> + </property> +</bean> + + As you can imagine, the returned Object must + be a Collection for this provider to operate. It + will remove any element if the AclManager indicates + the Authentication does not hold one of the listed + requirePermissions. + + The Contacts sample application demonstrates these two + AfterInvocationProviders. + + + Run-As Authentication Replacement @@ -1875,7 +2159,11 @@ public boolean supports(Class clazz); secured invocation will be able to call other objects which require different authentication and authorization credentials. It will also be able to perform any internal security checks for specific - GrantedAuthority objects. + GrantedAuthority objects. Because Acegi Security + provides a number of helper classes that automatically configure + remoting protocols based on the contents of the + ContextHolder, these run-as replacements are + particularly useful when calling remote web services. @@ -1962,12 +2250,12 @@ public boolean supports(Class clazz); Authentication object. Developers are free to do this in whichever way they like, such as directly calling the relevant objects at runtime. However, several classes have been provided to - make this process transparent in many situations. + make this process transparent in many situations. We call these + classes "authentication mechanisms". - The net.sf.acegisecurity.ui package is - designed to make interfacing web application user interfaces with the - ContextHolder as simple as possible. There are two - major steps in doing this: + The net.sf.acegisecurity.ui package provides + authentication mechanisms for web applications. There are two major + steps in doing this: @@ -1985,18 +2273,19 @@ public boolean supports(Class clazz); There are several alternatives are available for the first step, - which will be briefly discussed in this chapter. The most popular - approach is HTTP Session Authentication, which uses the - HttpSession object and filters to authenticate the - user. Another approach is HTTP Basic Authentication, which allows - clients to use HTTP headers to present authentication information to - the Acegi Security System for Spring. Alternatively, you can also use - Yale Central Authentication Service (CAS) for enterprise-wide single - sign on. The final approach is via Container Adapters, which allow - supported web containers to perform the authentication themselves. - HTTP Session and Basic Authentication is discussed below, whilst CAS - and Container Adapters are discussed in separate sections of this - document. + which will be briefly discussed in this chapter. The most popular (and + almost always recommended) approach is HTTP Session Authentication, + which uses the HttpSession object and filters to + authenticate the user. Another approach (commonly use with web + services) is HTTP Basic Authentication, which allows clients to use + HTTP headers to present authentication information to the Acegi + Security System for Spring. Alternatively, you can also use Yale + Central Authentication Service (CAS) for enterprise-wide single sign + on. The final (generally unrecommended) approach is via Container + Adapters, which allow supported web containers to perform the + authentication themselves. HTTP Session and Basic Authentication is + discussed below, whilst CAS and Container Adapters are discussed in + separate sections of this document. @@ -2485,7 +2774,7 @@ $CATALINA_HOME/bin/startup.sh installation. There are two different ways of making spring context available - to the Jboss integration classes. + to the Jboss integration classes. The first approach is by editing your $JBOSS_HOME/server/your_config/conf/login-config.xml @@ -3412,9 +3701,6 @@ $CATALINA_HOME/bin/startup.sh Overview - THIS FEATURE WAS ADDED IN VERSION 0.6. WE WELCOME YOUR COMMENTS - AND IMPROVEMENTS. - Complex applications often will find the need to define access permissions not simply at a web request or method invocation level. Instead, security decisions need to comprise both who @@ -3497,9 +3783,22 @@ $CATALINA_HOME/bin/startup.sh The net.sf.acegisecurity.acl Package The net.sf.acegisecurity.acl package is very - simple, comprising only a handful of interfaces and a single class. It - provides the basic foundation for access control list (ACL) lookups. - The central interface is AclManager, which is + simple, comprising only a handful of interfaces and a single class, as + shown in Figure 5. It provides the basic foundation for access control + list (ACL) lookups. + + + + + + + + Figure 5: Access Control List Manager + + + + The central interface is AclManager, which is defined by two methods: public AclEntry[] getAcls(java.lang.Object domainInstance); @@ -3548,12 +3847,25 @@ public AclEntry[] getAcls(java.lang.Object domainInstance, Authentication authen Integer Masked ACLs Acegi Security System for Spring includes a production-quality - ACL provider implementation. The implementation is based on integer - masking, which is commonly used for ACL permissions given its - flexibility and speed. Anyone who has used Unix's - chmod command will know all about this type of - permission masking (eg chmod 777). You'll find the - classes and interfaces for the integer masking ACL package under + ACL provider implementation, which is shown in Figure 6. + + + + + + + + Figure 6: Basic ACL Manager + + + + The implementation is based on integer masking, which is + commonly used for ACL permissions given its flexibility and speed. + Anyone who has used Unix's chmod command will know + all about this type of permission masking (eg chmod + 777). You'll find the classes and interfaces for the integer + masking ACL package under net.sf.acegisecurity.acl.basic. Extending the AclEntry interface is a @@ -3620,9 +3932,12 @@ public java.lang.Object getRecipient(); Acegi Security includes a single BasicAclDao implementation called JdbcDaoImpl. As implied by - the name, it accesses ACL information from a JDBC database. The - default database schema and some sample data will aid in understanding - its function: + the name, JdbcDaoImpl accesses ACL information from + a JDBC database. There is also an extended version of this DAO, + JdbcExtendedDaoImpl, which provides CRUD operations + on the JDBC database, although we won't discuss these features here. + The default database schema and some sample data will aid in + understanding its function: CREATE TABLE acl_object_identity ( id IDENTITY NOT NULL,