Acegi Security for Spring Framework

Acegi Security provides comprehensive security services for J2EE-based enterprise software applications. There is a particular emphasis on supporting projects built using The Spring Framework, which is the leading J2EE solution for enterprise software development. If you're not using Spring for developing enterprise applications, we warmly encourage you to take a closer look at it. Some familiarity with Spring - and in particular dependency injection principles - will help you get up to speed with Acegi Security more easily.

People use Acegi Security for many reasons, but most are drawn to the project after finding the security features of J2EE's Servlet Specification or EJB Specification lack the depth required for typical enterprise application scenarios. Whilst mentioning these standards, it's important to recognise that they are not portable at a WAR or EAR level. Therefore, if you switch server environments, it is typically a lot of work to reconfigure your application's security in the new target environment. Using Acegi Security overcomes these problems, and also brings you dozens of other useful, entirely customisable security features.

As you probably know, security comprises two major operations. The first is known as "authentication", which is the process of establishing a principal is who they claim to be. A "principal" generally means a user, device or some other system which can perform an action in your application. "Authorization" refers to the process of deciding whether a principal is allowed to perform an action in your application. To arrive at the point where an authorization decision is needed, the identity of the principal has already been established by the authentication process. These concepts are common, and not at all specific to Acegi Security.

At an authentication level, Acegi Security supports a wide range of authentication models. Most of these authentication models are either provided by third parties, or are developed by relevant standards bodies such as the Internet Engineering Task Force. In addition, Acegi Security provides its own set of authentication features. Specifically, Acegi Security currently supports authentication with all of these technologies:

• HTTP BASIC authentication headers (an IEFT RFC-based standard)

• HTTP Digest authentication headers (an IEFT RFC-based standard)

• HTTP X.509 client certificate exchange (an IEFT RFC-based standard)

• LDAP (a very common approach to cross-platform authentication needs, especially in large environments)

• Form-based authentication (for simple user interface needs)

• Computer Associates Siteminder

• JA-SIG Central Authentication Service (otherwise known as CAS, which is a popular open source single sign on system)

• Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol)

• Automatic "remember-me" authentication (so you can tick a box to avoid re-authentication for a predetermined period of time)

• Anonymous authentication (allowing every call to automatically assume a particular security identity)

• Run-as authentication (which is useful if one call should proceed with a different security identity)

• Java Authentication and Authorization Service (JAAS)

• Container integration with JBoss, Jetty, Resin and Tomcat (so you can still use Container Manager Authentication if desired)

• Your own authentication systems (see below)

Many independent software vendors (ISVs) adopt Acegi Security because of this rich choice of authentication models. Doing so allows them to quickly integrate their solutions with whatever their end clients need, without undertaking a lot of engineering or requiring the client to change their environment. If none of the above authentication mechanisms suit your needs, Acegi Security is an open platform and it is quite simple to write your own authentication mechanism. Many corporate users of Acegi Security need to integrate with "legacy" systems that don't follow any particular security standards, and Acegi Security is happy to "play nicely" with such systems.

Sometimes the mere process of authentication isn't enough. Sometimes you need to also differentiate security based on the way a principal is interacting with your application. For example, you might want to ensure requests only arrive over HTTPS, in order to protect passwords from eavesdropping or end users from man-in-the-middle attacks. Or, you might want to ensure that an actual human being is making the requests and not some robot or other automated process. This is especially helpful to protect password recovery processes from brute force attacks, or simply to make it harder for people to duplicate your application's key content. To help you achieve these goals, Acegi Security fully supports automatic "channel security", together with JCaptcha integration for human user detection.

Irrespective of how authentication was undertaken, Acegi Security provides a deep set of authorization capabilities. There are three main areas of interest in respect of authorization, these being authorizing web requests, authorizing methods can be invoked, and authorizing access to individual domain object instances. To help you understand the differences, consider the authorization capabilities found in the Servlet Specification web pattern security, EJB Container Managed Security and file system security respectively. Acegi Security provides deep capabilities in all of these important areas, which we'll explore later in this reference guide.

Source: Official Reference Guide

EJB Programming Restrictions

