Geronimo Security Architecture

The security model of Geronimo can be relatively straightforward when you consider that the end goal is to control the access to the applications that you develop. The cornerstones of this model are the two well-known security aspects: authentication and authorization.

Authentication

First, before enforcing any security policies that you may have, you must authenticate your users - making sure that they are who they claim to be. This can be as simple as checking user ID and password against a password file, or it may be as complex as requiring identification via an iris scan with a password and an ID badge.

As you may have noticed, there are at least as many ways to authenticate a user as there are operating systems - most requiring you to log on to the system before using it. In fact, authentication systems and standards exist all over the map. And they seem to be invented and adopted, and then stay around forever. Users don’t seem to take to migration between authentication systems lightly.

Furthermore, to be totally flexible, the concept of a living-and-breathing user must be abstracted to that of a security principal. This abstraction allows security policies to be enforced against tasks that are executed not directly by an authenticable human (for example, daemon processes that run regularly). It also allows the server to access system resources and call services on behalf of (acting as) specific users. In Geronimo security speak, a security principal supplies a credential to authenticate itself. This is analogous to a user supplying a password or biometrics for authentication.

Rich authentication capabilities are already built into the modern Java platform. Java Standard Edition 1.4 (which is an integral part of J2EE 1.4) already includes an authentication subsystem that accepts Pluggable Authentication Modules (PAMs) to carry out actual authentication. This flexible plug-in-based authentication subsystem is part of JAAS 1.0.

Authorization

Authorization (the act of enforcing access according to authenticated security principals) is the other cornerstone facet of the security architecture. A set of access rules must be declared, maintained, tracked, and enforced by Geronimo to ensure that unauthorized access is not allowed under any circumstance. This set of access rules forms a security policy. Authorization in Geronimo can be controlled by declaring security policies, and having the container enforce these policies during run time.

Using a security policy, you can allow authenticated principals to access different parts of the application based upon the kinds of roles they play (such as administrator, manager, supervisor). Often, you do not know ahead of time the set of principals who will be accessing your application. Authorization based on roles (instead of individual users) allows you to secure your application without knowing all the possible principals in advance. Access control is not limited to parts of a Web application, but also applies to most other Geronimo-managed resources (such as database connections, message queues, and external EJBs). These are frequently referred to as protected resources.

As a J2EE server, Geronimo supports both declarative security and programmatic security. Declarative security allows security policies to be added to modules via a security descriptor within deployment plans. These policies are enforced by Geronimo and can be modified without changing the code of the modules. Programmatic security, on the other hand, is the explicit code fragments that run and perform access checks. Policies enforced by programmatic security are hard-coded into the application and can not typically be modified without a recompilation of the code. The focus in this chapter is on declarative security. Consult a J2EE development book if you are interested in the details of programmatic security support.

Under the Geronimo security architecture, you must first create a security realm on the server and then use it to supply authentication and authorization services for your protected resources. A security realm is always associated with a set of login domains. Both security realm and login domains are concepts that are explored in detail in the next section.

Geronimo’s security architecture is completely componentized. Security components such as security realms and login modules are implemented as GBeans (server software components managed by Geronimo). These GBeans are readily configurable via XML descriptor elements in deployment plans. They can be configured flexibly to secure your application.

As an administrator, it is important to become familiar with the configuration of the Geronimo security components and their model of interaction.

Security Realms and Login Domains

A security realm is made up of one or more login domains and an authentication policy. Each of the login domains can represent a different source of authentication information. The authentication policy controls how authentication must succeed before the security principal is considered to be authenticated.

A login domain represents a physical source of authentication information (typically containing user, credentials, and user-to-group mapping). Physically, it may use an SQL database with user/password information, an LDAP server, a properties file read into memory, or other storage of user/group data. When a user successfully authenticates against a login domain (using login modules, covered in the next section), the user is represented internally (within the Geronimo server) by a set of javax.security .Principal objects. This set typically includes a user object and one or more group objects. The group objects represents the roles that the user plays (or groups that the user belongs to). These are the roles/ groups that are typically used in deployment plans and J2EE deployment descriptors to protect application resources.

