Securing applications
101Configuring login modules
user needs to supply his account name, without a domain name, to log in. For exam-
ple, when asked to log in by the browser, we’d supply peterj, not jbia\peterj. The
sAMAccountName contains only the basic account name, not the name in conjunction with the domain name.
Active Directory allows a user to log in using his email address, which is the value of the userPrincipalName attribute. You could require the user to use an email address to
log into a web application by changing the baseFilter to be (userPrincipalName=
{0}). The password would be the same as for the login id.
The role DN
H
is the same one we used for ldapsearch when looking up thegroup. For the filter
I
, the user’s login is used for the {0} placeholder, and the user’sfull DN is used for the {1} login id. Because Active Directory uses the user’s DN as the
value of the member attribute, we use the {1} placeholder.
When set to true, the roleAttributeIsDN option
J
indicates that the memberOfattribute is for a user object, and the name attribute for a group is a DN, not a simple
name. We also have to supply an attribute whose value is the simple group name
1)
.The group names gathered by this process form the roles to which the user belongs
and are used to grant access rights. If, in your LDAP server, the memberOf attribute is a
simple group name and not a DN, you can set roleAttributeIsDN to false; then you
don’t have to supply the roleNameAttributeID option. Table 4.7 lists other module
options that can be used for the LDAP login module.
Table 4.7 The options that can be used with the LdapExtLoginModule
Module option Description
allowEmptyPasswords Set this to true if the LDAP server allows anonymous login.
jaasSecurityDomain The MBean name of the JaasSecurityDomain used to decrypt the password specified by bindCredential.
roleAttributeId If roleAttributeIsDN is set to false, this is the name of the attri- bute of the user object that contains the role names.
roleRecursion If the LDAP server allows groups to be part of groups, set this value to the number of nesting levels allowed. The LDAP login module will then recursively search each group for parent groups to which it belongs, add- ing each one to the roles to which the user belongs. The default is 0, meaning that there’s no nesting of groups.
searchScope Allows one of the following values when searching for groups:
■ OBJECT_SCOPE—Searches only in the context specified by the
rolesCtxDN option.
■ ONELEVEL_SCOPE—Searches in the content specified by the
rolesCtxDN option and one level further out (away from the root).
■ SUBTREE_SCOPE—Searches in the content specified by the
rolesCtxDN option and all levels further out towards all branches of the tree. This is the default.
searchTimeLimit The number of milliseconds to allow for searching for groups or users. If the search takes longer, it’s aborted. The default is 10000 (10 seconds).
Time for a short quiz: what’s missing from this configuration? If you answered the user’s password, give yourself a gold star. The configuration did have a password used to log
into the LDAP server for making the queries, but this is akin to the account and pass-
word used to establish a database connection, not to authenticate a user who’s logging into an application. In the database server login module, the query included the
user’s password, but where is it in LDAP? To answer this question, we have to tell you a
little about how the LDAP login module works.
The LDAP login module performs three queries against the LDAP server to log in a
user, as follows:
■ The first query looks up the user object using only the login id. This search is
similar to the first ldapsearch query that we showed you earlier.
■ A second query is a login attempt using the user’s login id and the password.
■ The last query obtains the group objects.
The password is used, but you don’t have to reference it in the login module. Now let’s take a look at another login module that helps simplify development and testing.
4.3.4 Using the identity login module
It’s often easier to develop and test applications when you don’t have to worry about security constraints. But disabling or changing the security configuration of the appli- cation itself isn’t necessarily a good idea; you’re likely to forget to enable security
again before you check your code back into version control. JBoss SX provides a login
module called IdentityLoginModule that allows anybody to access the system, no
matter what credentials they provide. This login module isn’t meant to be used in a production environment, but it can come in handy in a development or test environ- ment. The module can be used as follows:
<login-module code="org.jboss.security.auth.spi.IdentityLoginModule" flag = "required">
<module-option name="principal">javid</module-option> <module-option name="roles">texan,newyorker</module-option> </login-module>
The principal option is the principal that all users will be authenticated as. If this
option isn’t provided, it defaults to guest. The roles option is a comma-separated list
of roles the principal will be assigned to.
Let’s explore how login-module stacking works.
4.3.5 Stacking login modules
Login modules can be stacked on top of one another if you want to authenticate or authorize against multiple sources or if want to authenticate from a different source
than you authorize from. You can define two login modules in an application-
policy definition as shown in this example:
<application-policy name="my-stacked-policy"> <authentication>
103