Download acegi security .jar

The authentication manager contacts an authentication provider to get a UserDetails object from a UserDetailsService. If authentication is successful, the user's granted authorities application-wide permissions are populated in the returned UserDetails object. This information is used to build the authentication object, which is then stored in Acegi's security context which is created by yet another filter.

The security context is associated with the current execution thread by the security context holder. The security context is stored as a session attribute and used for authorization checks by Acegi in the Web layer.

I assume you are familiar with basic JSF application development, and so will not describe the steps involved in configuring a JSF application, such as defining the JSF servlet and providing the servlet mapping. I also assume, for the sake of this example, that we have already registered a ContextLoaderListener to load the Spring application context when the application starts up.

Download the sample application code for details. Assuming that the above configurations are complete, the first step toward integrating Acegi with JSF is to configure Acegi's filters and direct all requests and forwards to be routed through them. Instead of registering all the Acegi filters individually in web. The Acegi filter chain invokes the filters added to its property list in the Spring context file.

Acegi's FilterToBeanProxy class implements the javax. Filter interface; hence its doFilter method is invoked by the servlet container when the request for a JSF page is received.

This means no authentication processing mechanism need ever interact directly with HttpSession. Indeed HttpSessionContextIntegrationFilter has been designed to minimise the unnecessary creation of HttpSession s, as might occur when using Basic authentication for example.

There are several authentication processing mechanisms included with Acegi Security, which will be briefly discussed in this chapter. The most popular and almost always recommended approach is HTTP Form Authentication, which uses a login form to authenticate the user. The final and generally unrecommended approach is via Container Adapters, which allow supported web containers to perform the authentication themselves. The filter is defined in web.

The application context will need to define the AuthenticationProcessingFilter :. The configured AuthenticationManager processes each authentication request.

If authentication fails, the browser will be redirected to the authenticationFailureUrl. If authentication is successful, the resulting Authentication object will be placed into the SecurityContextHolder. This attribute is automatically set by the SecurityEnforcementFilter when an AuthenticationException occurs, so that after login is completed the user can return to what they were trying to access.

Because this authentication approach is fully contained within a single web application, HTTP Form Authentication is recommended to be used instead of Container Adapters.

This can be used for authenticating calls made by Spring remoting protocols such as Hessian and Burlap , as well as normal user agents such as Internet Explorer and Navigator. Basic Authentication is an attractive approach to authentication, because it is very widely deployed in user agents and implementation is extremely simple it's just a Base64 encoding of the username:password, specified in a HTTP header. The application context will need to define the BasicProcessingFilter and its required collaborator:.

If authentication fails, the configured AuthenticationEntryPoint will be used to retry the authentication process. If the authentication event was successful, or authentication was not attempted because the HTTP header did not contain a supported authentication request, the filter chain will continue as normal.

The only time the filter chain will be interrupted is if authentication fails and the AuthenticationEntryPoint is called, as discussed in the previous paragraph. Digest Authentication attempts to solve many of the weakenesses of Basic authentication, specifically by ensuring credentials are never sent in clear text across the wire.

Most user agents implement RFC Digest Authentication is definitely the most secure choice between Form Authentication, Basic Authentication and Digest Authentication, although extra security also means more complex user agent implementations. Central to Digest Authentication is a "nonce". This is a value the server generates. Acegi Security's nonce adopts the following format:. The DigestProcessingFilterEntryPoint has a property specifying the key used for generating the nonce tokens, along with a nonceValiditySeconds property for determining the expiration time default , which equals five minutes.

Whilstever the nonce is valid, the digest is computed by concatenating various strings including the username, password, nonce, URI being requested, a client-generated nonce merely a random value which the user agent generates each request , the realm name etc, then performing an MD5 hash.

Both the server and user agent perform this digest computation, resulting in different hash codes if they disagree on an included value eg password. This tells the user agent there is no need to disturb the user as the password and username etc is correct , but simply to try again using a new nonce.

