Skip navigation.

eDocs Home > BEA WebLogic Portal 8.1 Documentation > Using WSRP with WebLogic Portal > Establishing WSRP Security

Using WSRP with WebLogic Portal

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Establishing WSRP Security

The WSRP standard does not enforce any specific security standard at this time; however, it does recommend that you follow security standards such as WS-Security and SAML when implementing WSRP-compliant portlets. The WSRP standard does emphasize using transport-level security standards, such as SSL/TLS, to address the security issues involved in Consumers invoking Producers on behalf of end-users. These security standards only require that a Producer's WSDL declare ports for an HTTPS service entry point. Consumers can only determine that secure transport is supported by parsing the URL for the service entry point access control.

Note: It is a general limitation of J2EE security that security constraints on web application resources are not honored when a portlet uses those resources. This limitation applies to both remote and local portlets. To work around this limitation, it is recommended that you use entitlements on the consumer portal to restrict access to specific content.

This section describes some of the security measures we suggest you follow. It contains information on the following subjects:

 

Access Control

Both Producers and Consumers can control access by using the implemented security measures.

 

Security Recommendations

While the WSRP standard does not specify security requirements, the following recommendations serve as guidelines that will ensure secure implementation of your WSRP-compliant portlets:

 

Setting Security Constraints on Resources

As a basic rule and best practice, administrators should secure all web applications and their resources running in a production environment. Security is especially important when resource URLs (links to files and images on a producer) are used with WSRP. Per the WSRP 1.0 specification, resource URLs are absolute and become part of the final URL, which is visible in the wsrp-url parameter.

When you view portal page's source in a browser, these resource URLs are visible. Because they provide the URL back to the hosting web application on the producer machine, it is important that all resources on the producer are secure. For example, using this information, a user could guess URLs on the producer, such as the WebLogic Server Console, and attempt to access them directly.

Warning: It is the responsibility of the producer's administrator to secure web applications and resources appropriately.

For information on adding security constraints to a WebLogic Server, see URL (Web) and EJB (Enterprise JavaBean) Resources and security-constraint at: 

http://download.oracle.com/docs/cd/E13222_01/wls/docs81/secwlres/types.html#1208206
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/webapp/web_xml.html#1017885

 

Creating a Resource Connection Filter

As discussed in the previous section, the wsrp-url parameter exposes resource URLs on the producer machine.

By default, a consumer allows access to URLs hosted on the machines that host WSRP producers that are currently known to the consumer. Such producers are ones added to the consumer with WebLogic Workshop, the Portal Administration Portal, or WebLogic Portal APIs. If you want to override this default behavior, do the following:

  1. On the consumer, create a class that implements the interface com.bea.wsrp.consumer.resource.ResourceConnectionFilter. This interface includes one method:

    2. public boolean allowedURL(String url);

    Implement this method to return true only for URLs that you want to allow access to through the wsrp-url parameter.

    Place the implementation class file in WEB-INF/lib/classes. For example, WEB-INF/lib/classes/MyResourceProxyServletImpl.class.

  2. Register the class with the ResourceProxyServlet on the consumer. To do this, add an <init-param> element to the ResourceProxyServlet definition in the WEB-INF/web.xml file of the consumer web application. You must set the <param-name> to resourceConnectionFilter, and the <param-value> to the fully qualified classname of your ResourceConnectionFilter implementation class.

    3. Listing 9-1 shows a sample ResourceProxyServlet servlet definition.

Listing 9-1 Configuring ResourceProxyServlet (in WEB-INF/web.xml)

<servlet>
   <servlet-name>ResourceProxyServlet</servlet-name>
   <servlet-class>com.bea.wsrp.consumer.resource.ResourceProxyServlet</servlet-class>
   <init-param>
      <param-name>resourceConnectionFilter</param-name>
      <param-value>myClasses.MyResourceProxyServletImpl</param-value>
   </init-param>
</servlet>

 

Secure WSRP Messages

Securing WSRP messages ensures their confidentiality between just the interested parties. When a portlet's messaging is secure, only parties authorized to handle the contents of that portlet's messages can see those messages. To secure WSRP messages:

Listing 9-2 <service-config> Element Configured for Security

<service-config>
   <registration required="true" secure="true"/>
   <service-description secure="true"/>
   <markup secure="true" rewrite-urls="true" transport="string"/>
   <portlet-management required="true" secure="true"/>
</service-config>

Note: If you make any changes to wsrp-producer-config.xml, you will need to redeploy or bounce the server before the changes become active.

 

Manage User Identity

To manage user identity:

What is Single Sign-on?

Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit that user to access all computers and systems to which access permission has been granted, without having to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore a feature.