1. Using static, nonfinal fields. Declaring all static fields in the EJB component as final is recommended. That ensures consistent runtime semantics so that EJB containers have the flexibility to distribute instances across multiple JVMs.
2. Using thread synchronization primitives to synchronize multiple instance execution. By avoiding that feature, you allow the EJB container flexibility to distribute instances across multiple JVMs.
3. Using AWT functionality for keyboard input/display output. That restriction exists because server-side business components are meant to provide business functionality that excludes user interface and keyboard I/O functionality.
4. Using file access/java.io operations. EJB business components are meant to use resource managers such as JDBC to store and retrieve application data rather than the file system APIs. Also, deployment tools provide the facility for storing environment entry elements (env-entry) into the deployment descriptor, so that EJB components can perform environment entry lookups in a standardized manner via the environment-naming context. Thus, the need to use file system-based property files is mostly eliminated.
5. Listening to or accepting socket connections, or using a socket for multicast. EJB components are not meant to provide network socket server functionality; however, the architecture lets EJB components act as a socket client or RMI clients and thus communicate with code outside the container's managed environment.
6. Using the Reflection API to query classes that are not otherwise accessible to the EJB component due to Java's security rules. That restriction enforces Java platform security.
7. Attempting to create or obtain a class loader, set or create a new security manager, stop the JVM, change the input, output, and error streams. That restriction enforces security and maintains the EJB container's ability to manage the runtime environment.
8. Setting the socket factory used by the URL's ServerSocket, Socket, or stream handler. By avoiding that feature, you also enforce security and maintain the EJB container's ability to manage the runtime environment.
9. Starting, stopping, or managing threads in any way. That restriction eliminates the possibility of conflicts with the EJB container's responsibilities of managing locking, threading, and concurrency issues.
10. By restricting your use of features 10-16, you aim to plug potential security holes:
11. Reading or writing a file descriptor directly.
12. Obtaining security policy information for a particular code source.
13. Loading native libraries.
14. Accessing packages and classes that the usual rules of Java make unavailable.
15. Defining a class in a package.
16. Accessing or modifying security configuration objects (Policy, Security, Provider, Signer, and Identity).
17. Using the subclass and object substitution features of the Java Serialization protocol.
18. Passing the this reference as an argument or returning the this reference as a result. Instead, you must use the result of the getEJBObject() available in SessionContext or EntityContext.

CMP-EJB vs. Hibernate

The J2EE field is agog with excitement about a very popular Open Source technology - Hibernate. This technology being elevated to the status of JCP standard. Feedback from J2EE programmers in industry says that knowledge of Hibernate is mandatory for all J2EE aspirants.

Hibernate is an ORM Object-Relational-Mapping technology. It is an Open-Source and free technology, developed in SourceForge. net. There have been a number of such ORM technologies,in recent past. . TopLink is one such tool, subsequently adopted by Oracle and so proprietary. Hibernate from SourceForge and OJB(Object-Relational-Bridge) from Apache are two well known ORM tools, open-source and free. JDO, also falls within the same category.

Gavin King is the lead for Hibernate and Craig Russell & David Jordan, the lead authors for SUN-sponsored JDO effort. Due to some technical problems, it appears that the majority in JCP favours Hibernate today instead of JDO. At first reading though, the difference is not, all that apparent. The syntax and the approach appear to be almost same, but Hibernate syntax is easier to learn.  

It is interesting to note that Craig Russell works for SUN and Gavin King is now with JBoss. It shows that JCP is a democratic community and SUN is not dictating terms except to protect the language and its enterprise-level users.

EJB-3, is the latest version and it is heavily influenced by Hibernate. Some readers equate EJB-3 with Hibernate. Oracle supports EJB-3 proposals and as it is the main Database company in j2ee world, EJB-3 has bright future. J2EE by its very name is an Enterprise level technology, and as EJB is the essence of such Enterprise applications, because of the built-in container services offered, the significance of the surging interest in Hibernate can be really appreciated only in association with EJB and hence a detour into EJB is inevitable.

EJB has three types. One type is the SESSION BEAN, residing in ENTERPRISE container, which can be thought of as a function-bean, invoked in RMI-IIOP style. Such session-bean, may be either stateless or stateful. The stateless bean working in Enterprise container has an exact counter-part in Microsoft COM+(MTS), but the other types are said to be available in MS platform only through third-party extensions.

ORM tools have been sometimes used along with Session beans. The only problem till recently was that they were proprietory and rather costly. But nowadays, very reliable open-source ORM tools are available, and even Richard Monson Haefel approves this method as a safe and productive alternative to Entity beans.

