1 Administering System Security

Authentication

Authentication is the way in which an entity (a user, an application, or a component) determines that another entity is who it claims to be. An entity uses security credentials to authenticate itself. The credentials might be a user name and password, a digital certificate, or something else. Usually, servers or applications require clients to authenticate themselves. Additionally, clients might require servers to authenticate themselves. When authentication is bidirectional, it is called mutual authentication.

When an entity tries to access a protected resource, GlassFish Server uses the authentication mechanism configured for that resource to determine whether to grant access. For example, a user can enter a user name and password in a web browser, and if the application verifies those credentials, the user is authenticated. The user is associated with this authenticated security identity for the remainder of the session.

Authorization

Authorization, also known as access control, is the means by which users are granted permission to access data or perform operations. After a user is authenticated, the user's level of authorization determines what operations the owner can perform. A user's authorization is based on the user's role.

Roles

A role defines which applications and what parts of each application users can access and what those users or groups can do with the applications. For example, in a personnel application, all employees might be able to see phone numbers and email addresses, but only managers have access to salary information. This application would define at least two roles: employee and manager. Only users in the manager role are allowed to view salary information.

A role is different from a group in that a role defines a function in an application, while a group is a set of users who are related in some way. For example, the personnel application specify groups such as full-time, part-time, and on-leave. Users in these groups are all employees (the employee role). In addition, each user has its own designation that defines an additional level of employment.

Roles are defined in the deployment descriptor for the application. The application developer or deployer maps roles to one or more groups in the deployment descriptor for each application. When the application is being packaged and deployed, the application specifies mappings between users, groups, and roles, as illustrated in the following figure.

Figure 1-1 Role Mapping

Description of "Figure 1-1 Role Mapping"

// classes in lib get all permissions by default
grant codeBase "file:${com.sun.aas.installRoot}/lib/-" {
    permission java.security.AllPermission;
};

// Core server classes get all permissions by default
grant codeBase "file:${com.sun.aas.installRoot}/modules/-" {
    permission java.security.AllPermission;
};

// Felix classes get all permissions by default
grant codeBase "file:${com.sun.aas.installRoot}/osgi/felix/bin/-" {
    permission java.security.AllPermission;
};

// iMQ classes get all permissions by default
grant codeBase "file:${com.sun.aas.imqLib}/-" {
    permission java.security.AllPermission;
};

// Derby driver classes get all permissions by default
grant codeBase "file:${com.sun.aas.derbyRoot}/lib/-" {
    permission java.security.AllPermission;
}; 


// permission for JDK's tools.jar to enable webservice annotation processing
// at runtime by wsgen tool: 
//       permission java.lang.RuntimePermission "createClassLoader";
//
// permission for JDK's tools.jar to sign JARs at runtime for 
// Java Web Start support:
//       permissions java.security.AllPermission;
// on the advice of the JDK tools folks.  Should be refined later.
grant codeBase "file:${com.sun.aas.javaRoot}/lib/tools.jar" {
    permission java.security.AllPermission;
};

//Loading MBeans from anywhere, to take care of side effects of 6235678.
grant {
    permission javax.management.MBeanTrustPermission "register" ;
};
//Loading MBeans from anywhere, to take care of side effects of 6235678.


// Basic set of required permissions granted to all remaining code
// The permission FilePermission "<<ALL FILES>>", "read,write"
// allows all applications to read and write any file in the filesystem.
// It should be changed based on real deployment needs. If you know your
// applications just need to read/write a few directories consider removing
// this permission and adding grants indicating those specific directories.
// against the codebase of your application(s).
grant {
    //Workaround for bugs #6484935, 6513799
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission com.sun.corba.ee.impl.presentation.rmi.DynamicAccessPermission "access";
    permission java.util.PropertyPermission "*", "read,write";

    permission java.lang.RuntimePermission  "loadLibrary.*";
    permission java.lang.RuntimePermission  "queuePrintJob";
    permission java.net.SocketPermission    "*", "connect";
    permission java.io.FilePermission       "<<ALL FILES>>", "read,write";

        // work-around for pointbase bug 4864405      
        permission java.io.FilePermission 
          "${com.sun.aas.instanceRoot}${/}lib${/}databases${/}-", 
           "delete";
        permission java.io.FilePermission "${java.io.tmpdir}${/}-", "delete";

    permission java.util.PropertyPermission "*", "read";

    permission java.lang.RuntimePermission    "modifyThreadGroup";
    permission java.lang.RuntimePermission    "getClassLoader";
    permission java.lang.RuntimePermission    "setContextClassLoader";
        permission javax.management.MBeanPermission 
               "[com.sun.messaging.jms.*:*]", "*"; 
};


