Realm-based Security

The J2SE-based security model provides for security realms that identify
and authenticate users. The user information is obtained from an underlying
security realm. Realm-based security consists of two aspects:

Realm-based User Authentication

The authentication process verifies users through an underlying realm,
also known as a security domain. A realm consists of a set of users, optional
group mappings, and authentication logic that can validate authentication
requests. Once an authentication request is validated by a configured realm
and the security context established, this identity is applied to all subsequent
authorization decsisions, unless overruled by a run-as condition.

A server instance may have any number of configured realms. The configuration
information is present in the AUTHREALM element in the server.xml file.

In Sun Java System Web Server, the authentication service is built using
JAAS, which provides pluggable security domains. The Java authentication realms
in Sun Java System Web Server 6.1 are compatible with Sun Java System Application
Server 7.0 realms.

LDAP realm

The ldap realm allows you to use an LDAP database
for user security information. An LDAP directory service is a collection of
attributes with unique identifiers. The ldap realm is ideal
for deployment to production systems.

In order to authenticate users against the ldap realm,
you must create the desired user(s) in your LDAP directory. You can do this
from the Administration Server’s Users & Groups tab or from your
LDAP directory product’s user management console. For more information,
see Creating a New User in an LDAP-based Authentication Database.

File realm

The file realm is the default realm when you first
install the Sun Java System Web Server. It is easy and simple to set up and
provides significant convenience to developers.

The file realm authenticates users against user data
stored in a text file. The following authentication databases are supported
by the file realm:

keyfile-style databases

htaccess-style databases

digest-style databases

For more information about the various file-based authentication databases,
see <add>.

Solaris realm

The solaris realm allows authentication using Solaris
username + password data. This realm is only supported on Solaris 9. An additional
step of setting up a separate database is eliminated since this realm uses
the user database of the Solaris 9 operating environment.

Certificate realm

The certificate realm supports SSL authentication. The certificate realm
sets up the user identity in the Sun Java System Web Server’s security
context and populates it with user data from the client certificate. The J2SE
containers then handle authorization processing based on each user’s
DN from his or her certificate. This realm authenticates users with SSL or
TLS client authentication through X.509 certificates.

Custom Realm

You can build realms for other databases, such as Oracle, to suit your
specific needs by using pluggable JAAS login modules and a realm implementation.

Note –

Client-side JAAS login modules are not suitable for use with Sun
Java System Web Server.

Refer to the sample realm in Sun Java System Web Server 6.1 as a template.

Native Realm

The Native realm is a special realm that provides a bridge between the
core ACL-based authentication model and the J2SE/Servlet authentication model.
Use the Native realm for Java web applications to have the ACL subsystem perform
the authentication (instead of having the Java web container do so) and yet
have this identity available for Java web applications.

When an authentication operation is invoked, the Native realm delegates
this authentication to the core authentication subsystem. From the user’s
perspective this is essentially equivalent to, for example, the LDAP realm
delegating authentication to the configured LDAP server. When group membership
queries are processed by the Native realm, they are also delegated to the
core authentication subsystem. From the Java web modules and the developers
perspective, the Native realm is no different from any of the other Java realms
which are available for use with web modules.

Additional configuration is required as the Native realm delegates the
authentication to the core, . For more information, see Configuring the Native Realm.

The Sun Java System Web Server 6.1 Programmer’s Guide
to Web Applications provides a detailed discussion on J2SE security
realms and the configuration parameters you can use to configure security
realms.

Role-based Authorization

The Java Servlet 2.3 Specification defines how to establish access control
rules to restrict access to the various J2SE application resources.

Mapping Roles to Restricted Areas

J2SE access control is based on roles. To restrict access to specific
HTML pages, servlets, JSPs, and so forth, you must define the following:

The restricted areas, as listed in the Web module descriptors
(web.xml)

The roles which are granted access to each restricted area
(in web.xml)

User and group mappings to roles, that determine which specific
users are authorized to access which restricted areas (in sun-web.xml).

Users can assume multiple roles. Access is allowed to the corresponding
areas on verification that users have been assigned at least one of the roles.

Use the samples located in the webapps/security directory
with various access restrictions in Sun Java System Web Server 6.1 as templates.
For additional discussion on Servlet role-based security, refer to the Servlet
2.3 specification.

Defining Access Control by Roles

J2SE application roles are abstract ones and apply to specific applications.
To run your application in a real-world environment with restricted access
to authorized users only, you must map the user names to the roles in the sun-web.xml descriptor. Employ either or both of these ways:

Principal mapping - Map a user name or multiple names directly
to a role in sun-web.xml. This method is convenient for
testing but does not scale beyond a limited number of users in each role.

Group mapping - Map a user name or multiple ones indirectly through
one or multiple groups in sun-web.xml. (For example, group
names can be engineers, managers, or staff.) Any authenticated user who belongs
to the groups listed is then assigned the application role. Please note that
the active realm implementation (or the database that is references) is responsible
for determining which users belong to a given group.

When a principal (user) requests a particular Web resource, for example,
a servlet or a JSP, the Web container checks the security constraints or permissions
associated with the resource in the deployment descriptor files to determine
whether the principal is authorized to access it.

Role mapping entries map a role to a user or a group in the module descriptor.
Example: