WebLogic学习笔记【Node Manager, SSL, Session Tracking】

Node Manager

NM is a standalone Java Tool for managing the availability of all Managed Server running on a machine. It runs as a dedicated process on a machine.

 

In order to control the life cycle of a Managed Server, you must using either the Admin Server or Admin tool through NM.

 

[Version 8.1] A Node Manager does not control the starting and stopping of the Admin Server, so the host machine of Admin Server does not need a NM.

 

Important to note that when NM is used, each Server is started up through NM using Admin Console or JMX application, not the startup scripts of its own.

 

For security consideration, provide 2 ways:

1.      You can instruct the NM to accept connections from certain trust host only.

2.     The NM and the Admin Server communicate through SSL, so both of them must be configured to user SSL.

 

In order to configure a list of trust hosts, you must create a text file with addresses of all Admin Server that allowed to connect the NM. Each line specifies either the IP address or the DNS host name of an Admin Server. By default, NM uses the nodemanager.hosts file located under the WL_HOME/common/nodemanger.

 

You can indicate other files to show trust host list using the following parameter:

 –Dweblogic.nodemanger.trustedHosts=nodemanager.myhosts

 

The best way to modify the default setup is to edit the nodemanger.properties file in the WL_HOME/common/nodemanager directory. A Node Manager uses the same public key infrastructure as WebLogic Server itself, and the default installation uses the DemoIdentity.jks and DemoTrust.jks stores. So, if you just want to get everything going, you can use the default configuration and ignore the rest of setup.

 

The default nodemanger.properties file also provides the syntax for most properties, for example, depending on which keystores you wish to use, the KeyStores property can take any of the following values:

KeyStores=CustomIdentityAndCustomTrust

CustomIdentityKeyStoreFileName=c:/mystores/myIdentityStore.jks

CustomIdentityKeyStorePassPhrase=mykeystorepass

CustomIdentityKeyStoreType=JKS

CustomIdentityAlias=myalias

CustomIdentityPrivateKeyPassPhrase=mypassword

 

Additional configuration properties of NM properties:

1.      JavaHome : specifies the Java home that should be used to start the managed servers. Otherwise, it uses the Java home defined in the Remote Start tab for the Server. If that is not defined, it uses the Java home used to start the Node Manager itself.

2.     WeblogicHome: sets the WebLogic home directory, You also can specify it on a per-server bases on a server’s Remote Start tab.

3.     ReverseDnsEnabled: defines whether reverse DNS may be used to resolve addresses in the trusted host file.

 

After restarting the NM, all of the pass phrases will be encrypted.

Two sets of logs are associated with the Node Manager. Both sets are useful when you need to debug any problems with the Node Manager or when you need to set up a more comprehensive monitoring environment. A subset of the logs is available from the Administration Console.

 

SSL

SSL replies on a public key encryption technology that uses a combination of two keys” a private key that is known only to the owner, and a public key that is embedded in a digital certificate.

 

A Java keystore(JKS) is a standard mechanism for protecting and storing private keys and certificate chains, and for managing the list of certificates of all trusted CAs.

 

There are 3 steps to configuring WebLogic’s SSL:

1.      Establish the server’s identity, by acquiring a private key and digital certificate for the server. You can either use demonstration keys and certificates supplied with WebLogic or generate your own. Alternatively, you can contact a reputed CA for production-quality certificates.

2.     Once you obtain the server’s key and certificate, you need to store them in a key-store before they can be made available to WebLogic.

3.     Finally, you need to fire up the Admin Console and point the server to the appropriate keystore files.

 

Once you configure the required SSL resource for WebLogic, you need to enable the SSL port. By default, SSL is not enabled for WebLogic because it consumes additional CPU resources.

 

You can use WebLogic’s CertGen utility to generate your own demonstration private keys and certificates, signed by CertGenCAB. The CergenCA.der and CertGenCAKey.der files located in the WL_HOME/server/lib directory, represent the digital certificate and the private key. Generate a new private key and certificate:

java util.CerGen keypass certifile keyfile [export] [hostname]

 

If you wish to enable hostname verification, you must generate a separate private key and digital certificate for each server instance that needs to accept SSL connections.

 

Note that if you do not specify a hostname, the CerGen utility will invokes the InetAddress. getLocalHost().getHostName() method to determine the subject’s common name for the certificate. The getHostName() method is somewhat platform dependent.

 

WebLogic groks certificates that are in either the .pem or .der format. The .der format is binary and is used to hold only a single certificate. The .pem format is textual.

 

Because the Certificate Request Generator tool runs as a servlet on WebLogic, you need to first deploy the Web application that packages the servlet. So you can accomplish this by copying the certificate.war file located in the WL_HOME/server/lib directory to the application directory under the domain’s root directory.

 

WebLogic’s ImportPrivateKey utility can be used to import private keys and trusted CA certificates into a keystore. For example:

java utils.ImportPrivateKey myIdentity.jks mykeystorepass/myalias mykeypass mycert.pem mykey.pem

 

Remember you need to specify a password both for the keystore itself and for the key entry within the keystore. The following command shows how to use the keytool utility to load a trusted CA certificate into a keystore:

keytool –import trustcacerts –alias uniquealias  -file c:/server/lib/certgenca.der –keystore myTrust.jks –storepass 12341234