Extremely secure applications should note that an intercepted authentication header can be used to impersonate the principal until the expirationTime contained in the nonce is reached. Because of the more complex implementation of Digest Authentication, there are often user agent issues.

For example, Internet Explorer fails to present an " opaque " token on subsequent requests in the same session. The Acegi Security filters therefore encapsulate all state information into the " nonce " token instead. In our testing, the Acegi Security implementation works reliably with FireFox and Internet Explorer, correctly handling nonce timeouts etc. Now that we've reviewed the theory, let's see how to use it.

The application context will need to define the DigestProcessingFilter and its required collaborators:. The configured UserDetailsService is needed because DigestProcessingFilter must have direct access to the clear text password of a user. Like BasicAuthenticationFilter , if authentication is successful an Authentication request token will be placed into the SecurityContextHolder.

If the authentication event was successful, or authentication was not attempted because the HTTP header did not contain a Digest Authentication request, the filter chain will continue as normal.

Digest Authentication's RFC offers a range of additional features to further increase security. For example, the nonce can be changed on every request. Despite this, the Acegi Security implementation was designed to minimise the complexity of the implementation and the doubtless user agent incompatibilities that would emerge , and avoid needing to store server-side state.

You are invited to review RFC if you wish to explore these features in more detail. As far as we are aware, the Acegi Security implementation does comply with the minimum standards of this RFC. Particularly in the case of web request URI security, sometimes it is more convenient to assign configuration attributes against every possible secure object invocation. There are also other situations where anonymous authentication would be desired, such as when an auditing interceptor queries the SecurityContextHolder to identify which principal was responsible for a given operation.

Such classes can be authored with more robustness if they know the SecurityContextHolder always contains an Authentication object, and never null. Acegi Security provides three classes that together provide an anoymous authentication feature. AnonymousAuthenticationToken is an implementation of Authentication , and stores the GrantedAuthority []s which apply to the anonymous principal. There is a corresponding AnonymousAuthenticationProvider , which is chained into the ProviderManager so that AnonymousAuthenticationTokens are accepted.

Finally, there is an AnonymousProcessingFilter, which is chained after the normal authentication mechanisms and automatically add an AnonymousAuthenticationToken to the SecurityContextHolder if there is no existing Authentication held there.

The definition of the filter and authentication provider appears as follows:. The key is shared between the filter and authentication provider, so that tokens created by the former are accepted by the latter. As explained earlier, the benefit of anonymous authentication is that all URI patterns can have security applied to them. For example:. This interface provides an isAnonymous Authentication method, which allows interested classes to take into account this special type of authentication status.

If an AccessDeniedException is thrown, and the authentication is of an anonymous type, instead of throwing a forbidden response, the filter will instead commence the AuthenticationEntryPoint so the principal can authenticate properly. This is a necessary distinction, otherwise principals would always be deemed "authenticated" and never be given an opportunity to login via form, basic, digest or some other normal authentication mechanism.

Remember-me authentication refers to web sites being able to remember the identity of a principal between sessions. This is typically accomplished by sending a cookie to the browser, with the cookie being detected during future sessions and causing automated login to take place.

Acegi Security provides the necessary hooks so that such operations can take place, along with providing a concrete implementation that uses hashing to preserve the security of cookie-based tokens. Remember-me authentication is not used with digest or basic authentication, given they are often not used with HttpSession s. Remember-me is used with AuthenticationProcessingFilter , and is implemented via hooks in the AbstractProcessingFilter superclass.

The hooks will invoke a concrete RememberMeServices at the appropriate times. The interface looks like this:. Please refer to JavaDocs for a fuller discussion on what the methods do, although note at this stage AbstractProcessingFilter only calls the loginFail and loginSuccess methods. This interface therefore provides the underlaying remember-me implementation with sufficient notification of authentication-related events, and delegates to the implementation whenever a candidate web request might contain a cookie and wish to be remembered.