// Following grant block is only required by Connectors. If Connectors
// are not in use the recommendation is to remove this grant.
grant {
        permission javax.security.auth.PrivateCredentialPermission 
               "javax.resource.spi.security.PasswordCredential * \"*\"","read";
};

// Following grant block is only required for Reflection. If Reflection
// is not in use the recommendation is to remove this section.
grant {
    permission java.lang.RuntimePermission "accessDeclaredMembers";
};

// Permissions to invoke CORBA objects in server
grant {
    permission com.sun.enterprise.security.CORBAObjectPermission "*", "*";
};

permission java.util.PropertyPermission "*", "read,write";
 permission java.io.FilePermission       "<<ALL FILES\>>", "read,write";

grant codeBase "file:${com.sun.aas.instanceRoot}/applications/MyApp/-"
{
permission java.io.FilePermission "file:${com.sun.aas.instanceRoot}
/applications/MyApp/-", "read,write";
}

Auditing

Auditing is the means used to capture security-related events for the purpose of evaluating the effectiveness of security measures. GlassFish Server uses audit modules to capture audit trails of all authentication and authorization decisions. GlassFish Server provides a default audit module, as well as the ability to plug in custom audit modules. The scope of the audit module is the entire server, which means that all the applications on the server will use the same audit module.

For administration instructions, see Administering Audit Modules.

Firewalls

A firewall controls the flow of data between two or more networks, and manages the links between the networks. A firewall can consist of both hardware and software elements. The following guidelines pertain primarily to GlassFish Server:

• In general, firewalls should be configured so that clients can access the necessary TCP/IP ports.

  For example, if the HTTP listener is operating on port 8080, configure the firewall to allow HTTP requests on port 8080 only. Likewise, if HTTPS requests are set up for port 8081, you must configure the firewalls to allow HTTPS requests on port 8081.

• If direct Remote Method Invocations over Internet Inter-ORB Protocol (RMI-IIOP) access from the Internet to EJB modules is required, open the RMI-IIOP listener port as well.

  Note:

  Opening the RMI-IIOP listener port is strongly discouraged because it creates security risks.

• In double firewall architecture, you must configure the outer firewall to allow for HTTP and HTTPS transactions. You must configure the inner firewall to allow the HTTP server plug-in to communicate with GlassFish Server behind the firewall.

Certificates and SSL

The following topics are addressed here:

• Certificates

• Certificate Chains

• Certificate Files

• Secure Sockets Layer

• Custom Authentication of Client Certificate in SSL Mutual Authentication

For administration instructions, see Administering JSSE Certificates.

/**
 *
 * @author nasradu8
 */
public class CertificateLM extends AppservCertificateLoginModule {

    @Override
    protected void authenticateUser() throws LoginException {
        // Get the distinguished name from the X500Principal.
        String dname = getX500Principal().getName();
        StringTokenizer st = new StringTokenizer(dname, "B \t\n\r\f,");
        while (st.hasMoreTokens()) {
            String next = st.nextToken();
            // Set the appname:OU as the group.
            // At this point, one has the application name and the DN of
            // the certificate. A suitable login decision can be made here.
            if (next.startsWith("OU=")) {
            commitUserAuthentication(new String[]{getAppName() 
+ ":" + next.substring(3)});
                return;
            }
        }
        throw new LoginException("No OU found.");
    }
}

Tools for Managing System Security

GlassFish Server provides the following tools for managing system security:

Administration Console

The Administration Console is a browser-based utility used to configure security for the entire server. Tasks include managing certificates, users, groups, and realms, and performing other system-wide security tasks. For a general introduction to the Administration Console, see "Administration Console" in Oracle GlassFish Server Administration Guide.

The asadmin utility

The asadmin command-line utility performs many of the same tasks as the Administration Console. You might be able to do some things with the asadmin utility that you cannot do with the Administration Console. For a general introduction to asadmin, see "asadmin Utility" in Oracle GlassFish Server Administration Guide.

The keytool utility

The keytool Java Platform, Standard Edition (Java SE) command-line utility is used for managing digital certificates and key pairs. For more information, see Administering JSSE Certificates.

The policytool utility

The policytool Java SE graphical utility is used for managing system-wide Java security policies. As an administrator, you rarely use policytool.

