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. This verifies users through an underlying realm.
Role-based Authorization. This assigns users to roles, which in turn are granted or restricted access to resources.
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.
Sun Java System Web Server 6.1 provides the following realms:
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.
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:
For more information about the various file-based authentication databases, see <add>.
The user information file used by the file realm is initially empty. You must add users before you can use the file realm. For more information on how you can do this, see Creating a New User in a Key File Authentication Database.
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.
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.
For details on how to set up the server and client certificates, see Certificate-based Authentication.
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.
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.
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.
The Java Servlet 2.3 Specification defines how to establish access control rules to restrict access to the various J2SE application resources.
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.
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:
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:
<sun-web-app> <security-role-mapping> <role-name>manager</role-name> <principal-name>jsmith</principal-name> <group-name>divmanagers</group-name> </sun-web-app>
For more information about deployment descriptor files, see the Sun Java System Web Server 6.1 SP11 Programmer’s Guide to Web Applications.