This design allows any number of remember-me implementation strategies. In the interests of simplicity and avoiding the need for DAO implementations that specify write and create methods, Acegi Security's only concrete implementation, TokenBasedRememberMeServices , uses hashing to achieve a useful remember-me strategy. In essence a cookie is sent to the browser upon successful interactive authentication, with that cookie being composed as follows:.

As such the remember-me token is valid only for the period specified, and provided that the username, password and key does not change. Notably, this has a potential security issue issue in that a captured remember-me token will be usable from any user agent until such time as the token expires. This is the same issue as with digest authentication. If a principal is aware a token has been captured, they can easily change their password and immediately invalidate all remember-me tokens on issue.

However, if more significant security is needed a rolling token approach should be used this would require a database or remember-me services should simply not be used.

Some sort of logout command should be provided by the application typically via a JSP that invalidates the cookie upon user request. See the Contacts Sample application's logout. The beans required in an application context to enable remember-me services are as follows:. This approach did not explicitly separate the function of HttpSession storage of SecurityContextHolder contents from the processing of authentication requests received through various protocols.

In addition, the previous approach did not facilitate storage of non- Authentication objects between requests, which was limiting usefulness of the SecurityContextHolder system to member of the community. For these reasons, the notion of well-known locations was abandoned, the HttpSessionContextIntegrationFilter was established, and the purpose of authentication processing mechanisms was explicitly defined and limited to interaction with the SecurityContextHolder only.

There is no need to refer to well-known locations any more and we hope this clearer separation of responsibilities enhances understanding of the design. Very early versions of the Acegi Security System for Spring exclusively used Container Adapters for interfacing authentication with end users. Whilst this worked well, it required considerable time to support multiple container versions and the configuration itself was relatively time-consuming for developers.

Container Adapters enable the Acegi Security System for Spring to integrate directly with the containers used to host end user applications. This integration means that applications can continue to leverage the authentication and authorization capabilities built into containers such as isUserInRole and form-based or basic authentication , whilst benefiting from the enhanced security interception capabilities provided by the Acegi Security System for Spring it should be noted that Acegi Security also offers ContextHolderAwareRequestWrapper to deliver isUserInRole and similar Servlet Specification compatibility methods.

The integration between a container and the Acegi Security System for Spring is achieved through an adapter. The adapter provides a container-compatible user authentication provider, and needs to return a container-compatible user object. The adapter is instantiated by the container and is defined in a container-specific configuration file. The adapter then loads a Spring application context which defines the normal authentication manager settings, such as the authentication providers that can be used to authenticate the request.

The application context is usually named acegisecurity. Additional container adapters can easily be written. As is always the case, the container adapter generated Authentication object still needs to be authenticated by an AuthenticationManager when requested to do so by the AbstractSecurityInterceptor.

The AuthenticationManager needs to be certain the adapter-provided Authentication object is valid and was actually authenticated by a trusted adapter. Adapters create Authentication objects which are immutable and implement the AuthByAdapter interface. These objects store the hash of a key that is defined by the adapter. This authentication provider is defined as follows:. The key must match the key that is defined in the container-specific configuration file that starts the adapter.

To reiterate, this means the adapter will perform the initial authentication using providers such as DaoAuthenticationProvider , returning an AuthByAdapter instance that contains a hash code of the key.

There is no requirement for additional authentication providers such as DaoAuthenticationProvider within the application-specific application context, as the only type of Authentication instance that will be presented by the application is from the container adapter. Classloader issues are frequent with containers and the use of container adapters illustrates this further.

Each container requires a very specific configuration. The installation instructions are provided below. Once installed, please take the time to try the sample application to ensure your container adapter is properly configured. When using container adapters with the DaoAuthenticationProvider , ensure you set its forcePrincipalAsString property to true. An example realm entry:. Copy acegisecurity. Copy acegi-security-catalina-XX.