For more information about using keytool, policytool, and other Java security tools, see Summary of Tools for Java Platform Security.

To Change the Master Password

The master password gives access to the keystore used with the domain. This password is not tied to a UNIX user. You should treat this overall shared password as sensitive data. GlassFish Server never uses it for authentication and never transmits it over the network.

You can choose to type the password manually when required, or to obscure the password in a password file. If there is no password file, you are prompted for the master password. If there is a password file, but you want to change access to require prompting, remove the file. The default master password is changeit.

When changing the master password, it has to be changed on all nodes as well as on the DAS. The master password on nodes is only stored once in the node, for all instances that are on that node.

Use the change-master-password subcommand in local mode to modify the master password.

When the master password is saved, it is saved in the master-password file.

Before You Begin

This subcommand will not work unless the domain is stopped.

1. Stop the domain whose password you are changing.

   See "To Stop a Domain" in Oracle GlassFish Server Administration Guide.

2. Change the master password for the domain by using the change-master-password subcommand.

   You are prompted for the old and new passwords. All dependent items are re-encrypted.

3. Start the domain.

   See "To Start a Domain" in Oracle GlassFish Server Administration Guide.

asadmin> change-master-password domain44ps

Please enter the new master password>
Please enter the new master password again>

Please enter the master password>
Please enter the new master password>
Please enter the new master password again>

Master password changed for domain44ps

See Also

You can also view the full syntax and options of the subcommand by typing asadmin --help change-master-password at the command line.

Additional Considerations for the start-instance and start-cluster Subcommands

If you change the master password for DAS, the start-domain and start-local-instance subcommands allow you to provide it during domain or instance startup in one of three ways:

• Via the master-password file

• By entering it interactively

• Via the asadmin passwordfile

The start-instance and start-cluster subcommands are more problematic. If you create a domain with a master password other than the default, an associated remote instance or cluster must have access to the master password in order to start. However, for security reasons GlassFish Server never transmits the master password or the master password file over the network.

Consider the following scenario:

1. Change the master password on the DAS and save it with --savemasterpassword.

2. Create an instance on another host using the subcommand create-instance. GlassFish Server copies the keystore and truststore from the DAS to the instance, but it does not copy the master password file.

3. Try to start the instance using the start-instance subcommand. An error results.

The start-instance command is looking for the file master-password in the node directory on the instance machine, and it is not there by default. Therefore, the subcommand fails.

You can use the change-master-password subcommand to make sure the correct password is used in this password file, as described in Using start-instance and start-cluster With a Password File.

Using start-instance and start-cluster With a Password File

Assume that you have changed the master password on the DAS and you want to make the same change for all instances.

The start-instance andstart-cluster subcommands automatically use the master password file if it exists in the instance filesystem. You can use the change-master-password subcommand to make sure the password file exists and that the correct password is used.

1. From the DAS, create a domain and set the master password.

   asadmin> create-domain --savemasterpassword true domain-name

2. Start the domain.

   asadmin>start-domain domain-name

3. Create a node that is enabled for communication over secure shell (SSH).

   asadmin> create-node-ssh --nodehost host-name --installdir/some-dir node-name

4. Create an instance on the node.

   asadmin> create-instance --node node-name instance-name

5. Before you start the instance, on the instance machine run change-master-password with the ---savemasterpassword option to create a file called master-password in the agents directory to access the keystores. (The start-instance subcommand is looking for a file called master-password in the agents directory to access the stores.)

   asadmin> change-master-password --savemasterpassword true --nodedir /some-dir node-name

   You are prompted to enter the current and new master password:

   Enter the current master password>

   Enter the new master password>

   Enter the new master password again>

   Command change-master-password executed successfully.

   Remember that when you created the domain you specified a new master password. This master password was then used to encrypt the keystore and truststore for the DAS, and these stores were copied to the instance as a result of the create-instance subcommand.

   Therefore, enter the master password you set when you created the domain as both the current master password and again as the new master password. You enter it as the new master password because you do not want to change the master password for the instance and make it out of sync with the DAS.

6. Run start-instance from the DAS.

   asadmin> start-instance instance-name

   The master password file is associated with the node and not with an instance. After the master password file exists in the node directory on the instance machine, additional instances can be created, started and stopped from the DAS.

To Change an Administration Password

Use the change-admin-password subcommand in remote mode to change an administration password. The default administration user is admin. You are prompted for the old and new admin passwords, with confirmation. The passwords are not echoed to the display.