For example, in order for you to be granted access to your employment record, you may need to be authenticated successfully against your department’s Windows 2003 Server authentication (NTLM) server (login domain #1), as well as the Human Resource department’s LDAP-based system (login domain #2). You can configure a security realm consisting of two login domains to accomplish this. Figure 15-1 illustrates this scenario.

Figure 15-1: Security realm

During the configuration of a security realm such as the one shown in Figure 15-1, you can specify in the authentication policy that authentication will only succeed if every login domain is authenticated successfully (in other words, all must pass; a single login domain authentication failure causes full failure to access resources), or you can specify that only one success is sufficient to authenticate the security principal. In Geronimo, enforcement of this authentication policy is available via the custom configuration of login modules within a security realm.

You can run Geronimo on a Java Virtual Machine (JVM) supporting either the J2SE 1.4 or JSE 5 Java platform. Both of these platforms have JAAS 1.0 built in. Since JAAS 1.0 already includes PAMS implementations to authenticate against a variety of common systems, Geronimo’s designers took advantage of this and based login domain implementation on these pluggable authentication components. These components are called JAAS login modules (not to be confused with login domains).

JAAS Login Modules

To successfully configure login domains - and create security realms - you must be able to configure some physical authentication modules. These authentication modules are the JAAS login modules, so you will need to be able to configure JAAS.

In Geronimo, the pluggable authentication modules in JAAS (login modules) are represented by configurable LoginModule components. You can configure a set of configuration entries that relates an application name or realm name to a set of LoginModules.

A LoginModule is a physical authenticator. It handles the interaction between the client and a specified login domain. Physical authentication is always performed through one of these LoginModules. Each LoginModule can represent a login domain and is the key piece of actual code that validates and verifies the user’s credentials against that domain.

In Geronimo, several types of security components can reference LoginModules. These include the following:

• GenericSecurityRealm

• ServerRealmConfiguratioEntry

• DirectConfigurationEntry

By far, the type that will be used most frequently is GenericSecurityRealm. This component, of course, represents a generic security realm.

The configuration of all of these components will be discussed in detail later in this chapter. The focus of attention in the next section will be on GenericSecurityRealm,.

The GenericSecurityRealm

The GenericSecurityRealm represents a plain-vanilla security realm and can be used as a model in creating your own custom security realm. The GenericSecurityRealm configuration entry lets you configure multiple LoginModules, allowing you to chain them together (see Figure 15-2).

Figure 15-2: JAAS Security GBean relationships

JAAS Login Modules Chaining

Chaining is an extended concept of JAAS and lets you do powerful things, such as have multiple login domains to authenticate against, or plug in specialized utilities that can enable logging or lock out bad authentication attempts.

Take a careful look at Figure 15-2. A GenericSecurityRealm contains a reference to a JaasLoginModuleUse component. This component, in turn, contains a reference (or acts as a wrapper) to a single LoginModule and its JAAS controls flag. The JaasLoginModuleUse component can also hold a reference to another JaasLoginModuleUse component (configured via the next attribute). This is the mechanism that allows chaining of multiple LoginModules within a realm or configuration entry.

Geronimo Server JAAS Configuration

The GeronimoLoginConfiguration GBean is responsible for representing the entire login configuration for JAAS. It will maintain references to all of the different ConfigurationEntryFactory GBeans, which includes the GeronimoSecurityRealm, ServerRealmConfiguratioEntry, and DirectConfigurationEntry GBeans.

The JaasLoginService GBean is the component that handles the interface between the client and the Geronimo security realm. This GBean handles both the server-side and client-side interaction for authentication, and acts as a bridge between the two.

JAAS Login Coordinator

Underneath the hood of the GeronimoSecurityRealm and JaasLoginService, the interaction is managed by a single component called the JaasLoginCoordinator. This component is actually a LoginModule. The GeronimoSecurityRealm component creates it at run time and stuffs this component into the login configuration.

This JaasLoginCoordinator is secret exit for the client or server to call the JAAS API. It acts as a proxy to the other LoginModules in the chain and handles the standard JAAS API calls to login(), initialize(), commit(), abort(), and logout(). In other words, whenever these methods are called from the client, the JaasLoginCoordinator ‘s version will be called, and proxy the calls for all of your other configured LoginModules. The interesting aspect of this is that the client thinks it is talking to a single LoginModule, when, in reality, it is simply acting as an adapter to the JaasLoginService and the other chained LoginModules.

Figure 15-3 shows the interaction between the client and the LoginModules. The client in these instances generally represents a remote process or a Web application. This example shows a configuration that contains a chain of two LoginModules, one for LDAP and one for a MySql database. When the JAAS API calls login(), it invokes the JaasLoginCoordinator as a primary LoginModule. The JaasLoginCoordinator proxies the calls for each of the LoginModules in the configuration as a chain by working through the JaasLoginService GBean by calling its performLogin() method. The JaasLoginService then passes the original JAAS login() call onto each of the LoginModules.

Important

Each GeronimoSecurityRealm creates and has its own JaasLoginCoordinator, so each JaasLoginCoordinator is specific to a single security realm.

Figure 15-3: JaasLoginCoordinator proxying calls to LoginModules

The operations of the JaasLoginCoordinator occurs under the hood and does not affect how you configure Geronimo security realms. This exploration serves to provide insight into the actual operation of the security system.

JMX Remoting Login Service

The JaasLoginService represents the Geronimo Login Service API that enables access to the LoginModules. For in-container access, the JaasLoginCoordinator acts as the bridge between the client and the security realm through the JaasLoginService. This allows authentication by any application components running within the same JVM as the Geronimo server. Sometimes separate Geronimo instances, each running in its own JVM, may need to use a common authentication service. For example, you may want to host EJBs in one Geronimo instance, and the Web tier (Tomcat) on another Geronimo instance. In these cases, Geronimo needs to support remote access to the JaasLoginService.

Geronimo accomplishes this by exposing a JMX connector GBean and a server wrapper around the JaasLoginService. In the Geronimo default security deployment plan, the JMXService GBean is the JMX connector, and the JaasLoginServiceRemotingServer GBean is the server wrapper that connects the JMX connector as a server to the JaasLoginService.

As a result of this configuration, Geronimo offers secure JMX access to the JaasLoginService with a server listening on port 4242 using the JMX protocol.

Authorization and JACC

Most of the discussions in this chapter centers around authentication. For authorization, Geronimo fully supports JSR 115, the JACC specification. JAAC represents a set of contracts between authorization policies and the Geronimo server. Implementing the JACC specification means that the container supports three separate subcontracts:

1. Provider Configuration

2. Policy Configuration

3. Policy Decision and Enforcement

This allows the container to apply a standard for authorization to your servlet and EJB applications, using the java.security.Policy object to make these decisions.

One major end result of JACC implementation is the ability to support J2EE standard declarative security elements.

Geronimo, through JACC, supports the ability to handle static principal-to-role mappings from your application’s deploy descriptors/plans. Essentially, this means that your authorization decisions can be implemented through flexible policies based on a deployment descriptor, instead of having proprietary authorization code specifically used within the EJB and/or Web containers.

It allows declarative principal/role mapping access and permission control within your Web and EJB applications. You will see how to declare principal/role mapping later in this chapter.

With most of the theory out of the way, the following sections examine how to configure the components in the Geronimo security architecture.