Acegi-security-1.0.6.jar download

Carlos Sanchez's Weblog Join 3, other followers. Sign me up. Already have a WordPress. Log in now. Post was not sent - check your email addresses!

Sorry, your blog cannot share posts by email. 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. Specifically, you define a BasicAclDao against the provider, so different ACL repository types can be accessed in a pluggable manner. A BasicAclDao implementation needs to understand the presented AclObjectIdentity and how it maps to a storage repository, find the relevant records, and create appropriate BasicAclEntry objects and return them. The default database schema and some sample data will aid in understanding its function:.

DomainObject:1', null, 'org. DomainObject:2', 1, 'org. DomainObject:3', 1, 'org. DomainObject:4', 1, 'org. DomainObject:5', 3, 'org. DomainObject:6', 3, 'org. As can be seen, database-specific constraints are used extensively to ensure the integrity of the ACL information. If you need to use a different database Hypersonic SQL statements are shown above , you should try to implement equivalent constraints. As indicated by the sample data, each database row corresponds to a single BasicAclEntry.

As stated earlier and demonstrated by corp. DomainObject:2 in the above sample data, each domain object instance will often have multiple BasicAclEntry []s. Returning to the BasicAclProvider , before it can poll the BasicAclDao implementation it needs to convert the domain object instance it was passed into an AclObjectIdentity. As a protected method, it enables subclasses to easily override. The normal implementation checks whether the passed domain object instance implements the AclObjectIdentityAware interface, which is merely a getter for an AclObjectIdentity.

If the domain object does implement this interface, that is the identity returned. If the domain object does not implement this interface, the method will attempt to create an AclObjectIdentity by passing the domain object instance to the constructor of a class defined by the BasicAclProvider.

By default the defined class is NamedEntityObjectIdentity , which was described in more detail above. Therefore, you will need to either i provide a getId method on your domain objects, ii implement AclObjectIdentityAware on your domain objects, iii provide an alternative AclObjectIdentity implementation that will accept your domain object in its constructor, or iv override the obtainIdentity Object method.

If any of the entries returned by the DAO indicate there is a parent, that parent will be polled, and the process will repeat until there is no further parent. The permissions assigned to a recipient closest to the domain object instance will always take priority and override any inherited permissions. From the sample data above, the following inherited permissions would apply:. So the above explains how a domain object instance has its AclObjectIdentity discovered, and the BasicAclDao will be polled successively until an array of inherited permissions is constructed for the domain object instance.

The final step is to determine the BasicAclEntry []s that are actually applicable to a given Authentication object. As you would recall, the AclManager and all delegates, up to and including BasicAclProvider provides a method which returns only those BasicAclEntry []s applying to a passed Authentication object.

BasicAclProvider delivers this functionality by delegating the filtering operation to an EffectiveAclsResolver implementation. The default implementation, GrantedAuthorityEffectiveAclsResolver , will iterate through the BasicAclEntry []s and include only those where the recipient is equal to either the Authentication 's principal or any of the Authentication 's GrantedAuthority []s.

Please refer to the JavaDocs for more information. The interfaces and classes detailed above provide a scalable, customisable ACL solution that is decoupled from your application code. Whilst the reference documentation may suggest complexity, the basic implementation is able to support most typical applications out-of-the-box.

The Acegi Security System for Spring uses filters extensively. Each filter is covered in detail in a respective section of this document. This section includes information that applies to all filters. Most filters are configured using the FilterToBeanProxy. An example configuration from web. Notice that the filter in web. What FilterToBeanProxy does is delegate the Filter 's methods through to a bean which is obtained from the Spring application context.

This enables the bean to benefit from the Spring application context lifecycle support and configuration flexibility. The bean must implement javax. The targetClass parameter locates the first object in the application context of the specified class, whilst targetBean locates the object by bean name.

There is a lifecycle issue to consider when hosting Filter s in an IoC container instead of a servlet container. Specifically, which container should be responsible for calling the Filter 's "startup" and "shutdown" methods? It is noted that the order of initialization and destruction of a Filter can vary by servlet container, and this can cause problems if one Filter depends on configuration settings established by an earlier initialized Filter.

For this reason we recommend the use of Spring lifecycle services instead of servlet container lifecycle services wherever possible. If you do require such invocations to be delegated, set the lifecycle initialization parameter to servlet-container-managed. We strongly recommend to use FilterChainProxy instead of adding multiple filters to web.

It is wired using a FilterToBeanProxy just like in the example above , but the target class is org. The filter chain is then declared in the application context, using code such as this:. You may notice similarities with the way SecurityEnforcementFilter is declared. Each of the corresponding configuration attributes represent the name of a bean defined in the application context. The filters will then be invoked in the order they are specified, with standard FilterChain behaviour being respected a Filter can elect not to proceed with the chain if it wishes to end processing.

As you can see, FitlerChainProxy requires the duplication of filter names for different request patterns in the above example, httpSessionContextIntegrationFilter and securityEnforcementFilter are duplicated. This design decision was made to enable FilterChainProxy to specify different Filter invocation orders for different URI patterns, and also to improve both the expressiveness in terms of regular expressions, Ant Paths, and any custom FilterInvocationDefinitionSource implementations and clarity of which Filter s should be invoked.

As web services will never present a jsessionid on future requests, creating HttpSession s for such user agents would be wasteful. If you had a high-volume application which required maximum scalability, we recommend you use the approach shown above.

For smaller applications, using a single HttpSessionContextIntegrationFilter with its default allowSessionCreation as true would likely be sufficient.

In relation to lifecycle issues, the FilterChainProxy will always delegate init FilterConfig and destroy methods through to the underlaying Filter s if such methods are called against FilterChainProxy itself.

