26 Configuring Security for Portlet Producers

Configure WebCenter Portal to handle security for WSRP and JPDK portlet producers.

Permissions: To perform the tasks in this chapter, you must be granted the WebLogic Server Admin role through the Oracle WebLogic Server Administration Console. Users with the Monitor or Operator roles can view security information but cannot make changes.

See also Understanding Administrative Operations, Roles, and Tools.

Topics:

• Securing a WSRP Producer

• Securing a PDK-Java Producer

Parent topic: Administering Security

Securing a WSRP Producer

The following sections describe how to secure access to JSR-168 standards-based WSRP portlets from WebCenter Portal:

• Deploying the Producer

• Attaching a Policy to the Producer Endpoint

• Setting Up the Keystores

Deploying the Producer

Before you configure the producer for WS-Security, you must first deploy your standards-compliant portlet producer to an Oracle WebLogic managed server by performing the steps described in Deploying Portlet Producer Applications.

Attaching a Policy to the Producer Endpoint

This section describes how to attach a security policy to a WSRP producer endpoint. The following policies are supported for WSRP producers:

• Username token with password

  wss10_username_token_with_message_protection_service_policy

  This policy enforces message-level protection (message integrity and confidentiality) and authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard. It uses WS-Security’s Basic 128 suite of asymmetric key technologies (specifically, RSA key mechanism for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption). The keystore is configured through the security configuration. Authentication is enforced using credentials in the WS-Security UsernameToken SOAP header. The user’s Subject is established against the currently configured identity store.

• Username token without password

  wss10_username_id_propagation_with_msg_protection_service_policy

  This policy enforces message level protection (message integrity and confidentiality) and identity propagation for inbound SOAP requests using mechanisms described by the WS-Security 1.0 standard. Message protection is provided using WS-Security’s Basic 128 suite of asymmetric key technologies (specifically, RSA key mechanisms for confidentiality, SHA-1 hashing algorithm for integrity, and AES-128 bit encryption). Identity is set using the user name provided by the UsernameToken WS-Security SOAP header. The Subject is established against the currently configured identity store.

• SAML token

  There are four SAML token policies:

  • WSS 1.0 SAML token Policy:

    wss10_saml_token_service_policy

    This policy authenticates users using credentials provided in SAML tokens in the WS-Security SOAP header. The credentials in the SAML token are authenticated against a SAML login module. This policy can be applied to any SOAP-based endpoint.

  • WSS 1.0 SAML token with message integrity:

    wss10_saml_token_with_message_integrity_service_policy

    This policy provides message-level integrity protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard. It uses WS-Security’s Basic 128 suite of asymmetric key technologies, specifically SHA-1 hashing algorithm for message integrity.

  • WSS 1.0 SAML token with message protection:

    wss10_saml_token_with_message_protection_service_policy

    This policy enforces message-level protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard. It uses WS-Security’s Basic 128 suite of asymmetric key technologies, specifically RSA key mechanisms for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption.

  • WSS 1.1 SAML token with message protection:

    wss11_saml_token_with_message_protection_service_policy

    This policy enforces message-level protection (that is, message integrity and message confidentiality) and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard. Messages are protected using WS-Security’s Basic 128 suite of symmetric key technologies, specifically RSA key mechanisms for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption. The keystore is configured through the security configuration. It extracts the SAML token from the WS-Security binary security token, and uses those credentials to validate users against the configured identity store. This policy can be attached to any SOAP-based endpoint.

  The keystore is configured through the security configuration. It extracts the SAML token from the WS-Security binary security token, and uses those credentials to validate users against the configured identity store.

To attach a policy to a producer endpoint

1. Open Fusion Middleware Control and log into the target domain.

   For information on logging into Fusion Middleware Control, see Starting Enterprise Manager Fusion Middleware Control.

2. In the Navigation pane, expand the Application Deployments node, and click the producer to attach a policy to.

3. From the Application Deployment menu, select Web Services.

   The Web Services Summary page for the producer displays.

4. Open the Web Service Endpoint tab and click the endpoint to which to attach a policy.

   The WSM Policy Subject Configuration page displays ( see Figure 26-1 ).

   Figure 26-1 WSM Policy Subject Configuration

   

   Note: Only the markup service ports should be secured (WSRP_V2_Markup_Service and WSRP_V1_Markup_Service).

   The Web Service Endpoints page for the producer displays.