Encrypting the admin password is strongly encouraged.

1. Change the admin password by using the change-admin-password subcommand.

2. Enter the old and new admin passwords when prompted.

3. Restart GlassFish Server.

   See "To Restart a Domain" in Oracle GlassFish Server Administration Guide.

asadmin> change-admin-password --username anonymous

Enter admin password>adminadmin
Enter new admin password>newadmin
Enter new admin password again>newadmin

Command change-admin-password executed successfully.

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help change-admin-password at the command line.

To Set a Password From a File

Instead of typing the password at the command line, you can access the password for a command from a file such as passwords.txt. The --passwordfile option of the asadmin utility takes the name of the file that contains the passwords. The entry for a password in the file must have the AS_ADMIN_ prefix followed by the password name in uppercase letters.

For a list of the types of passwords that can be specified, see the asadmin(1M) help page.

AS_ADMIN_MASTERPASSWORD
AS_ADMIN_USERPASSWORD
AS_ADMIN_ALIASPASSWORD

1. Edit the password file.

   For example, to specify the password for the domain administration server (DAS), add an entry similar to the following to the password file, where adminadmin is the administrator password:

   AS_ADMIN_PASSWORD=adminadmin 
   

2. Save the password file.

   You can now specify the password file in an asadmin subcommand. In this example, passwords.txt is the file that contains the password:

   asadmin>delete-jdbc-resource --user admin --passwordfile passwords.txt jdbc/DerbyPool
   

Troubleshooting

If AS_ADMIN_PASSWORD has been exported to the global environment, specifying the --passwordfile option will produce a warning about using the --passwordfile option. To prevent this warning situation from happening, unset AS_ADMIN_PASSWORD.

Administering Password Aliases

A password alias is used to indirectly access a password so that the password itself does not appear in cleartext in the domain's domain.xml configuration file.

Storing passwords in cleartext format in system configuration files is common in many open source projects. In addition to GlassFish Server, Apache Tomcat, Maven, and Subversion, among others, store and pass passwords in cleartext format. However, storing and passing passwords in cleartext can be a security risk, and may violate some corporate security policies. In such cases, you can use password aliases.

The following topics are addressed here:

• To Create a Password Alias

• To List Password Aliases

• To Delete a Password Alias

• To Update a Password Alias

asadmin set --user admin server.jms-service.jms-host.default_JMS_host.
admin-password='${ALIAS=jms-password}'

asadmin> create-password-alias --user admin jms-password

Please enter the alias password>secret-password
Please enter the alias password again>secret-password
Command create-password-alias executed successfully.

asadmin> list-password aliases
jmspassword-alias
Command list-password-aliases executed successfully

asadmin> delete-password-alias jmspassword-alias
Command list-password-aliases executed successfully

asadmin> update-password-alias jsmpassword-alias

Please enter the alias password>new-secret-password
Please enter the alias password again>new-secret-password
Command update-password-alias executed successfully

To Create an Audit Module

Use the create-audit-module subcommand in remote mode to create an audit module for the add-on component that implements the audit capabilities.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. Create an audit module by using the create-audit-module subcommand.

   Information about properties for this subcommand is included in this help page.

asadmin> create-audit-module 
--classname com.sun.appserv.auditmodule --property defaultuser=
admin:Password=admin sampleAuditModule
Command create-audit-module executed successfully.

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help create-audit-module at the command line.

To List Audit Modules

Use the list-audit-modules subcommand in remote mode to list the audit modules on one of the following targets:

• Server instance, server (the default)

• Specified server instance

• Specified configuration

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. List the audit modules by using the list-audit-modules subcommand.

asadmin> list-audit-modules
audit-module : default
audit-module : sampleAuditModule
Command list-audit-modules executed successfully.

See Also

You can also view the full syntax and options of the subcommand by typing asadmin help list-audit-modules at the command line.

To Delete an Audit Module

Use the delete-audit-module subcommand in remote mode to delete an existing audit module.

1. Ensure that the server is running.

   Remote subcommands require a running server.

2. List the audit modules by using the list-audit-modules subcommand.

3. Delete an audit module by using the delete-audit-module subcommand.

asadmin> delete-audit-module sampleAuditModule
Command delete-audit-module executed successfully.

To Generate a Certificate by Using keytool

By default, the keytool utility creates a keystore file in the directory where the utility is run.

Before You Begin

To run the keytool utility, your shell environment must be configured so that the Java SE /bin directory is in the path, otherwise the full path to the utility must be present on the command line.