The realm name indicated in your web. A work-around is to use a script such as follows:. There are two different ways of making spring context available to the Jboss integration classes. In this configuration acegisecurity. You have to bear in mind though, that SecurityContext is created and destroyed on each login request, so the login operation might become costly. Alternatively, the second approach is to use Spring singleton capabilities through org.

The required configuration for this approach is:. In the above code fragment, authenticationManager is a helper property that defines the expected name of the AuthenticationManager in case you have several defined in the IoC container.

The singletonId property references a bean defined in a beanRefFactory. The beanRefFactory. For example, to match the above example, your jboss-web. Resin provides several ways to support the container adapter. In the instructions below we have elected to maximise consistency with other container adapter configurations. This will allow Resin users to simply deploy the sample application and confirm correct configuration.

Unlike the container-wide acegisecurity. Each web application will also contain a resin-web. Yale University produces an enterprise-wide single sign on system known as CAS. Unlike other initiatives, Yale's Central Authentication Service is open source, widely used, simple to understand, platform independent, and supports proxy capabilities.

The Acegi Security System for Spring fully supports CAS, and provides an easy migration path from single-application deployments of Acegi Security through to multiple-application deployments secured by an enterprise-wide CAS server. Whilst the CAS web site above contains two documents that detail the architecture of CAS, we present the general overview again here within the context of the Acegi Security System for Spring. The following refers to CAS 2. Somewhere in your enterprise you will need to setup a CAS server.

Inside the WAR file you will customise the login and other single sign on pages displayed to users. You will also need to specify in the web. The PasswordHandler has a simple method that returns a boolean as to whether a given username and password is valid. Your PasswordHandler implementation will need to link into some type of backend authentication repository, such as an LDAP server or database.

If you are already running an existing CAS server instance, you will have already established a PasswordHandler. This class delegates through to the standard Acegi Security AuthenticationManager , enabling you to use a security configuration you might already have in place. Apart from the CAS server itself, the other key player is of course the secure web applications deployed throughout your enterprise. These web applications are known as "services". There are two types of services: standard services and proxy services.

A proxy service is able to request resources from other services on behalf of the user. This will be explained more fully later. Services can be developed in a large variety of languages, due to CAS 2. This is handled transparently for you. The web user is browsing the service's public pages.

CAS or Acegi Security is not involved. The user eventually requests a page that is either secure or one of the beans it uses is secure. Because the user's Authentication object or lack thereof caused an AuthenticationException , the SecurityEnforcementFilter will call the configured AuthenticationEntryPoint.

After the user's browser redirects to CAS, they will be prompted for their username and password. If the user presents a session cookie which indicates they've previously logged on, they will not be prompted to login again there is an exception to this procedure, which we'll cover later.

CAS will use the PasswordHandler discussed above to decide whether the username and password is valid. Upon successful login, CAS will redirect the user's browser back to the original service. It will also include a ticket parameter, which is an opaque string representing the "service ticket". The processing filter will construct a UsernamePasswordAuthenticationToken representing the service ticket. The principal will be equal to CasProcessingFilter.

This authentication request will then be handed to the configured AuthenticationManager. CasAuthenticationProvider will validate the service ticket using a TicketValidator implementation. This implementation a ticket validation class included in the CAS client library. Back on the CAS server, the proxy validation request will be received. If any proxy was involved in the authentication discussed below , the list of proxies is also included in the XML response. This pgtIou represents a proxy-granting ticket IOU.

It will return to the CasAuthenticationProvider a TicketResponse , which includes the username mandatory , proxy list if any were involved , and proxy-granting ticket IOU if the proxy callback was requested. The CasProxyDecider indicates whether the proxy list in the TicketResponse is acceptable to the service.

These names are largely self-explanatory, except NamedCasProxyDecider which allows a List of trusted proxies to be provided. The user's browser is redirected to the original page that caused the AuthenticationException. As the Authentication object is now in the well-known location, it is handled like any other authentication approach. Usually the HttpSessionIntegrationFilter will be used to associate the Authentication object with the SecurityContextHolder for the duration of each request.