5. Open the Policies tab to display the currently attached policies for the producer.

6. Click Attach/Detach to add or remove a policy.

   The Attach/Detach Policies page is shown listing the available policies and their descriptions.

7. Under Available Policies, select Category and Security as the policy category to search, and click the Search icon to list the security policies.

8. Select the policies to attach and click Attach. Use the Ctrl key to select multiple policies.

   The policies appear in the list under Attached Policies.

9. When finished adding polices to attach to the producer endpoint, click OK.

Setting Up the Keystores

The steps to create and configure keystores for a WSRP producer depend on the topology of your WebCenter Portal environment, and are covered in the following sections:

• Configuring WS-Security for a Typical Topology

• Configuring WS-Security for Multiple Domains

Refer to these sections for more complete instructions for setting up the keystores, and other WS-Security aspects of configuring WSRP producers.

Securing a PDK-Java Producer

A shared key can be defined for message integrity protection and should be used with SSL. The steps to store a shared key as a password credential are:

• Define a shared key as a password credential in the credential store of the administration server instance. This can be done using either Fusion Middleware Control or WLST.

• Restart the web producer and access the test page. Confirm that the shared key has been picked up correctly by checking the application logs.

Note: Using a shared key provides only message integrity protection. For complete message protection SSL is required. For more information on securing PDK-Java portlets using SSL, see Securing the WebCenter Portal Connection to Portlet Producers with SSL.

Defining a Shared Key as a Password Credential

You can define a shared key as a password credential in the credential store of the administration server instance using either Fusion Middleware Control or WLST commands, as described in the following subsections:

• Defining a Shared Key Using Fusion Middleware ControlFusion Middleware Control

• Defining a Shared Key Using WLST

Defining a Shared Key Using Fusion Middleware ControlFusion Middleware Control

To define a shared key using Fusion Middleware Control:

1. Log into Fusion Middleware Control.

2. In the Navigation pane, expand the WebLogic Domain node and click the target domain (for example, WC_Domain).

3. From the WebLogic Domain menu, select Security, then Credentials.

   The Credentials pane displays.

4. Click Create Map and enter PDK as the Map Name and click OK.

5. Click Create Key and select the map (PDK) you just created.

6. Enter a User Name (this value is not used so it could be anything), a Key in the form pdk.*service_id*.sharedKey (where *service_id* is the name of the producer), and a 10 to 20 hexadecimal digit Password and click OK.

   The new key is displayed in the Credential pane.

Defining a Shared Key Using WLST

You can also define a shared key using WLST as described in the following steps:

1. Start WLST as shown in Running Oracle WebLogic Scripting Tool (WLST) Commands, and connect to the Administration Server instance for the target domain.

2. Connect to the Administration Server for the target domain with the following command:

   connect('user_name','password, 'host_id:port')
   

   Where:

   • user_name is the name of the user account with which to access the Administration Server (for example, weblogic)

   • password is the password with which to access the Administration Server

   • host_id is the host ID of the Administration Server

   • port is the port number of the Administration Server (for example, 7001).

3. Add a shared key credential for a producer to the credential store using the WLST createCred command:

   createCred(map='PDK', key='pdk.service_id.sharedKey.user_name', user='user_name', password='password')
   

   Where:

   • service_id is the name of the producer to create the key for (for example, provider1)

   • user_name is the name of the user. This value is not used so it could be anything.

   • password is a 10 to 20 hexadecimal digit value.

   For example:

   createCred(map='PDK', key='pdk.provider1.sharedKey', user='sharedKey', password='1234567890abc')
   

   Note: After creating a credential, you can use the WLST updateCred command with the same parameters as above to update it.

4. Restart the producer.

   Web producers pick up properties the first time they handle a request (for example, a browser test page request or when they are first registered), so producers should be restarted once a shared key credential has been set up.

Registering an Oracle PDK-Java Producer with a Shared Key

Registering a PDK-Java producer is described in Registering an Oracle PDK-Java Portlet Producer. When you register an Oracle PDK-Java producer with a shared key, you must be sure to also do the following:

• Select the Enable producer session option when registering the producer.

• In the Add Portlet Producer Connection section, enter the password used when creating the credential map as the Shared Key.