Sun GlassFish Enterprise Server v3 Prelude Administration Guide

Administering Authentication Realms

An authentication realm, also called a security policy domain or security domain, is a scope over which the Enterprise Server defines and enforces a common security policy. Enterprise Server is preconfigured with the file, certificate, and admin-realm realms. In addition, you can set up ldap, jdbc, solaris, or custom realms. An application can specify which realm to use in its deployment descriptor. If the application does not specify a realm, Enterprise Server uses its default realm (file).

file realm

Enterprise Server stores user credentials locally in a file named keyfile. The file realm is the initial default realm.

admin-realm realm

The admin-realm is also a file realm and stores administrator user credentials locally in a file named admin-keyfile.

certificate realm

Enterprise 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.

ldap realm

Enterprise 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.

jdbc realm

Enterprise Server gets user credentials from a database. The server uses the database information and the enabled jdbc realm option in the configuration file.

Custom realm

You can create other repositories for user credentials, such as a relational database or third-party components. For more information on custom realms, see the Administration Console online help.

The Enterprise Server authentication service can govern users in multiple realms.

The following tasks and information are used to administer authentication realms:

ProcedureTo Create an Authentication Realm

The remote create-auth-realm command enables you to create an authentication realm.

  1. Ensure that the server is running.

    Remote commands require a running server.

  2. Create a realm by using the create-auth-realm(1) command.


Example 7–1 Creating a Realm

The following example command creates a realm named db:


asadmin create-auth-realm --classname com.iplanet.ias.security.auth.realm.DB.Database 
--property defaultuser=admin:Password=admin db

Information similar to the following is displayed:


Command create-auth-realm executed successfully.

See Also

To see the full syntax and options of the command, type asadmin create-auth-realm --help at the command line.

ProcedureTo List Authentication Realms

The remote list-auth-realms command enables you to list the existing authentication realms.

  1. Ensure that the server is running.

    Remote commands require a running server.

  2. List realms by using the list-auth-realms(1) command.


Example 7–2 Listing Realms

The following example command lists the authentication realms on localhost:


asadmin list-auth-realms

Information similar to the following is displayed:


db
certificate
file
admin-realm
Command list-auth-realms executed successfully.

See Also

To see the full syntax and options of the command, type asadmin list-auth-realms --help at the command line.

ProcedureTo Delete an Authentication Realm

The remote delete-auth-realm command enables you to delete an existing authentication realm.

  1. Ensure that the server is running.

    Remote commands require a running server.

  2. Obtain the exact name of the realm that you are deleting.

    To list the existing realms:


    asadmin list-auth-realms
    
  3. If necessary, notify users that the realm is being deleted.

  4. Delete the realm by using the delete-auth-realm(1) command.

  5. To apply your changes, restart Enterprise Server.

    1. Stop Enterprise Server.

      For instructions, see To Stop a Domain (or Server).

    2. Start Enterprise Server.

      For instructions, see To Start a Domain (or Server).


Example 7–3 Deleting a Realm

The following example command deletes an authentication realm named db localhost:


asadmin delete-auth-realm db

Information similar to the following is displayed:


Command delete-auth-realm executed successfully.

See Also

To see the full syntax and options of the command, type asadmin delete-auth-realm --help at the command line.

ProcedureTo Configure a JDBC Realm

Enterprise Server enables you to specify a user's credentials (user name and password) 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 user credentials.


Note –

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.


  1. Create the database tables in which to store user credentials for the realm.

    How you create the database tables depends on the database that you are using.

  2. Add user credentials to the database tables that you created.

    How you add user credentials to the database tables depends on the database that you are using.

  3. Create a jdbc realm.

    For instructions, see To Create an Authentication Realm.

  4. Modify the deployment descriptor to specify the jdbc realm.

    Modify the deployment descriptor that is associated with your application.

    For more information about how to specify a realm, see How to Configure a Realm in Sun GlassFish Enterprise Server v3 Prelude Developer’s Guide.

  5. Assign security roles 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.


Example 7–4 Assigning a Security Role

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>