It's good that you're still here! It might sound involved, but you can relax as the Acegi Security System for Spring classes hide much of the complexity. Let's now look at how this is configured.

To install, you will need to download and extract the CAS server archive. We used version 2. Copy an applicationContext. A sample applicationContext.

Note the granted authorities are ignored by CAS because it has no way of communicating the granted authorities to calling applications. Add or edit in the case of the authHandler property the following lines:. Copy the spring. Now use the ant dist task in the build. It is assumed you already know the basics of using the Acegi Security System for Spring, so these are not covered again below.

Only the CAS-specific beans are mentioned. You will need to add a ServiceProperties bean to your application context. This represents your service:. The sendRenew defaults to false, but should be set to true if your application is particularly sensitive. What this parameter does is tell the CAS login service that a single sign on login is unacceptable.

Instead, the user will need to re-enter their username and password in order to gain access to the service. You will also need to add the CasProcessingFilter to web.

Each property is self-explanatory. This is where the user's browser will be redirected. Next you need to add an AuthenticationManager that uses CasAuthenticationProvider and its collaborators:.

Careful readers might notice one surprise: the statelessTicketCache property of the CasAuthenticationProvider. Also note the proxyCallbackUrl is set so the service can receive a proxy-granting ticket. As mentioned above, this is optional and unnecessary if you do not require proxy-granting tickets.

If you do use this feature, you will need to configure a suitable servlet to receive the proxy-granting tickets. This completes the configuration of CAS. If you haven't made any mistakes, your web application should happily work within the framework of CAS single sign on. There is also a contacts-cas. This sample application uses the above settings and can be deployed to see CAS in operation. The CasAuthenticationProvider distinguishes between stateful and stateless clients. A stateful client is considered any that originates via the CasProcessingFilter.

A stateless client is any that presents an authentication request via the UsernamePasswordAuthenticationToken with a principal equal to CasProcessingFilter.

Stateless clients are likely to be via remoting protocols such as Hessian and Burlap. The BasicProcessingFilter is still used in this case, but the remoting protocol client is expected to present a username equal to the static string above, and a password equal to a CAS service ticket. Because remoting protocols have no way of presenting themselves within the context of a HttpSession , it isn't possible to rely on the HttpSession 's HttpSessionIntegrationFilter.

Furthermore, because the CAS server invalidates a service ticket after it has been validated by the TicketValidator , presenting the same service ticket on subsequent requests will not work. It is similarly very difficult to obtain a proxy-granting ticket for a remoting protocol client, as they are often deployed on client machines which rarely have HTTPS URLs that would be accessible to the CAS server.

One obvious option is to not use CAS at all for remoting protocol clients. However, this would eliminate many of the desirable features of CAS. This is used solely for requests with a principal equal to CasProcessingFilter. Accordingly, remoting protocol clients can present the same service ticket and the CasAuthenticationProvider will not need to contact the CAS server for validation aside from the first request.

The other aspect of advanced CAS usage involves creating proxy tickets from the proxy-granting ticket. The ProxyTicketReceptor provides a static method that enables you to obtain a proxy ticket by presenting the proxy-granting IOU ticket. Welcome to enterprise-wide single sign on! The browser will automatically check that the certificate presented by a server has been issued ie digitally signed by one of a list of trusted certificate authorities which it maintains.

The server will authenticate the client by checking that it's certificate is signed by an acceptable authority. If a valid certificate has been provided, it can be obtained through the servlet API in an application. The Acegi Security X module extracts the certificate using a filter and passes it to the configured X authentication provider to allow any additional application-specific checks to be applied.

It also maps the certificate to an application user and loads that user's set of granted authorities for use with the standard Acegi Security infrastructure. You should be familiar with using certificates and setting up client authentication for your servlet container before attempting to use it with Acegi Security. Most of the work is in creating and installing suitable certificates and keys.

It's important that you get this working before trying it out with Acegi Security. With X authentication, there is no explicit login procedure so the implementation is relatively simple; there is no need to redirect requests in order to interact with the user.

