Anchor | ||||
---|---|---|---|---|
|
Article donated by: Simon Godik, Hernan Cunico
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....
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 syntactic sugar 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.
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<GBean name="geronimo-properties-realm" class="org.apache.geronimo.security.realm.GenericSecurityRealm"> <!-- security-realm name; this is a name of the Security Realm as well as the name of -- the configuration entry used by the application --> <attribute name="realmName">geronimo-properties-realm</attribute> <!-- reference to the head of the login module use list --> <reference name="LoginModuleConfiguration"> <name>properties-login</name> </reference> <!-- server-info reference is passed to most GBeans --> <reference name="ServerInfo"> <module>org/apache/geronimo/System</module><name>ServerInfo</name> </reference> <!-- reference to the login-service GBean --> <reference name="LoginService"><name>JaasLoginService</name></reference> </GBean> <!-- this is the head of the login-module-use list --> <GBean name="properties-login" class="org.apache.geronimo.security.jaas.JaasLoginModuleUse"> <!-- login module must succeed --> <attribute name="controlFlag">REQUIRED</attribute> <!-- reference to the login module --> <reference name="LoginModule"> <name>properties-login</name> </reference> </GBean> <!-- this is login module GBean --> <GBean name="properties-login" class="org.apache.geronimo.security.jaas.LoginModuleGBean"> <attribute name="loginModuleClass"> org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule </attribute> <attribute name="serverSide">true</attribute> <!-- login module specific options --> <attribute name="options"> usersURI=var/security/users.properties <!-- user database --> groupsURI=var/security/groups.properties <!-- group database --> </attribute> <attribute name="loginDomainName">geronimo-properties</attribute> </GBean> |
It does not look too bad here, 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 'll 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.
Configuring GenericSecurityRealm using xml-reference
Anchor | ||||
---|---|---|---|---|
|
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.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<GBean name="geronimo-properties-realm" class="org.apache.geronimo.security.realm.GenericSecurityRealm"> <!-- security-realm name; this name is reused by the -- configuration-entry-factory interface implementation by the -- generic-security-realm; you may use this name as application -- configuration name parameter passed to the LoginContext constructor --> <attribute name="realmName">geronimo-properties-realm</attribute> <!-- xml reference, better than before? --> <xml-reference name="LoginModuleConfiguration"> <lc:login-config xmlns:lc="http://geronimo.apache.org/xml/ns/loginconfig"> <lc:login-module control-flag="REQUIRED" server-side="true"> <lc:login-domain-name>client-properties-realm</lc:login-domain-name> <lc:login-module-class> org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule </lc:login-module-class> <lc:option name="usersURI"> var/security/users.properties </lc:option> <lc:option name="groupsURI"> var/security/groups.properties </lc:option> </lc:login-module> </lc:login-config> </xml-reference> <!-- server-info reference is passed to most GBeans --> <reference name="ServerInfo"> <module>org/apache/geronimo/System</module><name>ServerInfo</name> </reference> <!-- reference to the login-service GBean --> <reference name="LoginService"><name>JaasLoginService</name></reference> </GBean> |
Configuring Login module
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.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<GBean name="properties-login"
class="org.apache.geronimo.security.jaas.LoginModuleGBean">
<attribute name="loginModuleClass">
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
</attribute>
<attribute name="serverSide">true</attribute>
<attribute name="options">
usersURI=var/security/users.properties
groupsURI=var/security/groups.properties
</attribute>
<attribute name="loginDomainName">geronimo-properties-realm</attribute>
</GBean> |