Reviewing Security Fundamentals
To build secure enterprise applications, security mechanisms must be established to ensure that enterprise assets and resources are protected from accidental and malicious attacks. Enterprise security addresses data resources, applications, and components, but it also deals with the secure communication between them. Security ensures that information is neither modified nor disclosed except in accordance with the security policy established by the enterprise. Most security measures involve proof material (such as passwords) and data encryption, which is the translation of data into a form that cannot be interpreted by an intruder.
We'll start by highlighting the important concepts, entities, and mechanisms used in enterprise security.
Security Concepts
A special jargon of terms and concepts is used in managing and developing enterprise security. The following sections explore the concepts used in application security and their definitions.
Resources, Users, and Groups
A resource is a critical entity that can be accessed by enterprise applications. Resources can be shared, and their accesses are controlled using sets of permissions. In the context of J2EE applications, the following resources require permissions:
A user is an entity that accesses resources. A user can be an application end user (such as a consumer or customer), or it can be a client application (such as a browser or another program). An administrator is a special type of user, who has certain capabilities to manage enterprise resources. When a user wants to access a resource, it presents a username and a credential (either a password or a digital certificate) to the application server. If the application server can prove the identity of the user Laura, it creates a security context (or a thread) and associates Laura with that context. In the event of any further access to resources, the server performs a security check to see whether Laura has the correct permissions to proceed.
A group is a collection of users. It is more efficient to manage a group than to manage a large numbers of users individually. Group members usually have something in common, such as similar permissions to access system resources. The system can be configured to assign users to groups. A person can be defined as both an individual user and a group member. Individual access permissions override any group member access permissions. Groups are defined at the operating system level, and not at the application level.
Permissions, Access Control Lists, and Realms
Permissions represent the privileges given to users to access certain resources. For example, permissions can be a combination of reading, writing, and executing files and directories. Other examples of permissions can be the ability to send and receive messages, load servlets, or connect to a hostname and port of a data source. The system administrator assigns permissions to both users and groups. This administration task is quite complex and prone to errors.
To reduce the complexity of administering security in an enterprise, an administrator protects shared resources by creating lists of users and groups that have the required permissions to access those resources. Such lists are called access control lists (ACLs). ACLs were first introduced to manage security of the Unix platform. ACLs are configured in the access control properties of the security policy.
A security realm is a logical domain of users, groups, permissions, and ACLs defined to protect resources. A user must belong to a realm in order to access resources defined in that realm. Some application servers use local disk storage or a database for storing security realms, but other security realms can use Windows NT, Unix, and Lightweight Directory Access Protocol (LDAP) for storage.
Principals and Roles
A principal is a logical entity that is associated with an identity (user, group, program, or organization) as a result of authentication. An identity can be mapped to a different principal based on the security context defined for the application. Thus, a role can have multiple principals when accessing enterprise resources.
A role is a logical grouping of users who have similar permissions, at the application level, to access resources. Roles are similar to groups, but roles are defined at the application layer. Roles are mapped to real-world groups and users (defined at the operating system layer) when the bean is deployed. J2EE security authorization is role-driven, and each principal is mapped to a unique role for the purposes of access control.
Figure 19.1 depicts the security concepts discussed so far. A client first must be identified and authenticated by the system before it is allowed access to the authorized resources.
Figure 19.1. Security concepts.
Learning Security Mechanisms
Security mechanisms provide answers to the following concerns in regard to protecting enterprise resources:
Authority: After the user is identified, what access control is allowed?
Integrity: How confidential is the data? Are passwords and credit-card numbers protected from being stolen?
Building a highly secure system is always costly, but is even harder to define, develop, and deploy. The next few sections answer the preceding list of questions and concerns.
Authentication
Authentication is the mechanism of verifying the identity of the security entity before completing a connection to the resource. The principal is the party whose identity is verified. Associated with a principal is a set of credentials, or proof materials such as passwords or digital certificates. More sophisticated credentials include smart cards and biometrics (fingerprint and retinal/iris scans). When the proof is two-way, it is referred to as mutual authentication. Authentication is the first layer of a security environment, as depicted in Figure 19.1.
After the user is authenticated, an initial security context is established and maintained by the container, and is associated with that user. Among the possible policies and mechanisms for controlling access to a security context is the Secure Sockets Layer (SSL) protocol (or HTTP over SSL [HTTPS]), which is used to encrypt passwords. This provides an additional level of security to password authentication.
The authentication process can be initiated for Web clients in the Web tier, and also can be started at the EJB container for J2EE client applications. In both cases, the corresponding container for allowing access control to resources will assess security checks. Figure 19.2 depicts the authentication for the two different clients accessing the application server.
Authentication validates the identity of the user, usually via JNDI or JAAS. We explored JNDI authentication in Day 4, and we'll explore authentication across J2EE tiers later today.
Authorization
Authorization is the mechanism that ensures only authenticated principals with the right permissions can access application components. It is a fine-grain security that allows authenticated users and groups (through access control lists) to access the assigned resources.
Roles that are allowed to access a given component are specified in the EJB's deployment descriptor. The deployer maps the roles to actual users using the J2EE server's deployment descriptors. After a user is authenticated, the container maintains a security context of that user. Whenever an attempt is made to access a protected component, the container applies security checks on the roles specified in the deployment descriptor to either grant or deny access to the user.
Encryption
Encryption is the mechanism used to translate data into a form that cannot be interpreted by an intruder. This ensures that data transmitted over the network is intelligible to only the intended recipient. Encryption is useful for securing critical data during communication between applications.
Most J2EE application servers address secure communications through SSL encryption for data integrity and confidentiality across the network. Clients can establish SSL sessions using the Hypertext Transfer Protocol (HTTP) or Remote Method Invocation (RMI) over Internet Inter-ORB Protocol (IIOP). SSL is also used to provide an additional level of security to password authentication in e-commerce applications. Optionally, SSL can be used in mutual authentication between two parties or applications.
Digital Signing
Digital signing is the mechanism of protecting the true identity of the authenticated entity. This is achieved through the use of digital certificates. A digital certificate is a statement that is digitally signed from one entity, which could be a person or a company, indicating that the public key of some other entity has some particular value. This is similar to the notary public concept used by banks and lawyers. Certificate interfaces enable developers to build tools for parsing certificates, enforcing their own site-specific certificate policies, and managing local databases of certificates.
The Java 2 Standard Edition (J2SE) Security API introduces certificate interfaces and classes for parsing and managing certificates, and provides an X.509 implementation of the certificate interfaces. The purposes of some of the certificate-related classes are described in Table 19.1.
| Class | Purpose |
|---|---|
| Certificate | A parent class for certificates that have different formats but important common uses. Subclasses are used for X.509 and Pretty Good Privacy (PGP), share general certificate functionality, such as encoding and verifying, and some types of information, such as a public key. |
| CertificateFactory | A class used to generate certificate and certificate revocation list (CRL) objects from their encoding. |
| X509Certificate | A subclass of Certificate for X.509 certificates. It provides a standard way to access all the attributes of an X.509 certificate. |
| Policy | A class that specifies the permissions available for code from various sources. |
Auditing and Filtering
Auditing is the mechanism that allows you to establish watchdog activities and maintain logs of sensitive actions taken for later analysis. Events such as failed login attempts, authentication requests, rejected digital certificates, and invalid ACLs are logged. Auditing is a fundamental mechanism in accountability, which assists in detect intrusion attempts and any security breaches. It helps in detecting errors associated with the application's code or their configurations.
Filtering is the mechanism of allowing you to configure your firewall in accepting or rejecting the client request based upon the origin (hostname or IP address) or the protocol used during the client connections. The J2EE platform does not standardize the auditing mechanism, and itís up to the container providerís implementation.
Administration
Administration is the most complex and costly aspect of application security. As a security administrator, you'll be involved in managing user security realms, repositories, and security policies. Other functions include delegation of administrative privileges, allowing users self-registration, and testing and deployment of new systems. J2EE does not support a standard for administration, and it's up to the J2EE container provider to provide the tools used.