WebLogic Server Frequently Asked Questions
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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, 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 this release of WebLogic Server. 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:
-Dweblogic.security.anonymousUserName=
newAnonymousUserName
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 this release of WebLogic Server, 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 weblogic.security.WLSPrincipals
.
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 javax.security.auth.TextInputCallback
interface of the JAAS Callback application programming interface (API) in the code for your LoginModule. The implementation of the javax.security.auth.TextInputCallback
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");
try{
callbackHandler.handle(callbacks)
textField1=((TextInputCallback)callbacks[2].getText
} catch (java.io.IOException 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 this release of WebLogic Server?
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 environment by using Compatibility security.
The management of WebLogic Server changed in 6.x 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.x mirrored the capabilities defined for the realm, they were not flexible enough to allow security vendors to integrate their products with WebLogic Server. This release of WebLogic Server 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 environment.
If you choose to upgrade your realm, you will need to write an implementation of the MBeans found in the weblogic.management.security
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 weblogic.management.security
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 this release of WebLogic Server:
weblogic.security.acl
package to the interfaces in the weblogic.managment.security.authentication
package. Note: The weblogic.security.acl
package is deprecated in this release of WebLogic Server.
Corresponding Method in the weblogic.management.security. |
|
---|---|
|
|
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?
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.
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 Securing WebLogic Resources.
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 this release WebLogic Server. 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 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:
-Dweblogic.security.SSL.ignoreHostnameVerification=true
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:
<java.io.IOException: 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:
-Dweblogic.security.SSL.ignoreHostnameVerification=true
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 this release of WebLogic Server, 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 when configuring SSL to requireWebLogic 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.
Q. Why do I get a 401 Unauthorized User error when using CLIENT-CERT in the login-config of my web application?
A. To use a login-config of CLIENT_CERT, ensure the following:
CLIENT_CERT also applies when perimeter authentication is used (meaning digital certificates are coming in via http headers or cookies). In this case, two-way SSL and https are not required.
Q. Why can't I use keytool to import a digital certificate into the identity keystore?
A. When using the keytool utility to create a Certificate Signing Request (CSR), a self-signed digital certificate is placed in the identity keystore. On occasion, a problem will occur when using the keytool commands to replace the self-signed digital certificate in the keystore with a signed digital certificate received from a trusted CA. Use the keytool utility to import the trusted CA certificate into the keystore before importing the signed digital certificate into the keystore. The steps are as follows:
Q. Can I programmatically add users and groups to the WebLogic Authentication provider?
A. Use the createUser()
and createGroup()
interfaces in the weblogic.management.security.authentication
class.
Q. When using the WebLogic Credential Mapping provider, how do you create mappings for anonymous or unauthenticated users?
A. When using the Resource container, special usernames are established for different cases. A mapping called wls_ra_anonymous
is used when there is not authenticated WebLogic user (meaning, the Subject has no users or is null). The Resource container also defines special mappings for mappings created during a Resource Adapter's pool startup (wls_ra_initial
) and when no other configured mapping applies to the given Subject (wls_ra_default
).
Q. How do I configure multiple Authentication providers to work together in a security realm?
A. The Login Modules for all the different types of supported Authentication providers conform to the JAAS specification. If there are two Authentication providers configured in a security realm and you want valid users from either provider to login into the system, set the JAAS Control Flag on each Authentication provider to REQUISITE
.
Q. Can an application use Java security?
A. Yes. An application can use Java security as well as JAAS authorization within itself. The application can use checkPermission()
and all the other Java security calls. The only caveat is there is no guarantee of your identity or code base when the application is being called from the server. At all entry points, your identity and code base must be re-established using AccessController.doPrivileged()
or Subject.DoAs()
.
Q. When using Java security, how do I change the default permissions for an application?
A. In the Java security policy file, there are three "fake" codebases for each of the three component types:
"file:/weblogic/application/defaults/EJB"
for EJBs
"file:/weblogic/application/defaults/Web
for Web applications
"file:/weblogic/application/defaults/Connector
for Connector applications
These codebases contain the defaults for these types of applications. When evaluating these defaults, the string "WEBLOGIC-APPLICATION-ROOT"
will be expanded to the top-level directory when the application was deployed.
Q. How do I protect access to the embedded LDAP server?
A. The acls.prop
file (located in WLHOME/server/lib/acls.prop
) controls access to the embedded LDAP server. You can modify the acls.prop
file to control access to the LDAP server. For more information, see Managing the Embedded LDAP Server.
Q. Does the embedded LDAP server support SSL?
A. Yes. Use the SSL listen port (7002). The WebLogic Server muxer is actually performing all the SSL work so there should be no additional configuration required when using SSL to talk to the embedded LDAP server.
Q. What is the password for the LDAP Admin Account?
A. The password is specified in the Credential field of the EmbeddedLDAP MBean. The password is generated on the first boot of the server and written to the config.xml file. The LDAP Admin account DN is cn=Admin
. Use the WebLogic Server Administration Console to change the password for the LDAP Admin account. For more information, see Configuring the Embedded LDAP Server.
![]() ![]() |
![]() |
![]() |