Permissions Overview

• Permissions   Expand (p)

Setting up permissions means specifying who is allowed to access which web pages. In other words, you're assigning access rights. For example, only managers can access the payroll section of our intranet, but anyone can access the product catalog. The terms permissions, access rights and security constraint all basically mean the same thing: who is allowed access to what pages. Incidently, security constraint is the term used by the Servlet spec.

• Permissions assigned in DD   Expand (p)

J2EE web containers allow you to assign permissions to (i.e. password protect) your web-accessible files (or groups of files) by adding entries to the web app's deployment descriptor. Before doing an example, we should define a few terms: users, groups, roles and web-resource-collection.

• Users and Groups   Expand (p)

Before you can protect portions of your web app, you must define your users and groups. This typically includes:

• Users and Groups   Expand (ul)
• A list of users and their passwords
• A list of groups (i.e. administrators, managers, employees, etc.)
• Plus someway to specify which users belong to which groups
• Web App Independent   Expand (p)

This users-and-groups-database typically exists independantly of your web application.

• Users-and-Groups Not Specified   Expand (p)

J2EE does not define how to store your users-and-groups database. In fact, many organizations already have this type of database setup. This may take the form of directory server or LDAP server (like MS Active Directory) or a relational database (like Oracle). Most J2EE web containers let you use your existing users-and-groups database. But if you don't have an existing users-and-groups database, most J2EE web containers will provide their own method of defining users and groups. For example, Orion allows you to specify users and groups in an xml file called principals.xml.

• Roles   Expand (p)

J2EE makes use of the concept of roles. Roles are like groups, and often have a one-to-one correspondence with groups. In fact, people are often confused about the distinction between roles and groups. Here is the difference: Roles are defined by your web application. Groups are defined external to the web application. This is what allows you to use an existing users-and-groups database. At some point, the application-defined roles must be mapped to the externally-defined groups.

• Web Resource Collection   Expand (p)

A "web-resource-collection" is just a fancy way of saying, "some sub-section of our web application". A web-resource-collection could be one html page. It could be 10 pages. It could be "all gifs". It could be "all jsp pages in the payroll folder". Web-resource-collections are important, because this is how permissions are assigned. When assigning permissions in a web app, you assign them to a web-resource-collection. For example, the web-resource-collection defined by "/payroll/*" can only be accessed by managers.

• Steps   Expand (p)

The General steps to securing some part of your web application are as follows. Note: each of these steps will be elaborated in the next examplet.

• Steps   Expand (ol)
1. Setup your users-and-groups database (how this is done is not specified by J2EE).
2. Declare web-app specific security-roles (this is done in the deployment descriptor).
3. Define security-constraints - i.e. permissions (this is done in the deployment descriptor).
4. Associate (or map) each application-defined role to an externally-defined group (how this is done is not specified by J2EE).