| products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 

WebLogic Server Frequently Asked Questions

 Previous Next Contents View as PDF  

FAQs: Security

Q. What is the difference between the Compatibility realm and myrealm? Under what circumstances should I use each of these realms?

A. If you have a 6.x config.xml file and you boot WebLogic Server 8.18.1, the following realms are created:

For more information, see Managing WebLogic Security.

Q. What are the default groups users and everyone used for?

A. The users and everyone groups are convenience groups that allow you to apply global roles and security policies. All WebLogic Server users are members of the everyone group. Only WebLogic Servers who are not the <anonymous> user are members of the users group.

For more information, see Managing WebLogic Security.

Q. Is there still a guest user?

A. The guest user is no longer supported by default in WebLogic Server 8.1. In WebLogic Server 6.x, guest was both the name of a user and the name for anonymous logins. The new user name for an anonymous user is <anonymous>. You can change this username by booting WebLogic Server with the following command line argument:

This argument allows you to make the name of the anonymous user guest for the purpose of backward compatibility.

If you want to have a guest user in WebLogic Server 8.1, create a user with the name guest in the Authentication provider in the default security realm and give the user the password of guest. If your code depends on the guest user, you should consider rewriting it to use the utility methods in

Q. I want to provide additional fields in my Web application for form-based authentication. What application programming interfaces (APIs) should I use?

A. The CallbackHandler implementation in the WebLogic Authentication provider supports only stringified versions of a username and password when using form-based authentication.

If a Web application requires more authentication information, use the interface of the JAAS Callback application programming interface (API) in the code for your Web application. The implementation of the interface needs to use the name of the authentication field as the prompt to the method constructor. For example:

