#### To set listener security properties

This procedure applies to HTTP listener, IIOP listener, and JMX Connector security properties.

1. In the Edit HTTP Listener, Edit IIOP Listener, or Edit JMX Connector page, go to the section labeled SSL.
2. Check the Enabled box in the Security field to enable security for this listener.

   When this option is selected, you must select SSL3 or TLS to specify which type of security is enabled, and you must enter a certificate nickname.

3. Check the Enabled box in the Client Authentication field if clients are to authenticate themselves to the Application Server when using this listener.
4. Enter the keystore alias in the Certificate Nickname field if the Enabled box is checked.

   The keystore alias is a single value that identifies an existing server key pair and certificate. The certificate nickname for the default keystore is `s1as`.

   To find the Certificate Nickname, use `keytool`, as shown in the following example:`keytool -list -v -keystore keystore.jks.`

   If the name has changed in the keystore file, then use that name instead of `keystore.jks`.

   To find the Certificate Nickname, use the `certutil` utility.

5. Select SSL3 and/or TLS if the Enabled box is checked. By default, both SSL3 and TLS are enabled.
6. Enable individual cipher suites, if needed. By default, all supported cipher suites are enabled.

   For information on ciphers, see About Ciphers in Sun Java System Application Server 9.1 Administration Guide.

7. Select Save to save the changes or Load Defaults to cancel.

###### See Also

- To configure security for HTTP listeners

- To configure security for IIOP listeners

- To set listener security properties

- To configure single sign-on (SSO) for a Virtual Server

- To configure security for the Admin Service's JMX connector

##### Configuring Single Sign-On

Single sign-on enables multiple applications to share user sign-on information, rather than requiring each application to have separate user sign-on. Applications using single sign-on authenticate the user one time, and the authentication information is propagated to all other involved applications.

Single sign-on applies to Web applications configured for the same realm and virtual server.

Note - Single sign-on uses an HTTP cookie to transmit a token that associates each request with the saved user identity, so it can be used only when the browser client supports cookies.

Single sign-on operates according to the following rules:

- When a user accesses a protected resource in a Web application, the server requires the user to authenticate himself or herself, using the method defined for that Web application.

- Once authenticated, the Application Server uses the roles associated with the user for authorization decisions across all Web applications on the virtual server, without challenging the user to authenticate to each application individually.

- When the user logs out of one Web application (explicitly, or because of session expiration), the user’s sessions in all Web applications become invalid. Thereafter, the user is required to log in to access a protected resource in any application.