1. Change to the directory that contains the keystore and truststore files.

   Always generate the certificate in the directory containing the keystore and truststore files. The default is domain-dir/config.

2. Generate the certificate in the keystore file, keystore.jks, using the following command format:

   keytool -genkey -alias keyAlias-keyalg RSA
    -keypass changeit
    -storepass changeit
   keystore keystore.jks
   

   Use any unique name as your keyAlias. If you have changed the keystore or private key password from the default (changeit), substitute the new password for changeit. The default key password alias is s1as.

   A prompt appears that asks for your name, organization, and other information.

3. Export the generated certificate to the server.cer file (or client.cer if you prefer), using the following command format:

   keytool -export -alias keyAlias-storepass changeit
    -file server.cer
    -keystore keystore.jks
   

4. If a certificate signed by a certificate authority is required, see To Sign a Certificate by Using keytool.

5. Create the cacerts.jks truststore file and add the certificate to the truststore, using the following command format:

   keytool -import -v -trustcacerts
   -alias keyAlias
    -file server.cer
   -keystore cacerts.jks
    -keypass changeit
   

   If you have changed the keystore or private key password from the default (changeit), substitute the new password.

   Information about the certificate is displayed and a prompt appears asking if you want to trust the certificate.

6. Type yes, then press Enter.

   Information similar to the following is displayed:

   Certificate was added to keystore
   [Saving cacerts.jks]
   

7. To apply your changes, restart GlassFish Server. See "To Restart a Domain" in Oracle GlassFish Server Administration Guide.

keytool -genkey -noprompt -trustcacerts -keyalg RSA -alias ${cert.alias} 
-dname ${dn.name} -keypass ${key.pass} -keystore ${keystore.file} 
-storepass ${keystore.pass}

keytool -genkey -noprompt -trustcacerts -alias ${cert.alias} -dname 
${dn.name} -keypass ${key.pass} -keystore ${keystore.file} -storepass 
${keystore.pass}

keytool -list -v -keystore ${keystore.file} -storepass ${keystore.pass}

keytool -list -v -alias ${cert.alias} -keystore ${keystore.file} 
-storepass ${keystore.pass}

See Also

For more information about keytool, see the keytool reference page.

To Sign a Certificate by Using keytool

After creating a certificate, the owner must sign the certificate to prevent forgery. E-commerce sites, or those for which authentication of identity is important, can purchase a certificate from a well-known Certificate Authority (CA).

1. Delete the default self-signed certificate:

   keytool -delete -alias s1as -keystore keystore.jks -storepass <store_passwd>
   

   where <store_passwd> is the password for the keystore. For example, "mypass". Note that s1as is the default alias of the GlassFish Server keystore.

2. Generate a new key pair for the application server:

   keytool -genkeypair -keyalg <key_alg> -keystore keystore.jks 
   -validity <val_days> -alias s1as 
   

   where <key_alg> is the algorithm to be used for generating the key pair, for example RSA, and <val_days> is the number of days that the certificate should be considered valid. For example, 365.

   In addition to generating a key pair, the command wraps the public key into a self-signed certificate and stores the certificate and the private key in a new keystore entry identified by the alias.

   For HTTPS hostname verification, it is important to ensure that the name of the certificate (CN) matches the fully-qualified hostname of your site (fully-qualified domain name). If the names do not match, clients connecting to the server will see a security alert stating that the name of the certificate does not match the name of the site.

3. Generate a Certificate Signing Request (CSR):

   keytool -certreq -alias s1as -file <certreq_file> -keystore keystore.jks 
   -storepass <store_passwd>
   

   where <certreq_file> is the file in which the CSR is stored (for example, s1as.csr) and <store_passwd> is the password for the keystore. For example, changeit.

