Behind the scenes, the default realm is set in the SECURITY element in the server.xml file. The SECURITY configuration looks like this:
<SECURITY defaultrealm="file" anonymousrole="ANYJava System" audit="false"> <AUTHREALM name="file" classname="com.iplanet.ias.security.auth.realm.file.FileRealm"> <property name="file" value="instance_dir/config/keyfile"> <property name="jaas-context" value="fileRealm"> </AUTHREALM> ... </SECURITY>
The defaultrealm attribute points to the realm the server is using by default. The default realm will be used by all web applications that do not provide a valid realm in their web.xml. It must point to one of the configured AUTHREALM names. The default is the file realm.
The audit flag determines whether auditing information is logged. If set to true, the server logs audit messages for all authentication and authorization events.
If you change the realm configuration, you must restart the server for the change to take effect.
For more information about the server.xml file, see the Sun Java System Web Server 6.1 SP9 Administrator’s Configuration File Reference.
As with all realms, you can configure the Native realm using the AUTHREALM element within the SECURITY element in server.xml. Example:
<AUTHREALM name="native" classname="com.sun.enterprise.security.auth.realm.webcore .NativeRealm"> <PROPERTY name="auth-db" value="mykeyfile"> <PROPERTY name="jaas-context" value="nativeRealm"> </AUTHREALM>
The auth-db property points to the core authentication database to which the Native realm instance delegates all authentication requests. In this example, an authentication database named “mykeyfile”. This property is optional. If not specified, the core authentication engine will use the default auth-db to process all requests from this Native realm. As in the case of most realms, the jaas-context property is a pointer to the JAAS login context to be used (defined in login.conf).
No other configuration is needed by the Native realm. However, since requests are being delegated to a core authentication database, that particular authentication database must also be property configured. The rest of this section provides an example of configuring a core authentication database.
To configure a core (native) authentication database, in server.xml, the VS element must contain a USERDB element which maps the auth-db name to a database name. For example:
<VS id="https-plaza.com" .... .... <USERDB id="mykeyfile" database="myalt"> .... </VS>
Note that if the auth-db property is not given (in which case "default" is used) you could have a USERDB entry mapping id="default" to some database name. If no mapping is present, the mapping is to default.
Next, the file install-root/userdb/dbswitch.conf must contain the configuration for the myalt database. The following example defines myalt to be a file-based authentication database.
directory myalt file myalt:syntax keyfile myalt:keyfile /local/ws61/https-plaza.com/config/keyfile
The above configuration is not specific to the Native realm. Any valid authentication directory configuration can be used as the destination authentication database by the Native realm. This means the Native realm can be configured to delegate to native LDAP authentication databases or even to custom native authentication databases.
In Sun Java System web Server 6.1, web applications have two distinct mechanisms for using LDAP as the authentication engine:
Using the Java LDAP realm
Using the Java Native realm configured to delegate to the native LDAP authentication database.