As a result, some of the classes behave slightly differently from their equivalents in other packages. With a suitable bean configuration, the normal sequence of events is as follows The XProcessingFilter extracts the certificate from the request and uses it as the credentials for an authentication request.

The generated authentication request is an XAuthenticationToken. The request is passed to the authentication manager. The XAuthenticationProvider receives the token. Its main concern is to obtain the user information in particular the user's granted authorities that matches the certificate. It delegates this responsibility to an XAuthoritiesPopulator.

Implementations should return a UserDetails instance containing the array of GrantedAuthority objects for the user. This method can also choose to reject the certificate for example if it doesn't contain a matching user name. In such cases it should throw a BadCredentialsException. It also allows you to set your own regular expression to match a different part of the subject's distinguished name.

A UserDetailsService is used to load the user information. If everything has gone smoothly then there should be a valid Authentication object in the secure context and the invocation will procede as normal. If no certificate was found, or the certificate was rejected, then the SecurityEnforcementFilter will invoke the XProcessingFilterEntryPoint which returns a error forbidden to the user.

There is a version of the Contacts Sample Application which uses X Copy the beans and filter setup from this as a starting point for configuring your own application.

A set of example certificates is also included which you can use to configure your server. These are marissa. These should be installed in your browser. This will be used by the container to validate client certificates. In addition to coordinating the authentication and authorization requirements of your application, the Acegi Security System for Spring is also able to ensure unauthenticated web requests have certain properties.

These properties may include being of a particular transport type, having a particular HttpSession attribute set and so on. The most common requirement is for your web requests to be received using a particular transport protocol, such as HTTPS. An important issue in considering transport security is that of session hijacking. Your web container manages a HttpSession by reference to a jsessionid that is sent to user agents either via a cookie or URL rewriting.

If the jsessionid is ever sent over HTTP, there is a possibility that session identifier can be intercepted and used to impersonate the user after they complete the authentication process. If session hijacking is considered too significant a risk for your particular application, the only option is to use HTTPS for every request.

This means the jsessionid is never sent across an insecure channel. You will need to ensure your web. The Acegi Security System for Spring provides a solution to assist with the latter. To utilise Acegi Security's channel security services, add the following lines to web. As usual when running FilterToBeanProxy , you will also need to configure the filter in your application context:.

The ChannelProcessingFilter operates by filtering all web requests and determining the configuration attributes that apply. It then delegates to the ChannelDecisionManager. The default implementation, ChannelDecisionManagerImpl , should suffice in most cases. It simply delegates through the list of configured ChannelProcessor instances. A ChannelProcessor will review the request, and if it is unhappy with the request eg it was received across the incorrect transport protocol , it will perform a redirect, throw an exception or take whatever other action is appropriate.

Both implementations delegate to a ChannelEntryPoint if the required transport protocol is not used. Appropriate defaults are assigned to the ChannelProcessor implementations for the configuration attribute keywords they respond to and the ChannelEntryPoint they delegate to, although you have the ability to override these using the application context. During testing it was discovered that Internet Explorer 6 Service Pack 1 has a bug whereby it does not respond correctly to a redirection instruction which also changes the port to use.

Accordingly, absolute URLs are used in conjunction with bug detection logic in the PortResolverImpl that is wired up by default to many Acegi Security beans. Once configured, using the channel security filter is very easy.

Obviously you'll still need a way of making the initial request probably via the web. For example, you might set a HttpSession attribute when a human user is detected via a "enter the contents of this graphic" procedure.

To decide whether a security check belongs in a ChannelProcessor or an AccessDecisionVoter , remember that the former is designed to handle unauthenticated requests, whilst the latter is designed to handle authenticated requests. The latter therefore has access to the granted authorities of the authenticated principal. 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 Authentication , where MethodInvocation and what SomeDomainObject. In other words, authorization decisions also need to consider the actual domain object instance subject of a method invocation.

