Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter 11g Release 1 (11.1.1) E12405-10 |
|
![]() Previous |
![]() Next |
This chapter describes how to configure your WebCenter application to handle security for WSRP and JPDK portlet producers.
This chapter includes the following sections:
Audience
The content of this chapter is intended for Fusion Middleware administrators (users granted the 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, Section 1.8, "Understanding Administrative Operations, Roles, and Tools."
The following sections describe how to secure access to JSR-168 standards-based WSRP portlets from WebCenter applications:
For a conceptual overview of securing WSRP producers, see "Securing Identity Propagation Through WSRP Producers with WS-Security" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.
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 Section 21.8, "Deploying Portlet Producer Applications."
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 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 RSA key mechanisms for message confidentiality, and 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
Open Fusion Middleware Control and log into the target domain.
For information on logging into Fusion Middleware Control, see Section 6, "Starting Enterprise Manager Fusion Middleware Control."
In the Navigation pane, expand the Application Deployments node, and click the producer to attach a policy to.
From the Application Deployment menu, select Web Services.
The Web Services Summary page for the producer displays (see Figure 29-1).
Open the Web Service Endpoint tab and click the endpoint to which to attach a policy.
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 (see Figure 29-2).
Open the Policies tab to display the currently attached policies for the producer (see Figure 29-3).
Figure 29-3 Web Services Endpoint Policies Page
Click Attach/Detach to add or remove a policy.
The Attach/Detach Policies page is shown listing the available policies and their descriptions (see Figure 29-4).
Under Available Policies, select Category
and Security
as the policy category to search, and click the Search icon to list the security policies.
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 (see Figure 29-5).
Figure 29-5 Attach Detach Policy Page with Policy Attached
When finished adding polices to attach to the producer endpoint, click OK.
The steps to create and configure keystores for a WSRP producer depend on the topology of your WebCenter environment, and are covered in the following sections:
Section 28.1, "Configuring WS-Security for a Simple Topology"
Section 28.2, "Configuring WS-Security for a Typical Topology"
Section 28.3, "Configuring WS-Security for a Complex Topology"
Please refer to these sections for more complete instructions for setting up the keystores, and other WS-Security aspects of configuring WSRP producers.
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 Section 27.6, "Securing the WebCenter Spaces Connection to Portlet Producers with SSL." |
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.
To define a shared key using Fusion Middleware Control:
Log into Fusion Middleware Control.
For information on logging into Fusion Middleware Control, see Section 6, "Starting Enterprise Manager Fusion Middleware Control."
In the Navigation pane, expand the WebLogic Domain node and click the target domain (for example, wc_domain
).
From the WebLogic Domain menu, select Security > Credentials.
The Credentials pane displays (see Figure 29-6).
Click Create Map and enter PDK
as the Map Name and click OK.
Click Create Key and select the map (PDK
) you just created.
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 (see Figure 29-7).
Figure 29-7 Credentials Pane with New Shared Key
You can also define a shared key using WLST:
Start WLST as described in Section 1.12.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands," and connect to the Administration Server instance for the target domain.
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
).
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, omniPortlet
)
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.omniPortlet.sharedKey', user='sharedKey', password='1234567890abc')
Note: After creating a credential, you can use the WLSTupdateCred command with the same parameters as above to update it. |
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.