Tutorial web development (with JSF) XII – Security Part I

Sometimes it is crucial to protect an application or data against unauthorized access. Although there is no need to secure my tiny calculator, I’m going to demonstrate the principals of container based security by using this small app. For a description of the project, please refer to Tutorial web development (with JSF) III: Basic arithmetics.

Container provided security is not specific to JSF. It’s part of the HTTP handling and might be used by a simple servlet too. But later on, I’m going to show you, how to integrate this into a JSF application by using programmatic access. But, first of all, some background.

To grant a user access to a secured application, the user has to be authenticated. The user must tell the system who she is and identify herself. This might be done by providing a username („it’s me“) and a password („you may verify that it’s really me, by checking a secret information only we both share“). Alternative techniques are identity cards, certificates, fingerprints and so on. In this tutorial I focus on username/password. Once the system has authenticated the user, it will authorize her: Let her access the whole application or only parts, depending on her security status. This is realized by assigning on or different roles to the user. Depending on the role, access to the application is controlled.

Let’s recap:

  1. System offers a login form to query username and password
  2. User provides this information
  3. System verifies this information. If there is no match, login is aborted
  4. System determines roles and grants access depending on these roles

Using container provided security, step 1. might be realized in (at least) three ways:

  1. The user’s web browser displays a simple input dialog. The appearance and client-side data handling is determined by the browser. There is no further action required by the developer. This mode is called Basic Authentication.
  2. The developer provides a HTML form for the two input fields and buttons to submit or reset. These field may be integrated in a web page with look and feel of the application. The names of the mentioned fields and the actions have strictly to follow a convention. This mode is called Form based Authentication.
  3. The developer uses a free arranged JSF form. At server side, the application calls the container’s login method. This is called Programmatic Authentication.

Anyway, username and password have to be send from client to server. It doesn’t make any difference whether the password is send as clear text or as hashed digest (which might be configured in a server property): If someone capture this data, it might be re-used. Thus, a common recommendation is to use a secure transport protocol, e.g. SSL.

For step 3 of the authentication / authorization process, the server must check the input (username / password) against information stored somewhere. This is realized by so called security realms. Usually, one or more realms are pre-defined at your server. GlassFish for examples provides a couple of realms. I’m going to talk about two of them, fileRealm (user info stored in a file) and jdbcRealm (user info stored in a database). Last but not least, I’m going to present you a self-programmed (custom) realm.

Even though these security realms are sometimes implemented in a similar way, they are still vendor specific. Even more, terminology conventions may differ, too. Some call it “realm”, others “domain”, “zone” etc. Same applies to other terminology in this context like “group”, “role”, “principal”, “right” and so on.

To overcome these confusion, a standard has been created: Java Authentication Service Provider Interface for Containers (JASPIC, JSR 196). Although the definition of JASPIC started more than 10 years ago, proprietary realms are prevalent. With JEE 6 this started to change. And in combination with Java EE 7, the updated version of JASPIC may become a kind of first class citizen.

Please consider vendor specific implementation, when I write about realms. I’ll focus on GlassFish and NetBeans, and you may have to transform some info into your environment. For example, NetBeans offers some special editors to configure container based security. I’ll discuss this as well as the resulting configuration, which usually is pure XML.


To web development content.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *