Security and EJBs
EJB security is determined either by declarative entries added to the deployment descriptor, programmatic constraints coded into the EJBs, or a combination of both.
Ideally, EJB security should only use the declarative approach, but where declarative security cannot represent the application's requirements, security must be encoded in the EJB class. Programmatic security is less portable and may restrict the way an application assembler can combine beans from different sources.
Defining EJB Security
Defining security for an EJB involves
Defining one or more roles to control access to different areas of your application
Authorizing access to EJBs and EJB methods according to the client roles
Mapping roles onto principals in the target server's authentication domain
Optionally adding programmatic authorization to Session and Entity beans
If you are using the J2EE RI, the security can be defined using deploytool. Other J2EE environments may provide GUI tools similar to deploytool or, if you are unlucky, you may have to manually edit the deployment descriptor to include the security requirements.
In the rest of this section, you will use deploytool to add security to the Agency case study. You will see how extra information is added to the deployment descriptor to define the security requirements.
Defining Roles
There are three distinct roles within the simple Agency application:
Administrators that can modify the skills and location tables
Customers that can advertise jobs
Applicants that can advertise their locations and skills
You may even decide that there are only two roles--administrators and clients (for want of a better term). Clients can register their own skills or advertise jobs for other clients. While this is a perfectly acceptable model, it loses the differentiation between applicants and customers.
Currently, there are no constraints on who can be an applicant and who can be a customer. However, in a real world job agency, it may become necessary to restrict who can be applicants and customers. Perhaps customers will be charged for applicants who match their jobs, so they need to be validated before they can use your system.
Having decided on your roles, you must add them to the deployment descriptor. Roles are associated with JAR files in your application. If several EJBs are defined in the same JAR file, they can share the same roles. EJBs in separate JAR files must define their own roles.
Grouping related EJBs into a single JAR file is a good design practice, not least of all because it allows related beans to share the same security roles.
Applying EJB Authorization
Authorizing access to EJBs involves restricting the methods a given end user can call. When applying authorization to EJBs you must consider where to apply the authorization. You could leave all authorization to the client (Application Client or Web Application), but there are several drawbacks to this approach
Badly written clients may bypass security constraints.
The same authorization rules must be applied to all clients duplicating development effort.
Different clients may apply different authorization rules leading to inconsistent behavior between different components of the same application.
Applying authorization at the EJB level ensures all clients use the same security model. In fact implementing a consistent security model is one of the benefits of using an EJB middleware layer.
Using a combination of Session beans and Entity beans gives you a choice for where to apply authorization. Should it be on the Session beans, the Entity beans or both?
The perceived wisdom is to apply authorization to Session beans. The reasons for not applying security on Entity beans are:
Entity beans represent persistent data and should only enforce data integrity rules.
Applying authorization on an Entity bean may unnecessarily restrict the capabilities of a Session bean.
Entity beans are not normally accessed directly by clients but through a Session bean (as discussed on Day 6, “Entity EJBS.”)
Obviously, if you have chosen to expose Entity beans to the client, you should apply security on those beans.
Typically, the authorization in the EJB middleware tier is there to prevent a badly written client from breaking security rules. Normally the Client or Web Application code would ensure that logical flow of control and operations presented to end users would not give them access to unauthorized functionality. Controlling client functionality is discussed later in the sections “Applying Programmatic EJB Security,” and “Applying Programmatic Web Security.”
The same arguments for not applying security on Entity beans also apply to Message Driven Beans. In fact, because MDBs do not have a client interface they do not have access to security credentials unless they are included in the JMS message itself.
Therefore, the security for the Agency case study EJBs will be applied to the Session beans as discussed in the next section.