4. Submit the CSR to a Certificate Authority such as VeriSign (at http://www.verisign.com/ssl/buy-ssl-certificates/index.html). In response, you should receive a signed server certificate. Make sure to import into your browser the CA certificate of the CA (if not already present) and any intermediate certificates indicated by the CA in the reply.

5. Store the signed server certificate from the CA, including the markers -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, into a file such as s1as.cert. Download the CA certificate and any intermediate CA certificates and store them in local files.

6. Import the CA certificate (if not already present) and any intermediate CA certificates (if not already present) indicated by the CA into the truststore cacerts.jks:

   keytool -import -v -trustcacerts -alias <CA-Name> -file ca.cert 
    -keystore cacerts.jks -storepass <store_passwd>
   

7. Replace the original self-signed certificate with the certificate you obtained from the CA, as stored in a file such as s1as.cert:

   keytool -import -v -trustcacerts -alias s1as -file s1as.cert
      -keystore keystore.jks -storepass <store_passwd>
   

   When you import the certificate using the same original aliass1as, keytool treats it as a command to replace the original certificate with the certificate obtained as a reply to a CSR.

   After running the command, you should see that the certificate s1as in the keystore is no longer the original self-signed certificate, but is now the response certificate from the CA.

   Consider the following example that compares an original s1as certificate with a new s1as certificate obtained from VeriSign:

   Original s1as (self-signed):
   
   Owner: CN=FQDN, OU=Sun Java System Application Server, O=Sun
   Microsystems, L=Santa Clara, ST=California, C=US
   Issuer: CN=KUMAR, OU=Sun Java System Application Server, O=Su
   n Microsystems, L=Santa Clara, ST=California, C=US
   Serial number: 472acd34
   Valid from: Fri Nov 02 12:39:40 GMT+05:30 2007 until: Mon Oct
   30 12:39:40 GMT+05:30 2017
   
   New s1as (contains signed cert from CA):
   
   Owner: CN=FQDN, OU=Terms of use at www.verisign.com/cps/test
   ca (c)05, OU=Sun Java System Application Server, O=Sun Micros
   ystems, L=Santa Clara, ST=California, C=US
   Issuer: CN=VeriSign Trial Secure Server Test CA, OU=Terms of
   use at https://www.verisign.com/cps/testca (c)05, OU="For Test
   Purposes Only. No assurances.", O="VeriSign, Inc.", C=US
   Serial number: 1375de18b223508c2cb0123059d5c440
   Valid from: Sun Nov 11 05:30:00 GMT+05:30 2007 until: Mon Nov
   26 05:29:59 GMT+05:30 2007
   

8. To apply your changes, restart GlassFish Server.

   See "To Restart a Domain" in Oracle GlassFish Server Administration Guide.

keytool -import -noprompt -trustcacerts -alias ${cert.alias} -file 
${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass}

keytool -export -noprompt -alias ${cert.alias} -file ${cert.file} 
-keystore ${keystore.file} -storepass ${keystore.pass}

keytool -export -noprompt -rfc -alias ${cert.alias} -file 
${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass}

See Also

For more information about keytool, see the keytool reference page.

To Delete a Certificate by Using keytool

Use the keytool delete command to delete an existing certificate.

Delete a certificate using the following command format:

keytool -delete
 -alias keyAlias
 -keystore keystore-name
 -storepass password

keytool -delete -noprompt -alias ${cert.alias} -keystore ${keystore.file} 
-storepass ${keystore.pass}

See Also

For more information about keytool, see the keytool reference page.

Administering JACC Providers From the Administration Console

To use the Administration Console to administer JACC providers, perform the following steps:

1. Select Configurations and expand the entry.

2. Select the server configuration for which you want to administer JACC providers and expand the entry.

3. Select Security and expand the entry.

4. Select JACC Providers. The JACC Providers page is displayed. The existing JACC providers are shown on this page.

   
   Description of the illustration jacc-providers.png
   
   

5. To create a new provider, click New.

   Enter the Name, Policy Configuration (the class that implements the policy configuration factory) and the Policy Provider (the class that implements the policy factory) for the new JACC provider. You can also enter optional properties (name/value) for the provider.

6. To delete an existing JACC provider, select that provider and click Delete.

Administering JACC Providers from the Command Line

To use the command line to administer JACC providers, perform the following steps:

1. To create a JACC provider, use the create-jacc-provider subcommand. The following example shows how to create a JACC provider named testJACC on the default server target.

   asadmin> create-jacc-provider
          --policyproviderclass com.sun.enterprise.security.provider.PolicyWrapper
          --policyconfigfactoryclass com.sun.enterprise.security.provider.PolicyCon
   figurationFactoryImpl
          testJACC
   

2. To delete a JACC provider, use the create-jacc-provider subcommand. The following example shows how to delete a JACC provider named testJACC from the default domain:

   asadmin> delete-jacc-provider testJACC
   

3. To list the available providers, use the list-jacc-providers subcommand. The following example shows how to list JACC providers for the default domain:

   asadmin> list-jacc-providers
   default
   simple
   Command list-jacc-providers executed successfully.