Note that all private key entries in a keystore are accessed via their unique alias.

 

WebLogic8.1 requires you to set up a keystore to hold the server’s identity (private key and public certificate), as well as a keystore to hold all the trusted CA certificates.

 

The WL_HOME/server/lib/cacerts file is an example of a JKS keystore that holds the certificate of all root CAs trusted by WebLogic.

 

A keystore can hold two kinds of entries: a key entry that holds the private key and the associated certificate, or a certificate entry that holds a trusted CA certificate. Each keystore entry may be accessed via a unique, case-insensitive alias.

 

To list all the entries in a keystore, use the following command:

keytool –list –keystore mykeystore.jks

 

To create a new keystore:

keytool –genkey –keystore mykeystore.jks –storepass mykeystorepass

 

To generate a new private key and a matching self-signed certificate:

keytool –alias myalias –genkey –keypass mykeypass –keystore mykeystore.jks –storepass storepass

 

To replace a self-signed certificate with a production-quality certificate or to import a trusted CA certificate into a keystore:

keytool –import –alias myalias –file mycert.pem –keypass mykeypass –keystore mykeystore.jks –storepass mykeystorepass

 

Once you are configured the identity keystore for WebLogic, you still need to associate the server with its private key and digital certificate. By6 default, when you configure WebLogic with the demonstration identity keystore (DemoIdentity.jks), it uses the alias DemoIdentity to access the private key and public certificate.

 

WebLogic performs hostname verification whenever it needs to validate a certificate. A hostname verifier compares the hostname within the certificate’s SubjectDN with the hostname of the other party that is involved in the SSL connection. You can ignore the verify through:

java –Dweblogic.security.SSL.ignoreHostnameVerification=true …

 

If you choose Custom Verifier option, you must specify the fully qualified name of a Java class that implements the weblogic.security.SSL.HostnameVerifier interface.

 

Any Java client that needs to use WebLogic’s SSL implementation must set the following system property:

-Djava.protocol.handler.pkgs=com.certicom.net.ssl

 

Session Tracking

Every J2EE-compliant servlet engine is required to support session tracking using cookies. When an HttpSession is created, a unique ID is associated with it. WebLogic then attempts to store the SessionID by sending a cookies back to the client. Once a cookie is set, the browser will return the cookie on each subsequent request. The server then is able to parse the cookie and return the associated session object when you invoke the getSession() method on the servlet. The servlet sepeification demands that this session-tracking cookie be named JSESSION.

 

Request sent using HTTP and HTTPS use different ports, and some browser treat the same address different port as different locations, If you want to get around this problem, you may add configure the CookieDomain parameter within the session-descriptor element in the weblogic.xml file.

<session-descriptor>

       <session-param>

              <param-name>CookieDomain</param-name>

              <param-name>domainname.com</param-name>

       </session-param>

</session-descriptor>

 

URL rewriting is an alternate mechanism for session tracking. If the client browser does not accept cookies, you must encode the SessionID into all URLs sent back to the client through the response stream. The encodeURL() method on the HttpServletResponse object allows you to encode the SessionID into a URL as a path parameter. The servlet specification demands that the SessionID parameter have the name jsessionid.

 

However, WebLogic detects whether the client supports cookies before encoding URLs. So, the encodeURL() method leaves the URL unchanged if the client does accept cookies. Likewise, when you redirect to another servlet or JSP, you must encode the target URL.

 

Regardless of the settings, WebLogic automatically uses URL rewriting when creating a new session because the server needs more than one visit to ensure that the client supports cookies. Servlets can determine whether the SessionID came from a cookie or a URL by invoking the following method: isRequestedSessionIdFromCookie().

 

You can disable URL rewriting explicitly in session-descriptor element of weblogic.xml file. However, WAP protocol does not support cookies, so URL rewriting must always be used if the web application needs to cater to WAP-enabled browsers.

 

WebLogic permits a single sign-on for multiple web applications. This means that once a client has authenticated itself to the web server, the user has access to all web applications running on the server. The servlet specification provides no mechanism for this, WebLogic Server does.

 

The weblogic.servlet.security.ServletAuthentication class:

logout(HttpServletRequest req) method removes authentication data associated with a client from the web server and all active session the user has logged into. The session associated with the user remains alive.

 

invalidateAll(HttpServletRequest req) method invalidates all the session associated with the user and remove the authentication data. The cookies is invalidated too.

 

killCookie(HttpServletRequest req) method invalidates the current cookie, ensuring that it expires as soon as the response is sent back to the client. The session will remain active until it times out.

 

WebLogic supports 5 different mechanisms for persisting session state information:

1.      Memory (data is stored on a single server in memory)

2.     File

3.     JDBC

4.     Cookie-based

5.     In-memory replication (data is stored in memory on multiple servers)

 

Cookies Persistence limitations: The browser must be configured to accept cookies, and only String value attriubtes may be stored in the session. You may not flush the HTTP response, or else cookie data cannot be written. You may use only basic browser authentication. By default, the session data stored in a cookie is not encrypted in any way.

 

In essence, in-memory replicated persistence requires two things:

1.      Redundancy

2.     Failover

 

Earlier, we saw that WebLogic handles session replication through its implementation of the setAttribute() and removeAttribute() methods on the HttpSession object. No we investigate how the failover is handled transparently.