How Single Sign-on Works with WSRP

SSO support is meant to propagate user identity from the consumer to the producer. That is, the consumer provides authentication, and the WSRP stack makes sure that the same user identity is established on each producer with which the user is interacting. The best way to see this in action is to monitor the SOAP message log on the producer or consumer side. After login (on the consumer side), you will see an extra SOAP header in each request.

Each web application has a monitor which logs soap messages. The monitor can be viewed by going to http://<machine>:<port>/<webapp>/monitor. For more information on monitoring SOAP messages, please refer to Monitoring Producer/Consumer Message Logs at:

http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/wsrp/monlog.html#998933

The Signed Certificate

Producers authenticate Consumers through the use of client certificates in conjunction with SSL/TLS. Therefore, if you are relying on SSO and allow users to log-in to the Consumer portal, as recommended, the Producer must trust that Consumer. To establish this trust, the Consumer needs a certificate of authentication signed by an approved certificate authority (CA), such as VeriSign, Inc. This section introduces the Java keytool utility that is used to generate a self-signed certificate. Later in this chapter, we use the keytool in a detailed example that includes obtaining and using a signed certificate from a CA.

The Java keytool Utility

When you install WebLogic Platform, part of the installation process installs a Java runtime environment (JRE). Within the JRE you will find a utility call keytool.exe. keytool is a key and certificate management utility with which you can administer your own public/private key pairs and associated certificates to use in self-authentication (where the user authenticates himself/herself to other users/services) or data integrity and authentication services by using digital signatures.

keytool Concepts and Terminology

You should be familiar with the following terms when implementing security for WSRP-compliant portlets:

certificate

Also known as a public-key certificate—a digitally signed statement from one entity (the issuer), saying that the public key (and some other information) of another entity (the subject) has some specific value.

Certificate Authority (CA)

An organization, such as VeriSign, Inc. that will accept a CSR and return to the requestor a certificate or certificate chain.

Certificate chain

A set of certificates used to establish trust back to a common certificate authority. The first certificate in the chain contains the public key corresponding to the private key.

Certificate Signing Request (CSR)

A file that is sent to a certificate authority, who will authenticate the certificate requestor (usually offline) and return to the requestor a certificate or certificate chain, used to replace the existing certificate chain (which initially consists of a self-signed certificate) in the keystore.

key pair

The combination of a public key and private key on the same certificate

keystore

A database of private keys and their associated X.509 certificate chains that are used to authenticate the corresponding public keys. A keystore file has the .jks extension. The keystore is scoped to the domain, so you will find it in the <BEA_HOME>/user_projects/domains/specificDomain folder (where specificDomain is the domain to which the application you want to secure points). WebLogic Platform ships with a default keystore called wsrpKeystore.jks. We strongly recommend that you rename this file for each domain in which you plan to run it. Otherwise, application security will be compromised.

Self-signed certificate

A certificate for which the issuer is the same as the subject (the entity whose public key is being authenticated by the certificate). When -genkey generate a new public/private key pair, it wraps the public key into a self-signed certificate.

keytool Reference

keytool was created by Sun Microsystems. For complete information on this utility, please refer to keytool - Key and Certificate Management Tool at:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html

Secure the /producer Path

By default, the Producer servlet is not protected. In order to restrict access to a Producer, protect the path <webAppPath>/producer at the network or firewall level (where webAppPath is the URL of the web application).

 

Establishing Single Sign-on with Remote Portlets: Example

The following example will show you how to establish SSO from a Consumer to a Producer. In this simple example, you will be able to log in to a remote portlet from a local portlet on a Consumer.

In this example, you will do the following:

  1. Set up an environment (domain, portal application, and portal web applications) in which to run the example.
  2. Create a login portlet and establish SSO with a remote portlet by using the signed certificate supplied with BEA WebLogic Portal 8.1
  3. Modify this out-of-the-box keystore file to prevent successful login to the same remote portlet.
  4. Use the Java keytool utility to create a new keystore (this utility is described in The Java keytool Utility).
  5. Use the keytool utility to request and obtain a signed certificate for that keystore from a certification authority (CA).
  6. Add that signed certificate to both the Consumer (you) and the Producer.
  7. Reestablish SSO with the remote portlet by using the new signed certificate.

Before you attempt this exercise, please read the preceding section, Manage User Identity.

Step 1. Set Up the Environment

To set up the necessary environment for this example, please refer to Step 1: Set Up Your Environment in Establishing Interportlet Communications with Remote Portlets. Follow the instructions in that section explicitly. If you already completed the environment setup described in Step 1: Set Up Your Environment, you do not need to complete this step.

