The native realm is a special realm that provides a bridge between the core Sun Java System Web Server ACL-based authentication and the J2SE/Servlet authentication model. By using the native realm for Java web applications, it becomes possible 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.
This functionality is provided by pluggable realm called NativeRealm, which acts as a bridge between the J2SE security subsystem and the access control security subsystem.
Depending on whether a security constraint is configured for a web application, the two modes of operation described below are supported by the native realm:
If a security constraint is defined in the application’s deployment descriptor file, web.xml, the web container carries out normal authentication and authorization processing. When the NativeRealm realm is invoked for validating user information, the task of verification is delegated to the core auth-db specified in the realm configuration. See the Sun Java System Web Server 6.1 SP8 Administrator’s Guide for more information on how to configure auth-db in dbswitch.conf and server.xml.
For example (classname= is all on one line, with no spaces):
<AUTHREALM name="native" classname="com.iplanet.ias.security.auth.realm.webcore. NativeRealm"> <PROPERTY name="auth-db" value="name"> <PROPERTY name="jaas-context" value="nativeRealm"> </AUTHREALM>
If a security constraint is not defined in the application’s deployment descriptor file web.xml when using NativeRealm, the Java web container does not carry out authentication and authorization tasks. These tasks are left to the core access control lists (ACLs). ACLs are collections of rules that follow a hierarchy and determine whether access should be granted or denied for the requested resource. The ACLs yield the user’s identity, which is then made available to the Java web application. In other words, if the servlet later invokes a principal’s identity with the request.getUserPrincipal() method, the correct user identity will be returned.
In this scenario it is not necessary to provide an auth-db to the NativeRealm configuration, since the access control list that was applied to the given request is already bound to an auth-db.
For example:
<AUTHREALM name="native" classname="com.iplanet.ias.security.auth.realm.webcore. NativeRealm"> </AUTHREALM>
For more details about access control lists, see the Sun Java System Web Server 6.1 SP8 Administrator’s Guide.
While it is possible to apply both ACL access control rules and web.xml security constraints on a single application, this usage is discouraged. It may lead to duplicate authentication prompts or otherwise confusing behavior. You should always pick either core ACL or J2SE web.xml-based access control mechanisms for a given web application.