A realm, also called a security policy domain or security domain, is a scope over which the server defines and enforces a common security policy. In practical terms, a realm is a repository where the server stores user and group information.
The Enterprise Server comes preconfigured with three realms: file (the initial default realm), certificate, and admin-realm. It is possible to also set up ldap, JDBC, solaris, or custom realms. Applications can specify the realm to use in their deployment descriptor. If they do not specify a realm, the Enterprise Server uses its default realm.
In the file realm, the server stores user credentials locally in a file named keyfile. You can use the Admin Console to manage users in the file realm.
In the certificate realm, the server stores user credentials in a certificate database. When using the certificate realm, the server uses certificates with the HTTPS protocol to authenticate Web clients. For more information about certificates, see Introduction to Certificates and SSL.
The admin-realm is also a FileRealm and stores administrator user credentials locally in a file named admin-keyfile. Use the Admin Console to manage users in this realm in the same way you manage users in the file realm.
In the ldap realm the server gets user credentials from a Lightweight Directory Access Protocol (LDAP) server such as the Directory Server. LDAP is a protocol for enabling anyone to locate organizations, individuals, and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet. Consult your LDAP server documentation for information on managing users and groups in the ldap realm.
In the JDBC realm, the server gets user credentials from a database. The Enterprise Server uses the database information and the enabled JDBC realm option in the configuration file. For digest authentication, a JDBC realm should be created with jdbcDigestRealm as the JAAS context.
In the solaris realm the server gets user credentials from the Solaris operating system. This realm is supported on the Solaris 9 OS and later. Consult your Solaris documentation for information on managing users and groups in the solaris realm.
A custom realm is any other repository of user credentials, such as a relational database or third-party component. For more information, see the Admin Console online help.
The Enterprise Server enables you to specify a user's credentials in the JDBC realm instead of in the connection pool. Using the JDBC realm instead of the connection pool prevents other applications from browsing the database tables for the user's credentials. A user's credentials are the user's name and password.
By default, storage of passwords as clear text is not supported in the JDBC realm. Under normal circumstances, passwords should not be stored as clear text.
Create the database tables in which to store the users' credentials for the realm.
How to create the database tables depends on the database that you are using.
Add the users' credentials to the database tables that you created in Step 1.
How to add users' credentials to the database tables depends on the database that you are using.
Create a JDBC realm.
Use the Admin Console GUI for this purpose. For instructions for creating a JDBC realm, see the online help for the Admin Console GUI.
Specify the realm that you created in Step 3 as the realm for the application.
To specify the realm, modify the appropriate deployment descriptor for your application:
For an enterprise application in an Enterprise Archive (EAR) file, modify the sun-application.xml file.
For a web application in a Web Application Archive (WAR) file, modify the web.xml file.
For an enterprise bean in an EJB JAR file, modify the sun-ejb-jar.xml file.
For more information about how to specify a realm, see How to Set a Realm for an Application or Module in Sun GlassFish Enterprise Server 2.1 Developer’s Guide.
Assign a security role to users in the realm.
To assign a security role to a user, add a security-role-mapping element to the deployment descriptor that you modified in Step 4.
The following example shows a security-role-mapping element that assigns the security role Employee to user Calvin.
<security-role-mapping> <role-name>Employee</role-name> <principal-name>Calvin</principal-name> </security-role-mapping>