Note: We recommend that you use the same environment from Establishing Interportlet Communications with Remote Portlets to avoid cluttering your <BEA_HOME>/user_projects folder. If you want to complete this exercise in a new domain and/or portal application, be sure to substitute the names you select for those components in the following procedures.

Step 2. Create the Login Portlet and Establish SSO with a Remote Portlet

In this step, you will create a log-in portlet on the Consumer using the BEA-supplied log-in controller page flow and a simple JSP portlet on the Producer. You will then federate the JSP portlet to the Consumer. Next, you will attempt to log in to the remote portlet by using the log-in portlet.

Create the Log-in Page Flow Portlet

  1. Launch WebLogic Workshop and open the application ipcWsrpTest.
  2. Right-click consumerWeb to open the context menu and select New>Page Flow.

    3. The Page Flow Wizard - Page Flow Name dialog box appears (Figure 9-1).

    Figure 9-1 Page Flow Wizard - Page Flow Name Dialog Box

    Page Flow Wizard - Page Flow Name Dialog Box


     
  3. In Page Flow Name, enter login.

    4. Note that Controller Name changes to LoginController.jpf.

  4. Click Next

    5. The Page Flow Wizard Page - Flow Type dialog box appears (Figure 9-2)

    Figure 9-2 Page Flow Wizard - Page Flow Type Dialog Box

    Page Flow Wizard - Page Flow Type Dialog Box


     
  5. Select Page Flow from a java control and, in the java Control list, select User Login.
  6. Click Next.

    7. The Page Flow Wizard - Select Action dialog box appears (Figure 9-3)

    Figure 9-3 Page Flow Wizard - Select Action Dialog Box

    Page Flow Wizard - Select Action Dialog Box


     
  7. Click Select All and then click Create.

    8. The page flow file is created. LoginController.jpf will appear under consumerWeb on the application tree and the page flow schematic will appear in the IDE workspace (Figure 9-4).

    Figure 9-4 LoginController.jpf Page Flow in IDE Workspace

    LoginController.jpf Page Flow in IDE Workspace


     
  8. Click Source View to display the page flow code (Figure 9-5)

    9. Figure 9-5 LoginController.jpf Source

    LoginController.jpf Source


     
  9. In the public Forward login(LoginForm aForm) call, locate the string: 
com.bea.p13n.usermgmt.profile.ProfileWrapper var = myControl.login
  (aForm.username, aForm.password, aForm.request );

and replace it with:

com.bea.p13n.usermgmt.profile.ProfileWrapper var = myControl.login
   (aForm.username, aForm.password, super.getRequest() );

The call should now look like the example in Listing 9-3


 

Listing 9-3 Updated Forward login(LoginForm aForm) Call

 public Forward login(LoginForm aForm)
        throws Exception
    {
        com.bea.p13n.usermgmt.profile.ProfileWrapper var =
        myControl.login(aForm.username, aForm.password, 
           super.getRequest() );
      getRequest().setAttribute("results", var);
        return new Forward("success");
    }
  1. Save the file.

    2. LoginController.jpf will appear under consumerWeb/login in the application tree (/login is created when you save LoginController.jpf; Figure 9-6).

    Figure 9-6 LoginController.jpf Under consumerWeb/login

    LoginController.jpf Under consumerWeb/login


     
  2. Right-click LoginController.jpf in the application tree to open the context menu and select Generate Portlet...

    3. The Portlet Wizard - Portlet Details dialog box appears (Figure 9-7).

    Figure 9-7 Portlet Wizard - Portlet Details Dialog Box for LoginController.jpf

    Portlet Wizard - Portlet Details Dialog Box for LoginController.jpf


     

    Note that LoginController.jpf already appears in the Content URI field.

  3. Click Finish.

    4. The portlet is generated; LoginController.portlet appears under consumerWeb/login in the application tree.

  4. Save all files.

Create a Log-in Portal

In this step, you will create a portal to contain the login portlet you built in Create the Log-in Page Flow Portlet.

  1. Right-click the consumerWeb node of the application tree to open the context menu and select New>Portal.

    2. The New File dialog box appears.

  2. Ensure the Portal is selected in both panes and, in File Name, enter login and then click Create.

    3. login.portal appears under consumerWeb/login in the application tree and the portal layout appears in the WebLogic Workshop workspace (Figure 9-8).

    Figure 9-8 login.portal in WebLogic Workshop Workspace

    login.portal in WebLogic Workshop Workspace


     
  3. Drag LoginController.portlet from the Data Palette onto the left-hand column of the portal layout, as shown in Figure 9-9.

    4. Figure 9-9 LoginController.portlet in Portal Layout

    LoginController.portlet in Portal Layout


     
  4. Save the portal.