Imagine you're designing an application for a pet clinic. There will be two main groups of users of your Spring-based application: staff of the pet clinic, as well as the pet clinic's customers. The staff will have access to all of the data, whilst your customers will only be able to see their own customer records. To make it a little more interesting, your customers can allow other users to see their customer records, such as their "puppy preschool "mentor or president of their local "Pony Club".

Using Acegi Security System for Spring as the foundation, you have several approaches that can be used: Write your business methods to enforce the security. You could consult a collection within the Customer domain object instance to determine which users have access. By using the SecurityContextHolder. Write an AccessDecisionVoter to enforce the security from the GrantedAuthority[] s stored in the Authentication object.

This would mean your AuthenticationManager would need to populate the Authentication with custom GrantedAuthority []s representing each of the Customer domain object instances the principal has access to. Write an AccessDecisionVoter to enforce the security and open the target Customer domain object directly.

This would mean your voter needs access to a DAO that allows it to retrieve the Customer object. It would then access the Customer object's collection of approved users and make the appropriate decision. Each one of these approaches is perfectly legitimate.

However, the first couples your authorization checking to your business code. The main problems with this include the enhanced difficulty of unit testing and the fact it would be more difficult to reuse the Customer authorization logic elsewhere. Obtaining the GrantedAuthority[] s from the Authentication object is also fine, but will not scale to large numbers of Customer s. If a user might be able to access 5, Customer s unlikely in this case, but imagine if it were a popular vet for a large Pony Club!

The final method, opening the Customer directly from external code, is probably the best of the three. It achieves separation of concerns, and doesn't misuse memory or CPU cycles, but it is still inefficient in that both the AccessDecisionVoter and the eventual business method itself will perform a call to the DAO responsible for retrieving the Customer object.

Two accesses per method invocation is clearly undesirable. In addition, with every approach listed you'll need to write your own access control list ACL persistence and business logic from scratch.

It provides the basic foundation for access control list ACL lookups. Figure 6: Access Control List Manager. The central interface is AclManager , which is defined by two methods:.

Object domainInstance ; public AclEntry[] getAcls java. Object domainInstance, Authentication authentication ;. AclManager is intended to be used as a collaborator against your business objects, or, more desirably, AccessDecisionVoter s. Consideration was given to placing the ACL information in the ContextHolder , but it was felt this would be inefficient both in terms of memory usage as well as the time spent loading potentially unused ACL information.

The trade-off of needing to wire up a collaborator for those objects requiring ACL information is rather minor, particularly in a Spring-managed application. The first method of the AclManager will return all ACLs applying to the domain object instance passed to it. The second method does the same, but only returns those ACLs which apply to the passed Authentication object.

The AclEntry interface returned by AclManager is merely a marker interface. You will need to provide an implementation that reflects that ACL permissions for your application. Rounding out the org. The first AclProvider that indicates it can authoritatively provide ACL information for the presented domain object instance will be used. This is very similar to the AuthenticationProvider interface used for authentication. 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 You'll find the classes and interfaces for the integer masking ACL package under org. Object getRecipient ;. As shown, each BasicAclEntry has four main properties. The mask is the integer that represents the permissions granted to the recipient. The aclObjectIdentity is able to identify the domain object instance for which the ACL applies, and the aclObjectParentIdentity optionally specifies the parent of the domain object instance.

Multiple BasicAclEntry s usually exist against a single domain object instance, and as suggested by the parent identity property, permissions granted higher in the object hierarchy will trickle down and be inherited unless blocked by integer zero. BasicAclEntry implementations typically provide convenience methods, such as isReadAllowed , to avoid application classes needing to perform bit masking themselves.

The AclObjectIdentity itself is merely a marker interface, so you need to provide implementations for your domain objects. However, the package does include a NamedEntityObjectIdentity implementation which will suit many needs. The NamedEntityObjectIdentity identifies a given domain object instance by the classname of the instance and the identity of the instance. A NamedEntityObjectIdentity can be constructed manually by calling the constructor and providing the classname and identity String s , or by passing in any domain object that contains a getId method.