In this case, FilterChainProxy guarantees to only initialize and destroy each Filter once, irrespective of how many times it is declared by the FilterInvocationDefinitionSource. You control the overall choice as to whether these methods are called or not via the lifecycle initialization parameter of the FilterToBeanProxy that proxies FilterChainProxy.

As discussed above, by default any servlet container lifecycle invocations are not delegated through to FilterChainProxy. The order that filters are defined in web.

ChannelProcessingFilter , because it might need to redirect to a different protocol. ConcurrentSessionFilter , because it doesn't use any SecurityContextHolder functionality but needs to update the SessionRegistry to reflect ongoing requests from the principal. HttpSessionContextIntegrationFilter , so a Context can be setup in the SecurityContextHolder at the beginning of a web request, and any changes to the Context can be copied to the HttpSession when the web request ends ready for use with the next web request.

RememberMeProcessingFilter , so that if no earlier authentication processing mechanism updated the SecurityContextHolder , and the request presents a cookie that enables remember-me services to take place, a suitable remembered Authentication object will be put there.

AnonymousProcessingFilter , so that if no earlier authentication processing mechanism updated the SecurityContextHolder , an anonymous Authentication object will be put there. Included with the Acegi Security System for Spring is a very simple application that can demonstrate the basic security facilities provided by the system and confirm your Container Adapter is properly configured if you're using one. If you build from CVS, the Contacts sample application includes three deployable versions: acegi-security-sample-contacts-filter.

The acegi-security-sample-contacts-ca. Finally, acegi-security-sample-contacts-cas. If you're just wanting to see how the sample application works, please use acegi-security-sample-contacts-filter. This is also the artifact included in ofiical release ZIPs. After starting your container, check the application can load. A random contact should be displayed.

Click "Refresh" several times and you will see different contacts. The business method that provides this random contact is not secured.

Next, click "Debug". You will be prompted to authenticate, and a series of usernames and passwords are suggested on that page. Simply authenticate with any of these and view the resulting page.

It should contain a success message similar to the following:. Context on SecurityContextHolder is of type: org. Authentication object as a String: org. If you receive a different message, and deployed acegi-security-sample-contacts-ca.

Once you successfully receive the above message, return to the sample application's home page and click "Manage". You can then try out the application. Behind the scenes, the MethodSecurityInterceptor is securing the business objects. If you're using acegi-security-sample-contacts-filter. Note the sample application enables you to modify the access control lists associated with different contacts. Be sure to give this a try and understand how it works by reviewing the sample application's application context XML files.

The Contacts sample application also include a client directory. Inside you will find a small application that queries the backend business objects using several web services protocols. You can use j2ee. I was also able to get all unit tests to pass on Tomcat 5, and the "setup-tomcat" target now supports Tomcat 5.

I wasn't able to get "Remember Me" to work - see the tomcat-user mailing list for more details. Included in this release are upgrades to Hibernate 2. November 30, I feel this release deserves the big 1. Of course, as I learn more, I will continue to push out new releases. In this release, I did a lot of refactoring and enhancements to existing features.

Hibernate's Session object is now passed as an argument into Manager and DAO constructors, rather than method signatures. The reason I have a LoginServlet vs. I've developed 3 different applications using AppFuse struts-resume is one of them , and I have found that it's a pain to upgrade to new versions of AppFuse. Because of this, I don't recommend upgrading unless you really need to.

I will be upgrading struts-resume to AppFuse 1. September 14, The highlights of this release include rendering a resume with Velocity demo , a password hint feature, self-registration feature, and a gzip compression filter. See the release notes below for a full list of changes. If you're looking to create a new application based on this architecture, you're best off using AppFuse.

You can also check out the Struts Resume Wiki Page for more information. This release contains all kinds of goodies - including a new password hint feature, a compression filter, and a JSP 2.

You can also check out the AppFuse Wiki Page for more information. News This release is a simplification of 1. Also, I synched up the build. The main reason for this release is to demonstrate self-registration and auto-login in a CMA Container Managed Authentication environment. I also upgraded most of the dependent packages i. Struts, Hibernate to their latest releases, and added a binary release as an optional download.

You can also browse the API Documentation. You should be able to view Source Code here too! If there's not a "View Source" link on a class's javadoc page, you can get to it by using Classname.

An important note, I'm using Crowd 1. This is what my login-config. This is the correct "crowd. Any advice very, very welcome! This early exit was caused by a missing commons-lang jar in the JBoss lib folder. Now it works like a charm! Crowd Extension. Pages Blog. Child pages. Browse pages. A t tachments 8 Page History. Dashboard Home. Jira links. Module Option Description Default crowd. Module Option Description Default storePass if true, save shared state if login succeeds tryFirstPass and useFirstPass do not enable this automatically.

Authenticate via Jaas. CrowdLoginModule required application. Sample Client Code to invoke a LoginContext. Version Release Date Description 0. River Tarnell. Permalink Jan 24, Brad Harvey. Permalink Jan 25, Abigail Edwards. Permalink Jan 26, Daniel Schulz. Please contribute the sources for 1. Permalink Apr 03, Permalink Apr 05, Bas Biesheuvel. I hope it makes sense, can somebody help?

Let me put things right. It was partly my own fault, but it was eventually still the module that didnt work properly. Permalink Apr 23, Hi Bas, Glad you got it working. Cheers, Brad. Permalink Apr 25, Let me know how it goes. Hey Brad, Thanks for looking into this. I didnt have time until today to check it out, sorry for that.

This is the log that I get: I removed some names for the sake of security, replaced with Let me know, Bas. Permalink May 04, Hi Bas, Can you set those properties in the login module options instead of crowd. Thanks, Brad.