Create a Portlet on the Producer

Next, create a JSP file and portlet on the Producer. This is the portlet you will federate to the Consumer portal you created in Create a Log-in Portal and will be the portlet you will attempt to log in to when you test the login portal.

  1. To create the portlet on the Producer, do the following:
  2. Right-click producerWeb and select New>JSP File

    3. The New File dialog box appears.

  3. Ensure that Web User Interface and JSP File are selected in the left and right-hand panes, respectively; in File name, enter cPortlet.jsp and click Create.

    4. cPportlet.jsp appears in the WebLogic Workshop workspace (Figure 9-10).

    Figure 9-10 cPortlet.jsp in Design View

    cPortlet.jsp in Design View


     
  4. Click Source View to display the JSP code for cPortlet.jsp (Figure 9-11).

    5. Figure 9-11 cPortlet in Source View

    cPortlet in Source View


     
  5. Copy the code from Listing 9-4 and replace the existing cPortlet.jsp source code with it.

Listing 9-4 cPortlet.jsp Source

<%
   String username=null;
      if(request.getUserPrincipal() !=null ){
      username=request.getUserPrincipal().getName();
   }
%>
Username = <%=username%>

The WebLogic Workshop workspace will look like the example in Figure 9-12.

Figure 9-12 New cPortlet.jsp Source

New cPortlet.jsp Source


 
  1. Save the file.

    2. cPortlet.jsp appears in the application tree under producerWeb.

  2. Right-click cPortlet.jsp in the application tree to display the context menu and select Generate Portlet...

    3. The Portlet Details dialog box for cPortlet.jsp appears (Figure 9-13).

    Figure 9-13 Portlet Details Dialog Box for cPortlet.jsp

    Portlet Details Dialog Box for cPortlet.jsp


     

    Note that cPortlet.jsp appears in the Content URI dialog box.

  3. Click Finish.

    4. cPortlet.portlet appears under producerWeb in the application tree.

Federate the Producer Portlet to the Consumer

Next, you will surface the JSP portlet you created in Create a Portlet on the Producer to the Consumer. To do so, use this procedure.

Note: Ensure that WebLogic Workshop is running.

  1. If it is not already running, open the Tools menu and select WebLogic Server>Start WebLogic Server.
  2. Right-click consumerWeb and select New>Portlet.

    3. The New File dialog box appears.

  3. Ensure that Portal and Portlet are selected; in File name, enter cPrime and click Create.

    4. The Select Portlet Type dialog box appears.

    Figure 9-14 Select Portlet Type Dialog Box

    Select Portlet Type Dialog Box


     
  4. Select Remote Portlet and click Next.

    5. The Find/Select a Producer dialog box appears (Figure 9-15), with Find Producer selected.

    Figure 9-15 Find/Select a Producer Dialog Box

    Find/Select a Producer Dialog Box


     
  5. In the Find Producer field, enter:
    6. http://localhost:7001/producerWeb/producer?WSDL

    and click Retrieve.

    The dialog box refreshes, showing Producer Details.

  6. Click Register.

    7. The Register dialog box appears.


     


     
  7. In Producer Handle, enter ssoTest and click Register.

    8. The Find/Select Producer dialog box reappears.

  8. Click Next.

    9. The Select Portlet from List dialog box appears (Figure 9-16).

    Figure 9-16 Select Portlet from List Dialog Box

    Select Portlet from List Dialog Box


     
  9. From the list, select cPortlet and click Next.

    10. The Proxy Portlet Details dialog box appears.

  10. Click Finish.

    11. cPrime.portlet will appear under consumerWeb on the application tree and the portlet layout will appear in the WebLogic Workshop workspace (Figure 9-17).

    Figure 9-17 cPrime Portlet Layout

    cPrime Portlet Layout


     
  11. Save the file.

Test the Log-in Portlet

Finally, you need to test the log-in portlet you created in Create the Log-in Page Flow Portlet to ensure that you can log in to a remote portlet. Once that test is successful, you will "break" the application, which will prevent you from logging in to the remote portlet.

Note: Ensure that WebLogic Server is running.

To run this test, do the following:

  1. Double-click login.portal in consumerWeb.

    2. The portal layout appears in the WebLogic Workshop workspace.

  2. Drag cPortlet from the Data Palette into the right-hand placeholder of the portal (Figure 9-18). cPortlet is the name that cPrime.portlet is identified by in the Data Palette. If the Data Palette is not visible, select View>Windows>Data Palette.

    3. Figure 9-18 login.portal with cPortlet Added

    login.portal with cPortlet Added


     
  3. Save the portal.
  4. Open the Portal menu and select Open Current Portal.

    5. After a few moments, the portal will appear in a browser (Figure 9-19).

    Figure 9-19 login.portal Rendered in the Browser

    login.portal Rendered in the Browser


     