Callback[] callbacks=new Callback[1];
callbacks[1]=new TextInputCallback("TextField");

} catch ( ioe) {
throw new LoginException(ioe.toString());
}catch (UnsupportedCallbackException uce) {
throw new LoginException
("Error:"+uce.getCallback().toString() +
"not available to garner authentication information" +
"from the user");
//"textField1 is not set correctly

When the ServletCallbackHandler gets a TextInputCallback, the callback looks for a field matching the prompt of the TextInputCallback. If there is a match, the callback handler sets the value in the callback. If no match is found, an UnsupportedCallback exception is raised.

Q. I am using the 6.x security realm APIs in my application. How do I upgrade this functionality to the security APIs in WebLogic Server 8.1?

Specifically, I am using the security.getRealm() method and then the getGroup(), getGroups(), and getUser() methods on the returned realm.

A. You can use your 6.x application as is in the WebLogic Server 8.1 environment by using Compatibility security.

The management of WebLogic Server changed in 6.0 away from direct calls on the realm to the use of MBeans. This change was the first step in creating a unified administration model for WebLogic Server. While the Security MBeans introduced in 6.0 mirrored the capabilities defined for the realm, they were not flexible enough to allow security vendors to integrate their products with WebLogic Server. WebLogic Server 8.1 provides a set of Security Service Provider Interfaces (SSPI) and Security SPI MBeans that allow you to write custom security products for WebLogic Server. These MBeans can also be used to replicate functionality in an existing application so that the application can be used in the WebLogic Server 8.1 environment.

If you choose to upgrade your realm, you will need to write an implementation of the MBeans found in the package. These MBeans allow you to implement management methods that are specific to your 6.x realm. For a description of using the MBeans in the package, see Developing Security Providers for WebLogic Server.

The following are some hints that may help you upgrade applications based on security realms to the security architecture available in WebLogic Server 8.1:

Note: The package was deprecated in WebLogic Server 7.0.


Table 18-1 Interface Mapping

Methods in the 6.x package

Corresponding Method in the 8.1
authentication package














GroupMemberLister.listGroupMembers() or SubjectUtils.isUserInGroup()






GroupReader.groupExists(), GroupReader.isMember()


Q. Does WebLogic Server support Diffie-Hellman or DSS/DSA digital certificates?

A. No. The exportable version of WebLogic supports only 512 bit RSA with 40 bit RC4. Additionally, Web browsers do not support these types of certificates, and there are no commercial issuers for DSA certificates.

Q. Can a Weblogic Server deployment have one RSA and one non-RSA certificate?

A. No.

Q. Must we pay RSA licensing costs for non-RSA client code?

A. WebLogic Server has licensed RSA for SSL communications between WebLogic Server and WebLogic clients. When using WebLogic Server, no extra licensing for RSA is necessary, although different rules apply to VARs.

Q. How do I use Netscape security certificates with WebLogic Server?

A. Netscape stores the private and public keys together in a key-pair file which prevents you from separating the public and private keys. Therefore, you must generate another request for a certificate, not using Netscape utilities. You can use the Certificate Request servlet in WebLogic Server to generate a request for a new certificate.

Q. Where does WebLogic Server store private keys?

A. WebLogic Server 8.1 looks for the private key in the configured Keystore provider. Before a private key can be located in the Keystore provider, you need to perform the following configuration steps:

  1. Configure the Keystore provider using the Administration Console.
  2. Load the private key into the configured Keystore provider.
  3. Specify the Server Private Key Alias and Server Passphrase attributes on the SSL protocol tab in the WebLogic Server Administration Console.

If the private key is not found, WebLogic Server looks in the file specified in the Server Key File Name attribute on the SSL tab under the Server node.

For more information, see Managing WebLogic Security.

Q. How do I restrict access to servlets and JSPs?

The Java Servlet API Specification v2.3 allows you to declaratively restrict access to specific Servlets and JSPs using the Web Application Deployment descriptor. Section 13.3.2 of the specification has an example deployment descriptor that uses declarative security. For more information, see Programming WebLogic HTTP Servlets. You can also specify roles for EJBs and Web applications through the Administration Console. For more information, see Managing WebLogic Security.

Q. Can I use RSA encryption algorithms and javax.crypto.* API to build applications?

A. No. WebLogic's RSA license does not permit end-users to use RSA classes directly. You must obtain your own license for the encryption libraries from RSA.

Q. Can I use a JNDI Initial Context to pass the security credentials of a WebLogic Server user?

A. The ability to use JNDI to pass security credentials was deprecated in 6.1 of WebLogic Server. You can still use this method in WebLogic Server 8.1. However, BEA recommends using the Java Authentication and Authorization Service (JAAS) runAs() method rather than JNDI to associate a user with a security context. For more information, see Programming WebLogic Security.

Q. Are WebLogic Server passwords secure?

A. The config.xml file no longer has clear text passwords. In place of clear text passwords, the config.xml file has encrypted passwords. You cannot copy encrypted passwords from one domain to another. Instead, you can edit the config.xml file and replace the existing encrypted passwords with clear text passwords and then copy the file to the new domain. The Administration Console will encrypt the passwords the next time it writes to the file.

Q. Why do I get a Java security permission error when starting and running WebLogic Server?

For example: denied (description of error)

What should I do?

A. The RecordingSecurityManager utility can be used to detect permission problems that occur when starting and running WebLogic Server. The utility outputs permissions that can be added to your Java security policy file to resolve the permission problems that the utility finds. The RecordingSecurityManager utility is available from the following BEA download page.

Q. Why do I get a certificate configuration error when I start the my Weblogic Server?

For example: Alert> <WebLogicServer> <Security> configuration problem with certificate file

A. It is possible that you did not specify a WL_HOME relative file name in your SSL configuration files.

For more information, see Managing WebLogic Security.

Q. Why can't I establish an outbound SSL connection when using the demonstration certificates?

A. When establishing an SSL connection, the subject DN of the digital certificate must match the host name of the server initiating the SSL connection. Otherwise, the SSL connection is dropped. If you use the demonstration certificates, the host names will not match. To avoid this situation, use the following command-line argument when starting WebLogic Server:

This argument disables the Hostname Verifier which compares the subject DNs and host names. This solution is recommended in development environments only. A more secure solution is to obtain a new digital certificate for the server making outbound SSL connections.

Q. Why do I get a configuration error when establishing an SSL connection to WebLogic Server?

For example: <WebLogic Server> <SSLListenThread listening on port 8802> Failed to connect to t3s://localhost:8802.

A problem with the configuration of the SSL protocol will also raise the following exception:

< Write Channel Closed, possible handshaking or trust failure>

A. By default, WebLogic Server contains a Hostname Verifier that compares the subject DNs of digital certificates and host names. When establishing an SSL connection, the subject DN of the digital certificate must match the host name of the server initiating the SSL connection. If you use the demonstration certificates the host names will not match. To avoid this situation, use the following command-line argument when starting WebLogic Server:

This argument disables the Hostname Verifier. This solution is recommended in development environments only. A more secure solution is to obtain a new digital certificate for your WebLogic client.

In WebLogic Server 8.1, WebLogic clients perform a trusted certificate authority check on the digital certificate for WebLogic Server. The client may reject the digital certificate of WebLogic Server if the certificate was not issued by a certificate authority trusted by the client. Previous versions of WebLogic Server did not perform this check.

Q. Why does my servlet return a no certificate message?

A. Unless WebLogic Server is configured to ask a client for its digital certificate during the SSL handshake (referred to as Two-Way SSL), WebLogic Server will not have the digital certificate. You get this error when a WebLogic servlet or JSP tries to perform peer validation on the client. Set the Client Certificate Enforced attribute on the SSL tab under the Server node to configure WebLogic Server to request client certificates.

Q. Why doesn't my Custom security provider show up (that is, it doesn't appear as a Configure a new Security_Provider_Type link) in the Administration Console?

A. Check to make sure the system administrator put the MBean JAR file (MJF) in the lib/mbeantype directory.


Back to Top Previous Next