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, the following realms are created:
Compatibility realm Allows you to use an existing 6.x security configuration as is in the management environment provided in this release of WebLogic Server. The Realm Adapter providers allows access to existing stores of users, groups, and access control lists (ACLs). myrealm Is the default security realm in this release of WebLogic Server. By default, the WebLogic Security providers are configured in myrealm.
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:
- If you are using the security realm to authenticate users, instead use the JAAS API to authenticate users.
- Table 18-1 lists the mappings between the interfaces in the 6.x of the weblogic.security.acl package to the interfaces in the package...
weblogic.managment.security.authentication
Note: The weblogic.security.acl package is deprecated in this release of WebLogic Server.
6.x weblogic.security.authentication 7.x weblogic.management.security.authentication newUser() UserEditor.createUser() deleteUser() UserRemover.removeUser() newGroup() GroupEditor.createGroup() deleteGroup() GroupRemover.removeGroup() Group.addMember() GroupEditor.addMemberToGroup Group.removeMember() GroupEditor.removeMemberFromGroup() Group.isMember() GroupMemberLister.listGroupMembers() or SubjectUtils.isUserInGroup() Group.members() GroupMemberList.listGroupMembers() userExists() UserReader.isUser() isGroupMember() 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, 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:
- Two-way SSL is configured on the server with the Client Enforced option set.
- The web application is access via https.
- A user corresponding to the CN attribute of the digital certificate for the web application is defined as a user in the default security realm and that the security realm has an Identity Assertion provider configured.
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:
- Obtain the trusted CA certificate.
- Use the der2pem utility to convert the trusted CA certificate to a PEM file.
- Use the keytool utility to create an identity keystore. For example:
keytool -genkey -alias subjectkey -keypass keypassword -keystore nameofkeystore -storepass keystorepassphrase - Use keytool certreq command to create a CSR and submit the CSR to a certificate authority. For example:
keytool -certreq \ -alias subjectkey \ -keypass keypassword keystore nameofkeystore \ -storepass keystorepassphrase \ -file mycertificate.cer - Use the keytool import command to import the PEM file for the trusted CA into the keystore.
- Use the keytool import command with the -trustcacerts option to import the signed digital certificate from the certificate authority into the keystore.
Q. Can I programmatically add users and groups to the WebLogic Authentication provider?
A. Use the createUser() and createGroup() interfaces in the class...
weblogic.management.security.authentication
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.
A.
|
|