Copyright (c) SEMM NL All rights reserved.
Author : Paul Hamaker. Part of

It's best to leave authentication + authorization up to the application server, so this boils down to doing a bit of configuring.

In the war file we have a logform.html,...

that contains a FORM with two INPUTS by these names.

And this ACTION.

The web.xml file contains the reference to the form,...

in the login-config tag.

The URL /restricted may be accessed by those who have a Role as Toppy,

like the user shimmie .

Provided that shimmie logs in with the correct user name/password combination.

So this login name can be used.


To protect servlet access.

Put jsp-files and html-files that need authorized access in a directory 'restricted' in the .war file.


The database tables excepted, it's all fairly standard up to this point, but further on it's really up to the vendors.

The JBoss link, for example, is in JBoss's login-config.xml.

Database queries,...

linked to the .war though the domain-name in jboss-web.xml, present in the .war .


Websphere, on the other hand, let's you map a Role, like our Toppy, to users/groups in the system's user registry through its Administrative Console.


All data transferred, including the username/password, can be intercepted. A smart thing to do is to configure the HTTP-server to support SSL, so the HTTPS protocol can be used and all data is encrypted before transferring.


Regular HTTP-authentication can be used, too

Use BASIC or DIGEST instead of FORM, resulting in a browser authentication window being presented to the user.

Where the usernames, passwords etc. have to be stored, is server-specific. Apache expects them in a .htpasswds directory.

With DIGEST the username+password are sent encrypted. NOT THE ACTUAL DATA HOWEVER ! For this you need HTTPS, SSL.




JAAS, Java Authentication and Authorization Service.