Note that cPortlet displays the text Username = null.

  1. In LoginController, click Login.

    2. LoginController refreshes to show log-in fields (Figure 9-20).

    Figure 9-20 Log-in Fields on LoginController.portlet

    Log-in Fields on LoginController.portlet


     

    In both Password and Username, enter weblogic and click Submit.

    The portal refreshes; cPortlet will now display Username = weblogic.

    Figure 9-21 login.portal After Login is Successful

    login.portal After Login is Successful


     
  2. Close the portal.
  3. Stop WebLogic Server.

Summary

In this step, you created all components required to build a portal that will allow you to log in to a portlet that has been federated to that portal from a producer. You then assembled a log-in portal using out-of-the-box resources, rendered that portal in a browser, and logged in to the remote portlet. In the next step, you will "break" this portal.

Step 3: Break the Log-in Portal

In this step, you will rename the keystore file, which will prevent login to the remote portlet on login.portal. Next, you will verify that you cannot log in to the portal by attempting and failing to successfully log in.

Rename the .jks File

To rename the .jks file, do the following:

Note: Ensure that WebLogic Workshop is running.

  1. Open your file system (for example, Windows Explorer) and navigate to and display the contents of:
    2. <BEA_HOME>/user_projects/domains/ipcWsrpTest
  2. In the list of files, locate wsrpKeystore.jks.
  3. Rename wsrpkeystore.jks to wsrpkeystore_old.jks.

Retest the Portal