It has adopted a similar design to that used by the authentication-related DaoAuthenticationProvder. AclProvider org. AclProviderManager org. AbstractBasicAclEntry org. AclObjectIdentity org. AclObjectIdentityAware org. BasicAclDao org. BasicAclEntry org. BasicAclEntryCache org. BasicAclExtendedDao org. BasicAclProvider org. EffectiveAclsResolver org.

GrantedAuthorityEffectiveAclsResolver org. NamedEntityObjectIdentity org. SimpleAclEntry org. BasicAclEntryHolder org. NullAclEntryCache org. JdbcDaoImpl org. JdbcExtendedDaoImpl org. AccessControlEntry org. Acl org. AclFormattingUtils org. AclService org. AlreadyExistsException org. AuditableAccessControlEntry org. AuditableAcl org. ChildrenExistException org.

IdentityUnavailableException org. MutableAcl org. MutableAclService org. NotFoundException org. OwnershipAcl org. Permission org. UnloadedSidException org. AccessControlEntryImpl org. AclAuthorizationStrategy org. AclAuthorizationStrategyImpl org.

AclImpl org. AuditLogger org. BasePermission org. ConsoleAuditLogger org. CumulativePermission org. AclCache org. BasicLookupStrategy org. EhCacheBasedAclCache org. JdbcAclService org. JdbcMutableAclService org. LookupStrategy org. ObjectIdentity org. ObjectIdentityImpl org. ObjectIdentityRetrievalStrategy org. ObjectIdentityRetrievalStrategyImpl org. GrantedAuthoritySid org. PrincipalSid org. Sid org. SidRetrievalStrategy org. SidRetrievalStrategyImpl org. AbstractAdapterAuthenticationToken org.

AuthByAdapter org. AuthByAdapterProvider org. HttpRequestIntegrationFilter org. PrincipalAcegiUserToken org. AbstractAclProvider org. AclEntryAfterInvocationProvider org.

AfterInvocationProvider org. AfterInvocationProviderManager org. ArrayFilterer org. CollectionFilterer org. Filterer org. ConcurrentLoginException org. ConcurrentSessionController org.

ConcurrentSessionControllerImpl org. ConcurrentSessionFilter org. NullConcurrentSessionController org. SessionAlreadyUsedException org. SessionIdentifierAware org. SessionInformation org. SessionRegistry org. SessionRegistryImpl org.

SessionRegistryUtils org. GlobalSecurityContextHolderStrategy org. HttpSessionContextIntegrationFilter org. SecurityContext org. SecurityContextHolder org. SecurityContextHolderStrategy org. SecurityContextImpl org. ContextPropagatingRemoteInvocation org. ContextPropagatingRemoteInvocationFactory org. AbstractAuthenticationEvent org.

AbstractAuthenticationFailureEvent org. AuthenticationFailureBadCredentialsEvent org. AuthenticationFailureConcurrentLoginEvent org. AuthenticationFailureCredentialsExpiredEvent org. AuthenticationFailureDisabledEvent org. AuthenticationFailureExpiredEvent org. AuthenticationFailureLockedEvent org. AuthenticationFailureProxyUntrustedEvent org. AuthenticationFailureServiceExceptionEvent org. AuthenticationSuccessEvent org. AuthenticationSwitchUserEvent org.

InteractiveAuthenticationSuccessEvent org. LoggerListener org. AbstractAuthorizationEvent org. AuthenticationCredentialsNotFoundEvent org. AuthorizationFailureEvent org. AuthorizedEvent org. PublicInvocationEvent org. AbstractSecurityInterceptor org. InterceptorStatusToken org. ObjectDefinitionSource org. AbstractMethodDefinitionSource org.

MethodDefinitionAttributes org. MethodDefinitionMap org. MethodDefinitionSource org. MethodDefinitionSourceEditor org. MethodDefinitionSourceMapping org.