|Home > Apache Geronimo v1.0 > Documentation > Apache Geronimo v1.0 - User's Guide > Security > Component Configuration|
There are a number of components that need be configured for the system to work. Such components are: implementations of the ConfiguraitonEntryFactory interface, Login Modules, Login Module Use among others.
We start with GBeans that implement ConfigurationEntryFactory interface and supporting GBeans, followed by the LoginModule gbean.
DirectConfigurationEntry exposes login module directly to JAAS clients. You have to specify Login Module here directly. To be able to login into Geronimo specify JaasLoginCoordinator login module.
DirectConfigurationEntry GBean declares following metadata:
The following example shows how DirectConfigurationEntry is configured to use the ServerLoginCoordinator login module GBean.
ServerRealmConfigurationEntry connects server side component (such as a Servlet) to the Security Realm. It allows decoupling of configuration name and Security Realm name.
ServerRealmConfigurationEntry declares following metadata:
The following example shows how to setup the ServerRealmConfigurationEntry with the name of JMX. The security realm name is geronimo-properties-realm.
The only implementation of the org.apache.geronimo.security.realm.SecurityRealm interface in Geronimo is the org.apache.geronimo.security.realm.GenericSecurityRealm class.
org.apache.geronimo.security.realm.GenericSecurityRealm implements 2 interfaces: SecurityRealm and ConfigurationEntryFactory. The GenericSecurityRealm name is also the name of the ConfigurationEntryFactory implementation. That is why you can use GenericSecurityRealm name from your application as application configuration entry name passed to the LoginContext() constructor, see the Geronimo and JAAS section.
You need to give a name to the GenericSecurityRealm and configure it's authentication policy by wiring up login modules into the realm. Login modules are not wired up by themselves but are qualified by their use in the computation of authentication outcome.
The list of login modules that must be configured into the GenericSecurityRealm is specified with the org.apache.geronimo.security.jaas.JaasLoginModuleUse GBean. It is injected with the LoginModuleGBean, the value of the control-flag that specifies how authentication outcome of this login module must be combined with the authentication outcomes of other login modules to compute authentication result, and a reference to the next LoginModuleUse definition.
You may wonder why do you need a linked list of GBeans. Wouldn't it be much easier to list parameters for the GenericSecurityRealm and be done with it?
The answer is that Geronimo is an IOC container and one of it's major functions in addition to dependency injection is dependency management. That means that if GBean A depends on GBean B, then GBean B will be started by the Geronimo container before GBean A. Login modules are deployed as GBeans and GenericSecurityRealm GBean depends on the login module GBeans. If you just list login module object names together with the control flags, Geronimo container would not be able to resolve this dependencies and you would not have a guarantee that all login modules wired up into the generic Security Realm are up and running before GenericSecurityRealm comes online.
But still, an effort required to configure login modules into GenericSecurityRealm with the list of LoginModuleUse GBeans may seem excessive. To help with this kind of problems GBean definition syntax allows for syntactic sugar in the form of xml-reference element. At this point it is necessary to emphasize that this is just a reference that gets processed at the deployment time to create and wire up all GBeans that otherwise would have been explicitly defined. We will show the use of xml-reference in the GenericSecurityRealm configuration later.
Here is an example of generic-security-realm setup, we want to wire the GenericSecurityRealm named geronimo-properties-realm with the login module
named properties-login that authenticates against a property file. Our Security Realm authentication policy requires properties-login module authentication to succeed.
It does not look too bad in this example but imagine that you have 2 login modules in the Security Realm and how many GBean dependencies you have to configure.
Note that the order in which all these elements are defined does not matter. If you look at the deployment plans, you will find that login-module GBeans are defined first (as they represent elements of reuse by the GenericSecurityRealm GBeans). GenericSecurityRealm GBeans and JaasLoginModuleUse GBeans are normally close to each other.
The reason for the introduction of the xml-reference element in GBean syntax was explained earlier. But just to repeat: it is a syntactic sugar that allows problem friendly xml syntax in GBean definition.
Problem-friendly xml syntax for the login module configuration is defined by the "http://geronimo.apache.org/xml/ns/loginconfig-1.0" xml namespace.
The following example briefly shows how the LoginConfig schema is used.
Login module is configured with org.apache.geronimo.security.jaas.LoginModuleGBean. It takes loginModuleClass attribute that specifies the login module implementation class. Other interesting parameters are options and loginDomainName.
The following is an example of a login module that uses property files as authentication database. Values of property files are passed as options attribute.