Java Reference
In-Depth Information
</authentication>
</security-domain>
In order to get working with this configuration, you have to first create the required
tables and insert some sample data in it:
CREATE TABLE USERS(login VARCHAR(64) PRIMARY
KEY, passwd VARCHAR(64));
CREATE TABLE USER_ROLES(login VARCHAR(64), role
VARCHAR(32));
INSERT into USERS values('admin', 'admin');
INSERT into USER_ROLES values('admin',
'Manager');
As you can see, the
admin
user will map again to the
Manager
role. One caveat
of this configuration is that it uses clear-text passwords in the database; so before
rolling this module into production, you should consider adding additional security to
your login module. Let's see how in the next section.
Encrypting passwords
Storing passwords in the database as a clear-text string is not considered a good
practice; as a matter of fact, a database has even more potential security holes than
a regular file system. Imagine, for example, that a DBA added a public synonym for
some tables, forgetting that one of those tables was holding sensitive information like
application passwords! You then need to be sure that no potential attackers will ever
be able to deliver the following query:
Fortunately, securing application passwords is relatively easy; you can add a few ex-
tra options to your Login Module, specifying that the stored passwords are encrypted