Now, you will launch the log-in portal and attempt to log in to the remote portlet again. To do so, do the following:

  1. Return to WebLogic Workshop and restart Weblogic Server.

    2. Note: The application ipcWsrpTest should be open.

  2. Under consumerWeb, double-click login.portal to open that portal in WebLogic Workshop (if login.portal is already open when you launched WebLogic Workshop, you can ignore this step).
  3. Open the Portal menu and select Open Current Portal...

    4. The log-in portal appears in a browser.

  4. Click Login.

    5. The Password and Username fields appear.

  5. For both values, enter weblogic and click Submit.
  6. The portal refreshes and cPortlet will read Username = null (that is, it won't change; Figure 9-22). This indicates that the login has failed.

    7. Figure 9-22 login.portal After Failed Login Attempt

    login.portal After Failed Login Attempt


     
  7. Close the portal and stop WebLogic Server.

Step 4: Obtain and Implement a Signed Certificate

In this step, you will use the The Java keytool Utility to create a Self-signed certificate, creating a new keystore in the process. You will then generate a Certificate Signing Request (CSR) and send that CSR to a Certificate Authority (CA) who will return to you a signed certificate that you will use to establish log-in to the remote portlet.

Before You Begin

Before attempting this procedure, please read about The Java keytool Utility. You might also want to review the information included in keytool - Key and Certificate Management Tool at:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html

Generate a New Keystore

To generate a new keystore, use this procedure.

Note: <BEA_HOME> is the directory where you installed WebLogic Platform.

  1. Open a command prompt on your computer and navigate to the <BEA_HOME>\jdk142_05\bin

    2. Note: The keytool utility is scoped to the JVM you are using. If you select another JVM when you configured your implementation of WebLogic Server, for example BEA WebLogic JRockit, you must navigate to and run the following commands from that JVM's directory.

  2. At the command line, create the keystore by entering the -genkey command as shown here:
    3. <BEA_HOME>\jdk142_05\bin>keytool -genkey -keypass testkeypass -keystore <BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.jks -storepass teststorepass -alias testalias

    In this example,:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html

The keytool options are not required. If you choose not to specify them, defaults are used for those that have default values and you will be prompted for any required values.

  1. Follow the prompts required to identify yourself.

    2. If all the information has been entered correctly, the system will respond with a command prompt, such as <BEA_HOME>\jdk142_05\bin>. To verify that the keystore was properly generated, go to your file system and in <BEA_HOME>\user_projects\domains\ipcWsrpDomain\, locate wsrpKeystore.jks

Create the Certificate Signing Request and Import the Signed Certificate

You've now generated a self-signed certificate. Because any certificate is more likely to be trusted by others if it is signed by a Certification Authority (CA), you now need to generate a Certificate Signing Request (CSR) to gain that signature. To create the CSR, do the following:

  1. Go to a command prompt and navigate to <BEA_HOME>\jd142_05\bin (if you are already at this directory, you can ignore this step).
  2. Enter the keytool -certreq command, using the options listed here: 
    3. keytool -certreq -keystore <BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.jks -alias testalias
    The system responds: 
    Enter keystore password:
  3. Enter teststorepass.
    4. The system responds: 
    Enter key password for <mykey>:
  4. Enter testkeypass.

    5. The system will then generate the CSR and respond with a series of characters representing the CSR; for example:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIICYzCCAiACAQAwXjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNPMRAwDgYDVQQHEwdCb3VsZGVy
MRQwEgYDVQQKEwtCRUEgU3lzdGVtczENMAsGA1UECxMERG9jczELMAkGA1UEAxMCRWQwggG3MIIB
LAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZ
PY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7
g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKB
gQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgW
E7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8G
kotmXoB7VSVkAUw7/s9JKgOBhAACgYBkQ10+BRJVVzMgZTQJiUDYdK+5WOI1EkvXbyZPmvYzAfch
vtR7WKJZMPcbAyq9mtrOXFY7TTEkupXlY4R8c5DdLW0db3YB1eV4gUGQOXn4Y+zE8Z4LxKNhkKLk
yEUQhv0JkyzIReV7sioJahf7AiOwqs2cW1r4dNt4y42duwrdsKAAMAsGByqGSM44BAMFAAMwADAt
AhRARh4iBbioO+Jn3qc/bXOpjr+cqgIVAI78/s8hMqhFkTJxt/qtE3L3F1aP
-----END NEW CERTIFICATE REQUEST-----
  1. Submit the CSR to a certification authority (CA), such as VeriSign, Inc. They will authenticate you, sign a certificate, and then return it to you. This certificate authenticates your public key.

    2. Note: Submitting the .pem file to a CA is beyond the scope of this document. There are many CAs you can use and your company might already have agreements with a specific CA that defines how to submit the CSR. You can also access the website for any CA to review their submission process.

Import the Signed Certificate

A CA will return two certificates: a consumer certificate and the CA certificate. The CA certificate is used to validate the CA's signature on the consumer certificate. Use the keytool -import command to store both the CA-signed certificate and the consumer certificate in the keystore.

Note: Depending upon the CA you use, the CA might return a single file with both certificates imbedded therein. You will have to separate the two using some sort of certificate translation tool, such as the certificate import/export wizards in Internet Explorer. This process is beyond the scope of this document; we recommend you consult your company's security administrator or the CA you used.

Now, you will import both the consumer certificate and the CA certificate into the keystore. Note that when you run the import command, you must use a different alias for each of the certificates, as explained in the following steps.

  1. When you obtain the the signed consumer certificate from the CA, save it in <BEA_HOME>\user_projects\domains\ipcWsrpDomain\ as a .pem file called wsrpKeystore.pem (if the CA returns the certificates as a .pem file, you can skip this step).
  2. Use the keytool -import command to store the consumer certificate in the keystore entry identified by testalias. This will replace the self-signed certificate you created with the -genkey command. Enter the following command:
keytool -import -alias testalias -file <BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.pem -keypass testkeypass -keystore <BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.jks -storepass teststorepass

Note: For more information on using the -import command, please refer to:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html#importCmd

The system responds:

Owner: CN=Your Name, OU=WLP Docs, O=WLP, L=Boulder, ST=Colorado, C=US
Issuer: CN=Thawte Test CA Root, OU=TEST TEST TEST, O=CA Name Certification, ST=FO
R TESTING PURPOSES ONLY, C=ZA
Serial number: 121e
Valid from: Mon Dec 13 11:18:17 MST 2004 until: Mon Jan 03 11:18:17 MST 2005
Certificate fingerprints:
         MD5:  87:29:4B:7F:02:7D:2B:90:EF:FA:7D:02:50:82:7D:FF
         SHA1: 25:08:1E:98:7D:76:31:48:B3:6B:4B:5F:81:24:59:1D:41:CA:A2:DB

And asks:

Trust this certificate? [no]:
  1. Enter yes.

    2. The system responds:

    Certificate was added to keystore
  2. Repeat steps 1 through 3 to import the CA certificate. Save the CA certificate obtained from the CA in a file called <BEA_HOME>\user_projects\domains\ipcTestDomain\CAcert.pem, and use the following values for the .pem filename (-file) and alias (-alias) when you run the keytool -import command. 
    3. -file <BEA_HOME>\user_projects\domains\ipcTestDomain\CAcert.pem
    -alias CAtestalias

Step 5: Update the Consumer mBean

Update the Consumer mBean with the new certificate information by doing the following

  1. In WebLogic Workshop, open the application to which the certificate applies.
  2. Start WebLogic Server by selecting Tools>WebLogic Server>Start WebLogic Server.
  3. Launch the Administration Portal by selecting Portal>Portal Administration

    4. The Administration Portal login page appears

  4. Login to the Administration Portal using weblogic for both the Username and the Password.

    5. The Administration Portal appears.

  5. Under Configure Settings, click Service Administration.

    6. The Configuration Setting page appears (Figure 9-23).

    Figure 9-23 Configuration Settings Page

    Configuration Settings Page


     
  6. In the left pane, click WSRP Consumer Security Service.

    7. The Configuration Settings for: dialog box appears in the right pane (Figure 9-24)

    Figure 9-24 Configuration Settings for: WSRP Consumer Security Service Dialog Box

    Configuration Settings for: WSRP Consumer Security Service Dialog Box


     
  7. Update the necessary fields on this dialog box with information from the keystore. At the minimum, you must update the fields listed in Table 9-1.

    Table 9-1 Updating WSRP Consumer Security Service Configuration Information

    In...

    Enter...

    Consumer Name

    testalias

    Keystore Password

    teststorepass

    Certificate Alias

    testalias

    Certificate Private Key Password

    testkeypass
  8. Click Update.
  9. Restart the server.

Step 6: Update the WSRP Identity Asserter

For a Producer to trust a Consumer, it needs to recognize the Consumer's signed certificate. To ensure this, you need to provide the Producer with the Consumer's public key, which the administrator must add to the Producer's keystore.

To update the WSRP identity asserter, use this procedure:

  1. Launch an instance of WebLogic Server and open the WebLogic Server console by entering in the address field of a browser the URL:
    2. http://localhost:7001/console

    The WebLogic Server Administration Console login page appears.

  2. Log in to the administration console with the user name weblogic and the password weblogic.

    3. WebLogic Server Administration Console appears.

  3. In the left pane, drill down to the WSRP Identity Asserter node (Security>Realms>myRealm>Providers>Authentication>WSRPIndentityAsserter), as shown in Figure 9-25.

    4. Figure 9-25 WSRP Identity Asserter Drill-down

    WSRP Identity Asserter Drill-down


     

    The WSRP Identity Asserter appears in the right pane.

  4. Select the Detail tab to display WSRP identity detail information, as shown in Figure 9-26.

    5. Figure 9-26 WSRP Identity Asserter Detail

    WSRP Identity Asserter Detail


     
  5. Update the information in the WSRP Identity Asserter as described in Table 9-2.

    6. Table 9-2 Updating the WSRP Identity Asserter

    In...

    Enter...

    Key Store Path

    wsrpKeystore.jks

    Key Store Password

    teststorepass

    Confirm Key Store Password

    teststorepass


     
  6. Click Apply.

Note: If any of the yellow icons next to the field labels are blinking, this means that the server must be restarted for the changes to take effect.

Step 7: Test the New Keystore

To test the new keystore, you simply need to try to log in to the remote portlet, as you did in Test the Log-in Portlet. Do the following:

  1. Launch WebLogic Workshop, if it isn't already running.
  2. Stop (if necessary) and restart the server. Select Tools>WebLogic Server>Stop WebLogic Server (if the server is running). Select Tools>WebLogic Server>Start WebLogic Server to start the server.
  3. Once the server starts, go to the consumerWeb node and double-click login.portal (if login.portal is already open, you can ignore this step).
  4. Open the Portal menu and select Open Current Portal.

    5. login.portal renders in the browser.

  5. In the LoginController portlet, click Login.

    6. The portlet refreshes to show the login form.

  6. In both Username and Password, enter weblogic and click submit.

    7. The portal refreshes; cPortlet will now display Username = weblogic.

    Figure 9-27 login.portal After Login is Successful

    login.portal After Login is Successful


     

 

Securing the WebLogic Administrator's Logon Information

A portal domain's portal application's META-INF directory contains the application-config.xml file. In newly created portal domains where the portal application is deployed, this file will contain unencrypted passwords. These passwords actually remain clear text until the portal administration tool's Service Administration page is used to edit and save attributes contained in this config file, or the application using the password accesses it. (And if the portal application is deployed as an ear file, this file cannot be edited and saved.)

Typically, in development, the administrator will use some sort of generic logon information (logon ID and password), such as weblogic/weblogic. For example, Listing 9-5 shows the WSRP element from application-config.xml on initial deployment:

Listing 9-5 Development Phase Clear Text Passwords in application-config.xml

<ConsumerSecurity AdminPassword="weblogic" AdminUserName="weblogic"
   CertAlias="wsrpConsumer" CertPrivateKeyPassword="wsrppassword"
   ConsumerName="wsrpConsumer"
   IdentityAssertionProviderClass="com.bea.wsrp.security.
      DefaultIdentityAssertionProvider"
   Keystore="wsrpKeystore.jks" KeystorePassword="password"
   Name="ConsumerSecurity"/>

After the Service Administration tool is used to edit attributes, the file is saved and automatically passwords are encrypted, as shown in Listing 9-6:

Listing 9-6 .Encrypted Passwords in application-config.xml

<ConsumerSecurity AdminPassword="{3DES}3QrrUeIwN/DxlDI++1ixPw=="
   AdminUserName="weblogicc" CertAlias="wsrpConsumer"
   CertPrivateKeyPassword="{3DES}g7h+VOSAsO9pSlvYSSB2iw=="
   ConsumerName="wsrpConsumer"
   IdentityAssertionProviderClass="com.bea.wsrp.security.
      DefaultIdentityAssertionProvider"
   Keystore="wsrpKeystore.jks" KeystorePassword=
      "{3DES}1OLYVirMWOo+3sEU80cMqw=="
   Name="ConsumerSecurity" />

To ensure the security of passwords throughout the applications lifecycle, you need to use the EncryptDomainString command-line utility to generate an encrypted password and then place that encrypted password into the application-config.xml file while it is still in the development environment. Then you can build the EAR file for the application and deploy it as necessary.

Encrypting Passwords

To encrypt passwords, use this procedure:

  1. Open a command box (DOS shell) and navigate to domain/portal/ (where domain is the domain directory for the application) and run setDomainEnv.cmd.
  2. At the prompt, enter 
    3. java com.bea.p13n.util.EncryptDomainString -targetDomainDir d -inputString s

    where:

    • d is the domain directory to which the portal application is being deployed; for example,
    • s is the input password to encrypt

    For example:

    java com.bea.p13n.util.EncryptDomainString -targetDomainDir \bea\weblogic81b\samples\domain\portal -inputString weblogic

    In this example, the input string weblogic represents administrator's password (adminpassword=weblogic; see Listing 9-7). The command line utility prints a domain specific encrypted string.

  3. Open WebLogic Workshop and the specific portal application.
  4. Select File>Open>File (Figure 9-28).

    5. Figure 9-28 Opening a File in WebLogic Workshop

    Opening a File in WebLogic Workshop


     

    An Open dialog box appears.

  5. Navigate to the application's META-INF folder and open application-config.xml.

Listing 9-7 Clear text Passwords in application-config.xml

<ConsumerSecurity AdminPassword="weblogic" AdminUserName="weblogic"
   CertAlias="wsrpConsumer" CertPrivateKeyPassword="wsrppassword"
   ConsumerName="wsrpConsumer"
   IdentityAssertionProviderClass="com.bea.wsrp.security.
      DefaultIdentityAssertionProvider"
   Keystore="wsrpKeystore.jks" KeystorePassword="password"
   Name="ConsumerSecurity"/>
  1. Replace the clear text passwords with those generated by the EncryptDomainString utility, as shown in Figure 9-8. You will need to run EncryptDomainString for each password in the <ConsumerSecurity>(Listing 9-7) element; for example:
    • AdminPassword="weblogic"
    • CertPrivateKeyPassword="wsrppassword"
    • KeystorePassword="password"

Listing 9-8 Encrypted Passwords Generated by EncryptDomainString Utility 

<ConsumerSecurity AdminPassword="{3DES}3QrrUeIwN/DxlDI++1ixPw=="
   AdminUserName="weblogicc" CertAlias="wsrpConsumer"
   CertPrivateKeyPassword="{3DES}g7h+VOSAsO9pSlvYSSB2iw=="
   ConsumerName="wsrpConsumer"
   IdentityAssertionProviderClass="com.bea.wsrp.security.
      DefaultIdentityAssertionProvider"
   Keystore="wsrpKeystore.jks" KeystorePassword=
      "{3DES}1OLYVirMWOo+3sEU80cMqw=="
   Name="ConsumerSecurity" />

Now you can build the EAR file and deploy the application.

Note on Changing Passwords

If you need to change an administrator's password for any reason, simply changing the password will result in having to rebuild and redeploy the EAR. This is time-consuming and counterproductive. Instead, you can work around this problem by doing the following:

  1. Create a special user in the target system for a WSRP administrator. See Create a New User for more information on creating a user.
  2. Make that user a member of the administrator group. See Add a User to a Group for more information on adding a member to a group.
  3. Insert the new logon information (username and password) into the application's application-config.xml file as described in Encrypting Passwords.

 

Skip navigation bar  Back to Top Previous Next