The other branch, the ENTITY BEAN has been less lucky. EJB-1. 1, EJB-2. 0 and then EJB-2. 1, have meant a number of changes in the specification relating to Entity Beans.
We can say that an Entity bean is an 'Attribute bean' or 'property-bean', with setter and getter methods, invoked in RMI-IIOP style and persisted in Enterprise container. The pattern of defining a typical Javabean is a recurring theme in Java. The same style occurs in BDK, EJB-Entity beans, Struts, JSF and now in Hibernate too. So, it is very important and elegant.

The third branch is Messaging paradigm and MDB. An Enterprise by its very name implies huge number of customers and concurrent transactions, RPC style being like telephone call, could result in 'line-engaged!' problem. If the call involves the called person referring to some records before replying, it leads to line- blocking. But, messaging style, as in email, atleast ensures that the message has been sent. It is evident that dubbing RPC( read 'telephone') as unsuitable, is over-statement. Sometimes, we desire immediate response,too. By the same token, even XML webservice, if it is really serious, should adopt messaging style and it does. MDB (Message-Driven bean) has weathered the storm and is in fact gaining more and more acceptance.

So, why is it that Entity beans alone were found wanting and the specification keeps on changing?
Entity beans are of two types. CMP & BMP.
CMP stands for Container-Managed Persistence and BMP stands for Bean-managed persistence. Theoretically, the EJB specification does not say anything about the method to be adopted in persisting objects for permanent storage and retrieval. It could be simple object serialization. The database may be object-database or Object-relational database or XML. In practice, however, a database has always meant a Relational Database and its SQL.

In CMP, the coder deals with objects, only in memory. He creates new objects, modifies them, deletes them and views them, all in memory. The task of saving these objects in memory ,to the relational database table is done by the container, automatically. The coder does not write any sql-related code for this.

In BMP, the coder has to write the sql to persist the object in memory to the relational database.

CMP in EJB1. 1 was suitable for simple tables, without complex relationships to other tables. CMP avoids all references to the underlying database. So, it is more portable. There is no vendor-lock-in. CMP can persist data to Object- databases also, besides Relational databases.

But, CMP is not always suitable. If the database is some legacy type, which cannot be used with SQL, the database company gives a proprietory code for persistence and such code has to be used in our program to persist data. The facilities given in CMP originally were found to be too elementary and there were complaints.

But, what matters is that CMP makes use of ORM concepts, though the implementation left much to be desired. It did not expose how the EJB vendor implements it. Weblogic, Oracle, IBM WebSphere, SUN , JBoss, each may implement CMP in any way that they deem fit. Except in special circumstances, it will be better to use CMP, not merely because, it makes the code more portable & is easy to write. Much more important reason is that the EJB container can optimize the performace dramatically, if we adopt CMP. So the developer community wanted to adopt CMP but found it unsuitable for really complex jobs.

Even with all these improvements, CMP was found to be less than the ultimate solution. There was no spossibility for Inheritance.  

Though the container services provided by the EJB container are indispensable in a truly large enterprise application, the J2EE camp is almost vertically split into WebTier & EJB-Tier votaries. The WebTier supporters claim that EJB with its steep learning curve and error prone development environment for developers is not really necessary for most applications. And they would like to have an ORM tool, built into the J2EE specification. For afterall, ORM task is not specific to EJB alone. Even Servlets and JSP could use them. In fact, they have been using them, though the J2EE specification was silent about it. ORM tools like OJB, JDO and Hibernate can be used not only in EJB containers but in webcontainer and even in standalone containers. Gavin King makes it a special point in favour of Hibernate. Making such a tool, a J2EE standard, would make development tasks far easier ,to develop either web-tier application or ejb-tier application. saving us from the medley of classpath to required jars.

In a scathing attack on the complexity and questionable performance of EJB Entity beans, Rod Johnson, prophesies, that in a few years time, J2EE will cease to include EJB. Whether, we agree or not, it is worth looking into the criticisms against EJB Entity beans, raised by him. ( 'J2EE Development without EJB' - Wrox/Wiley/DreamTech-2004). For, he is proposing the Spring Framework as an alternative to EJB container and the idea is gaining ground. J2EE developers and students may have to re-orient themselves rather abruptly, to remain relevant to industry.

Source: in.geocities.com/rsramsam