Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter 11g Release 1 (11.1.1) E10148-08 |
|
![]() Previous |
![]() Next |
This chapter describes how to use Oracle ADF Security in your WebCenter application to handle authentication and authorization.
This chapter includes the following sections:
Section 37.1, "Introduction to WebCenter Application Security"
Section 37.7, "Creating a Public Welcome Page for Your Application"
Section 37.8, "Configuring Basic Authentication for Testing Portlet Personalization"
Section 37.9, "Registering Custom Certificates with the Keystore"
Section 37.10, "Overriding Inherited Security on Portlets and Customizable Components"
Section 37.12, "Securing Identity Propagation Through WSRP Producers with WS-Security"
WebCenter applications are dynamic and often involve input from users in the form of customization and personalization, and require a flexible security model. Consequently, the WebCenter security model is based on the ADF security model rather than the more traditional J2EE security model. ADF Security is a framework built upon the Java Authentication and Authorization Service (JAAS) standard. See Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework for a complete introduction to ADF Security.
Oracle WebCenter Framework defines an external application as any application that implements its own authentication process. That is, an application that does not take part in the WebCenter Framework application's single sign-on process. In some cases, the identity management solution may be the same, but the authentication process can be different.
When WebCenter Framework Service interacts with an application that handles its own authentication, you can associate that service with an external application to allow for credential provisioning. Therefore, the use of an external application definition provides a means of accessing content from these independently authenticated applications.
To replicate a single sign-on experience from the end user's perspective, the external application service captures the username and password, and any other credentials for the external application, and supplies it to the WebCenter service requiring it. The WebCenter service then uses this and logs in on behalf of the end user. This username and password combination is securely stored in a credential store configured for the WebLogic domain where the application is deployed.
The user provides login credentials when prompted, and these credentials are mapped to the WebCenter application user and stored in the credential store configured for the domain. The credential store subsequently supplies that information during authentication to the external application. Unless the external application's credentials change, the user supplies the credentials only once as the mapped information is read from the credential store for future requests.
Note: When logging in to an external application, if you clear the Remember My Login Information checkbox, then the credentials provisioned for that user session are lost if there is a failover in a high availability (HA) environment. You are prompted to specify the credentials again if you try to access the external application content in the same user session. |
The external applications that are to be used by the custom WebCenter application can be specified before deployment through a wizard in Oracle JDeveloper, or post-deployment through the application server management interfaces (WebLogic Scripting Tool and Oracle Enterprise Manager). See Oracle Fusion Middleware Administrator's Guide for more information.
This section contains the following:
The WebCenter External Application Service provides a way for mapped user identities to be passed to a web application that requires its own authentication. The support for external applications and credential mapping provided by the WebCenter External Application Service can be used to set up a secured service connection and to provide a seamless automated single sign-on experience for the user.
This is described in the following sections:
To use an external application definition with a secured service (such as a mail server or portlet producer) you associate the named external application with the connection configuration to the required service. For example, the connection to a mail server requires the user to supply a valid username and password to see their mail. Therefore, by associating an external application to the IMAP server connection definition, the user's credentials are automatically passed as part of the mail request as shown in Figure 37-1.
Note: The following WebCenter Services must be configured with external applications for credential mapping support to be available:
For more information about the identity propagation mechanisms used by WebCenter Services, see Section 37.11, "Identity Propagation Mechanisms". |
Figure 37-1 Configure a New Mail Connection Page
When a portlet producer depends on an application that handles its own authentication, you can associate the producer with an external application so that when you register the producer it is a simple task to select the appropriate external definition that maps to the application that is exposed within the portlet, as shown in Figure 37-2.
At run time, the producer uses the information associated with the external application to authenticate the user to the application, and consequently consume its portlets. The producer code is responsible for actually performing the authentication interaction with the external application. The external application support provided with WebCenter Framework simply provides the information needed for authentication to the portlet producer. The use of external applications is supported for both Oracle PDK-Java as well as WSRP producers.
For example, a producer provides a stock portfolio portlet from a portlet-producing application that has its own authentication mechanism. In this case the developer:
Defines the external application. This can be done through the Oracle JDeveloper wizard or through Oracle Enterprise Manager.
Associates the external application with the portlet producer.
With automated single sign-on, the user directly links to the application and is automatically authenticated to the secured web application, as their credentials are retrieved from the credential store. This provides the end user with a seamless single sign-on experience.
Note: Automated login is not supported for:
|
Rather than using a URL directly to the web application, links to the application are proxied through the external application's automated login servlet (adfextapplogin
). If the user is not authenticated to the external application and they have not previously stored their credentials in the credential store, they will be challenged for their password through the credential provisioning page discussed below. If, however, the user has previously defined credentials, they will be returned from the credential store and the user will automatically be logged on to the application.
The proxy URL references the external application in question and redirects to the URL that is specified in the external application definition.
/adfextapplogin?extappid=<extappid>
For example, if you had a WebCenter application in which you defined an external application that represented the myoracle.com Web site (external application identifier is "myoracle"), the proxy URL would look like this:
/adfextapplogin?extappid=myoracle
The link's target
attribute should also be set appropriately. For example, if you use <a href=>
, then set the target
attribute appropriately in addition to specifying the target in the href
. The target attribute specified for the servlet will determine how the Cancel button functions as described below.
/adfextapplogin?extappid=<extappid> [target= _self | _blank]
If you specify target=_blank
the link opens in new window. If you specify target=_self
the link opens in current window. If the target
parameter is not specified the link opens in current window.
This parameter also affects how the Cancel button on the credential provisioning page works. If _blank
is specified, the new window is closed when Cancel is clicked; if _self
is specified (or the target
parameter is not used), the user is returned to the calling page.
Note: Automated login for external sites is not supported for sites that do not support UTF8 encoding. |
How you allow an end user to define their credentials for an external application depends on the use of the external application. For most services, the credential provisioning screen is incorporated into the task flow that the service exposes and for these no further configuration steps are required. You can, however, add the External Application - Change Password
task flow component to applications using these services thereby allowing the end user to preemptively set the appropriate user name and password for each of the external applications that is registered with your custom WebCenter application.
The External Application - Change Password
task flow displays all external applications defined in the application that do not specify shared credentials (for more information about shared credentials, see Section 37.2.3, "Managing External Applications"). Note that the user must to be authenticated to view this task flow.
For the Instant Messaging and Presence service, however, you must explicitly add the External Application - Change Password
task flow component to your application from the Resource Palette or Component Palette. For step-by-step instructions on how to configure security for the Instant Messaging and Presence service using the External Application - Change Password
task flow component, see Section 18.2.2, "Adding the IMP Service at Design Time".
At run time, the credential provisioning screen displays login data fields composed of the data fields specified through external application registration. Users fill in the data fields with their login information for the specified external application and that login information is passed to the external application or service. Entering the credentials in the provisioning screen also results in the credentials being persisted in the credential store configured for the WebLogic domain.
By default, the login information the user entered is preserved in a credential store, which handles logins for future sessions. The user does not have to enter login information again (unless the user's credentials change). However, the end user can choose to use the information for the current session by deselecting the Remember my Login Information checkbox on the credential provisioning page.
This section provides information about registering external applications. Additionally, it describes the process of editing and deleting registration details. It contains the following subsections:
Section 37.2.3.1, "Working with External Applications in Oracle JDeveloper"
Section 37.2.3.2, "Working with External Applications in Enterprise Manager"
Section 37.2.3.3, "Working with External Applications Using WLST"
This section provides information about registering external applications and editing and deleting registration details in Oracle JDeveloper. It contains the following subsections:
Section 37.2.3.1.1, "Registering an External Application in Oracle JDeveloper"
Section 37.2.3.1.2, "Editing External Application Registration Details in Oracle JDeveloper"
Section 37.2.3.1.3, "Deleting External Application Registration Details in Oracle JDeveloper"
Use the Register External Application Wizard to identify and store information about the type of data required to authenticate to an external application, such as the names of login fields.
To register an external application in Oracle JDeveloper:
In the Applications Navigator, right-click a WebCenter application or project and select New from the context menu.
In the New Gallery, select External Applications under the General node.
In the right pane, select External Application, and click OK.
This displays the Register External Application Wizard.
On the Name page, use the Create external application in option to specify whether the external application can be reused in other WebCenter applications. Select Application Resources to make the external application available only in the WebCenter application in which it is registered, or select Resource Palette to make the external application available from the Resource Palette to any new WebCenter applications you create in Oracle JDeveloper.
If you choose Resource Palette, then the external application connection will be visible under IDE connections in the Resource Palette. If you want to use it in an application, you can right click the external application from resource palette and click Add to Application.
In the Name field enter a unique name to identify the application.
This name must be unique within the WebCenter application, and among other connections as well. Note that you cannot edit this field afterward.
In the Display Name field enter a name for the application that end users will see in the credential provisioning screens.
You can modify the Display Name at any time as described in Section 37.2.3.1.2, "Editing External Application Registration Details in Oracle JDeveloper". If you leave the field blank the display name is set to the value of the Name field by default.
Click Next.
On the General page, in the Login URL field enter the URL to which the HTML login page is submitted.
View the HTML source of the application's login form to retrieve this URL.
Note: The fields on the General pane are only required if the external application being defined participates in click-through login as described in Section 37.2.2, "Supplying User Credentials". |
In the User Name/ID FieldName field, enter the label that the application uses for the user name field, for example, User Name
.
In the Password FieldName field, enter the label that the application uses for the password field, for example Password
.
From the Authentication Method list, select the application's login method.
Choose from the following:
GET
Presents a page request to a server. Submits the login credentials as part of the login URL.
POST
Submits login credentials within the body of a form.
Click Next.
On the Additional Fields page, enter the names and values of any additional fields that are submitted with the external application's login form:
Click the Add Field button to create an input field:
Field Name
Enter a unique name for any additional field that requires user input on the external application HTML login form.
Field Value
Enter a default value for the corresponding field name.
Display to User
Select to display the field on the external application login screen. If the field is not displayed (unchecked), then a default value must be specified, which will be used to login into the external application for all users. If the value is user-specific, then the field must be displayed to the user provisioning page.
Note: The Delete Field option can be used to delete selected rows. |
Click Next.
On the Shared Credentials page, select the Specify Shared Credentials check box and specify a Username and Password if you want all authenticated users to access the external application using this credential. Authenticated users will not be challenged to provide their credentials when they access the external application.
Click Next.
On the Public Credentials page, select the Specify Public Credentials check box and specify a Username and Password to be used for all unauthenticated (public) users accessing the external application. This is required when the external application content is accessed through one of the WebCenter Services (such as Document Library, or Instant Messaging and Presence), and the taskflow is placed on a public page.
Click Finish to register the external application.
After registering your external application, you must configure the application to allow the end user to define the username and password. You can do this by dropping an External Application - Change Password
task flow component into your application. This allows the end user to preemptively set the appropriate username and password for each of the external applications that is registered with your custom WebCenter application.
To configure the application to allow the end user to define the username and password, perform the following steps:
Open a JSF Page in your ViewController project.
From the Resource Palette, under My Catalogs, WebCenter Services Catalog, expand Task Flows.
Drag an External Application - Change Password
task flow component onto your page.
When prompted, choose Region as the way to create the task flow.
Secure the page as this taskflow is accessible only to authenticated users
Use the Edit External Application Registration Information Wizard to revise the registration details provided for an external application.
To edit external application registration details:
In the Application Navigator, from the Application Resources pane under the Connections node, right-click an external application and select Properties from the context menu.
In the Edit External Application Wizard, click a link to show a page and revise its values.
Choose from the following:
Name
General
Additional Fields
Shared Credentials
Public Credentials
For more information, see Section 37.2.3.1.1, "Registering an External Application in Oracle JDeveloper".
Click OK to save your changes and exit the wizard, or click Cancel to exit the wizard without saving.
To delete external application registration information, perform the following steps:
In the Application Navigator, from the Application Resources pane under the Connections node, right-click an external application and select Delete from the context menu.
Alternatively, you can select an external application in the Applications Navigator and from the Edit menu, select Delete.
In the External Application Delete dialog box, select Yes.
Oracle recommends that you remove any references to services, such as a portlet producer, with which the external application is associated. Failing to do so will likely result in runtime errors, because the components will attempt to communicate with the external application.
Just as you can create, edit, and delete external application registration details in Oracle JDeveloper, you can also do this in Enterprise Manager. See the section "Working with External Applications" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter.
As well as Oracle JDeveloper and Enterprise Manager, you can also use WebLogic Scripting Tool (WLST) commands to create, edit, and delete external application registration details. See the section "Working with External Applications" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter.
Refer to the section on adding security to an ADF application in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework for information about securing your application by using Oracle ADF Security, which is based on JAAS.
Refer to the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework for more information on creating a login portlet for your application.
Refer to the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework for more information on creating login pages and login components.
The Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework describes how you can create an ADF Faces-based login page for your application. In this section, you will add some portlets to such a login page so that the login page becomes indistinguishable from the other pages in your WebCenter application.
Make sure your portlet producers have been registered before proceeding. See Section 34.2, "Registering Portlet Producers with a Custom WebCenter Application" for details.
To add portlets to the login page, perform the following steps:
Drag a PanelCustomizable onto the h:form
tag that is inside the first cust:panelCustomizable
tag you added to the login page.
From the Component Palette, select RichTextPortlet Producer, then select the Rich Text portlet from the list and drag it onto the PanelCustomizable
component.
From the Component Palette, select ADF Faces Core and drag an ObjectSeparator below the Rich Text portlet on the PanelCustomizable
component.
From the Component Palette, select OmniPortlet Producer, then select the OmniPortlet from the list and drag it onto the PanelCustomizable
component.
Save the page.
Because the login page is called from the container as part of the login process, the request must be forwarded to the ADF binding filter to establish the appropriate portlet and security context. To do this, you must configure a mapping for the ADF Binding filter in the web.xml
file. To do this, perform the following steps:
In the Applications Navigator, expand the WEB-INF node, right-click web.xml and select properties to open the property palette.
Select Filter Mappings in the left panel and click add to define a new mapping for the adfBindings
Filter. This displays the Create Web Application Filter Mapping dialog box.
Specify adfBindings for the filter name and click the Servlet Name option and specify Faces Servlet as the servlet name. Ensure that the Forward and Include dispatcher types are selected as shown in Figure 37-3.
Figure 37-3 Create Web Application Filter Mapping Dialog Box
Click OK.
Follow the steps in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework to complete the creation of the login page.
WebCenter applications are not secured by default. If you have implemented ADF Security for your WebCenter application and intend to make part of the application public, you must provide a starting point or home page for unauthenticated users. To create this public welcome page, refer to the section on adding security to an ADF application in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Portlet personalizations are tied to particular, authenticated users. Hence, when running a portlet that has an Edit mode, the Personalize option in the portlet's dropdown menu only appears to authenticated users of the application. Anonymous or public users will not have the option to personalize the portlet. If you are a developer creating portlets and pages, then you may want to quickly test the Edit mode of your portlet without creating a complete security model for your application. To perform this sort of testing, you can easily configure some very basic authentication for your application and then remove it when you have finished testing:
Note: This procedure is useful for any portlet that has an Edit mode (Omniportlet, Web Clipping, JPS, and PDK-Java). |
Create a user sking
and the role manager
. See the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework for information about creating users and roles.
Secure your application using the ADF Security Wizard. See the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework for the steps to be performed. On the Login page of the wizard, select HTTP Basic Authentication (RFC 2617). This specifies that the application will use basic authentication.
Run the page in the integrated WLS and log in as a valid user and test your portlet's edit mode.
When you are done testing your portlet's Edit mode, you can quickly remove this test security by do the following:
In the Applications Navigator, click the project that contains a page with the portlet you want to test.
From the Tools menu, choose ADF Security Wizard.
If the Welcome page appears, then click Next.
Choose Remove All ADF Security Settings.
Click Next until you come to the Finish page of the wizard. Click Finish. The security is removed. If you want to ensure that the security has been removed, then exit your browser and rerun the application. When you access the page, you are not prompted to login and the personalize option no longer available from the portlet's dropdown menu.
Secure Sockets Layer (SSL) Communication requires the use of trusted certificates issued by a certificate authority, which vouches for the authenticity of the certificates that it issues or signs. Widely accepted certificate authorities are listed in the keystore, the cacerts
file, available in the <
JDEV_HOME
>\jdk\jre\lib\security
directory. If a portlet producer uses a security certificate issued by a non-widely accepted certificate authority and you try to access portlets from this producer, a security alert is displayed informing you that the security certificate was issued from a certificate authority you do not trust. This means the certificate is not available in the keystore. To avoid being prompted each time you access such portlets, you must register this certificate with the keystore.
To register a certificate with the keystore, perform the following steps:
Navigate to JDEV_HOME
\jdk\jre\lib\security
.
Back up the cacerts
file.
Access the producer URL in Internet Explorer to get the certificate.
Note: Recent versions of FireFox do not provide a means to export certificates. |
In the Security Alert dialog box, shown in Figure 37-4, click View Certificate.
In the Certificate dialog box, click the Certification Path tab.
The dummy child certificate is selected by default as shown in Figure 37-5. Select the root certificate and click View Certificate.
Click the Details tab, and click Copy to File.
In the Certificate Export Wizard, accept the default settings and click Next until you reach the File to Export screen, shown in Figure 37-6.
Figure 37-6 File to Export Screen of the Certificate Export Wizard
In the File Name field, enter <
JDEV_HOME
>\jdk\jre\lib\security\root.cer
and click Next.
Click Finish.
In the command prompt, set your default directory to <
JDEV_HOME
>\jdk\jre\lib\security
and run the following command:
keytool -import -file root.cer -keystore cacerts -storepass changeit
By running this command, the root.cer
certificate is imported into the keystore.
Enter y
at the prompt to confirm that you trust this certificate.
Verify that the cacerts
file is updated with the certificate.
Individual actions on portlets and customizable components are not secured by default. Rather, the ability to customize a portlet or customizable component as a whole is inherited from the page permissions. If you want to grant more granular activities within a portlet or customizable component, then you can override the page-level security inheritance and define security directly on the required actions.
The ability of a user to perform actions on portlets and customizable components is inherited from the page security based on the value of the application-wide switch, enableSecurity
, in the adf-config.xml
file. If you selected the WebCenter application template while creating your application, then the adf-config.xml
file is located in the <
APPLICATION_NAME
>/.adf/META-INF
directory. The enableSecurity
element is not available by default in adf-config.xml
. To override or extend the page-level security inheritance for portlets and customizable components, you must add the portlets security and customizable components security sections in the adf-config.xml
file, as shown in Example 37-1 and Example 37-2 and set the enableSecurity
element in those sections to true
.
Example 37-1 enableSecurity Element in the Portlet Security Section in adf-config.xml
<!-- ============================================================================== PORTLETS ACTIONS SECURITY ============================================================================== --> <adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> .......................................... </adfp:adf-config-child>
Example 37-2 enableSecurity Element in the Customizable Components Security Section in adf-config.xml
<!--
==============================================================================
CUSTOMIZABLE COMPONENTS ACTIONS SECURITY
==============================================================================
-->
<cust:customizableComponentsSecurity
xmlns:cust="http://xmlns.oracle.com/adf/faces/customizable/config
">
<cust:enableSecurity value="true"/>
<cust:actionsCategory>
..........................................
</cust:customizableComponentsSecurity>
Security for actions on portlets and customizable components can be implemented at the following levels:
Page level: You can define security for portlets and customizable components such that page-level privileges are inherited by these components. This is the default behavior.
By default, portlets and customizable components inherit allowable actions from the defined page-level permissions such as personalize or customize. That is, a user who has customize privileges on the page has permission on the customize action for the components on that page. The enableSecurity
element enables you to override the security inheritance behavior and can take either of the following values:
true
: If set to true
(the default), then the ability for a user to modify a component will first be determined from the page permissions and then adjusted according to the current set of actions defined for that type of permission. If a user has customize permission, then the actions that constitute the customize category (move, customize, and so on) are available to the user, but they will be overridden by the actions that are defined in the adf-config.xml
file. For example, a page designer wants to allow the end user to be able to customize portlets, but not customize the page layout. By setting enableSecurity
to true
, the page designer enforces that users must first have customize permission on the page. Setting customizeActionsCategory
to false
for customizable components will prevent the customization of the page layout, yet still allowing portlet customization. (As the default for customizeActionsCategory
is true
, it does not need to be set explicitly for portlets.).
false
: If set to false
, then all the actions are available to users. The user's page permissions and actions configured in adf-config.xml
are ignored.
Actions category level: You can define security on all actions for portlets or customizable components that belong to a named category.
You can add an actionsCategory
element in the adf-config.xml
file to define security on multiple actions simultaneously. Depending on the actionCategory
attributes that you enable, appropriate privileges are provided on the portlets or customizable components.
Actions level: You can define security on individual actions for portlets or customizable components.
You can use the actions
element in the adf-config.xml
file to enable or disable individual actions. Depending on the actions
attributes that you enable, appropriate privileges are provided on the portlets or customizable components.
Notes:
|
Section 37.10.1, "Portlets Security" describes how you can implement security on portlets at the actions category level and actions level. For information on how to define security for actions on customizable components at the application level, see Section 11.5, "Applying Action-Level Restrictions on Panel Customizable and Show Detail Component Actions."
You can define portlet security if actions on portlets are inherited from the page at the application level by setting enableSecurity
to true
in the portlets security section of the adf-config.xml
file. A value of true
implies that the user's permissions are determined from the page permission and then augmented according to the actionsCategory
and actions
elements specified. By defining actions categories and individual actions, you can control the exposure of the individual actions available within the given page permissions.
To implement security for actions on portlets at various levels as described earlier, you must define security settings at the following sections:
You can add an actionsCategory
element in the portlets security section in the adf-config.xml
file to define the group of actions that are exposed on the portlets within the application. Depending on the actionsCategory
attributes that you enable, appropriate privileges are provided on the portlets. Table 37-1 describes the different actionsCategory
attributes and the portlet actions they support by default.
Table 37-1 actionsCategory Attributes and Portlets Actions Mapping
Attribute Value | Actions Supported |
---|---|
viewActionsCategory |
Render isHelpModeAvailable isNormalModeAvailable isAboutModeAvailable isPreviewModeAvailable isDetailModeAvailable isLinkModeAvailable isPrintModeAvailable |
customizeActionsCategory |
showMoveAction showRemoveAction isCustomizeModeAvailable showMinimizeAction showMaximizeAction isConfigModeAvailable |
personalizeActionsCategory |
isPersonalizeModeAvailable |
Example 37-3 shows the actionsCategory
entry that you can add to the portlets security section in the adf-config.xml
file. In this example, customizeActionsCategory
is set to false
to prevent customization. You can use Expression Language (EL) for the values of these elements.
Example 37-3 actionsCategory Element in the Portlets Security Section
<!-- ============================================================================== PORTLETS ACTIONS SECURITY ============================================================================== --> <adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> <adfp:actionCategory name="viewActionsCategory" value="true"/> <adfp:actionCategory name="customizeActionsCategory" value="false"/> <adfp:actionCategory name="personalizeActionsCategory" value="true"/> </adfp:actionsCategory> <adfp:actions> .......................................... </adfp:actions> </adfp:adf-config-child>
You can use the actions
element in the portlets security section of the adf-config.xml
file to enable or disable individual portlet actions. Depending on the action
attributes that you enable, appropriate privileges are provided on the portlets.
Example 37-4 shows an example of an actions
entry that you can add to the portlets security section in the adf-config.xml
file. You can use EL for the values of these elements. In this case you prevent customization by setting isCustomizeModeAvailable
to false
.
Example 37-4 actions Element in the Portlets Security Section
<!-- ============================================================================== PORTLETS ACTIONS SECURITY ============================================================================== --> <adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> .......................................... </adfp:actionsCategory> <adfp:actions> <adfp:action name="Render" value="true"/> <adfp:action name="showMoveAction" value="true"/> <adfp:action name="isCustomizeModeAvailable" value="false"/> <adfp:action name="isPersonalizeModeAvailable" value="true"/> </adfp:actions> </adfp:adf-config-child>
Using EL to Prevent Customization of Portlets Outside of Business Hours
An example to show when you may need to override inherited portlet security is an application that is configured to disable portlet customization outside of standard business hours. For this, you must first create a managed bean (for example, a managed bean called appBusinessRules
), containing the method shown in Example 37-5.
Example 37-5 InsideBizHours Method Defined in appBusinessRules Managed Bean
public boolean isInsideBizHours() { Calendar rightNow = Calendar.getInstance(); int currentHr = rightNow.get(rightNow.HOUR_OF_DAY); // Do not allow customize operation outside of standard business hours if ((currentHr > 9) && (currentHr < 17)) return true; else return false; }
You can then reference this managed bean from the actionsCategory
element in the portlet security section of the adf-config.xml
file, as shown in Example 37-6.
Example 37-6 InsideBizHours Method Referenced in the adf-config.xml File
<adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> <adfp:actionCategory name="customizeActionsCategory" value="#{appBusinessRules.InsideBizHours?"true":"false"}"/> </adfp:actionsCategory> </adfp:adf-config-child>
In this example, the customizeActionsCategory
will be set to true
only if the application is run within business hours. Outside of these hours, the portlet cannot be customized even if the user had that permission granted on the page. All other categories that are not explicitly defined, will be inherited from the page.
Using EL to Prevent Personalization and Customization of Portlets Outside the Corporate Network
In this example the managed bean checks the IP address of the request to determine whether the user has accessed the application through the corporate proxy server or from within the corporate network. In this simple example, assume that if the request has the proxy server's IP address, then it is coming from outside the corporate network. In general it is not advised to base security strictly on IP addresses, because these can be compromised. For this, you must add the method shown in Example 37-7 to the managed bean:
Example 37-7 InsideCorpNetwork Method Defined in appBusinessRules Managed Bean
public boolean isInsideCorpNetwork() { // Do not allow personalize and customize operations // for requests that go through the corporate proxy FacesContext ctx = FacesContext.getCurrentInstance(); ExternalContext ectx = ctx.getExternalContext(); HttpServletRequest myrequest = (HttpServletRequest) ectx.getRequest(); String currentIP = myrequest.getRemoteAddr(); if (currentIP.equals(getProxyServerIP())) return false; else return true; }
You can then reference this managed bean from the actionsCategory
element in the portlet security section of the adf-config.xml
file, as shown in Example 37-8.
Example 37-8 InsideCorpNetwork Method Referenced in the adf-config.xml File
<adfp:adf-config-child xmlns="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> <adfp:actionCategory name="customizeActionsCategory" value="#{appBusinessRules.InsideCorpNetwork?"true":"false"}"/> <adfp:actionCategory name="personalizeActionsCategory" value="#{appBusinessRules.InsideCorpNetwork?"true":"false"}"/> </adfp:actionsCategory> </adfp:adf-config-child>
In this example, the customizeActionsCategory
and the personalizeActionsCategory
will be set to true
only if the IP address of the request for the application does not match that of the corporate proxy. The assumption is that the internal requests would have a valid client IP address. All other categories that are not explicitly defined, will be inherited from the page.
The following table lists the identity propagation mechanisms employed by WebCenter Services for propagating the end-user's identity to the various information sources from which content is being integrated into the WebCenter application.
Whenever possible, WS-Security is the preferred means of identity propagation. Where WS-Security cannot be used due to legacy restrictions or pre-defined store-specific standards or specifications, the primary mechanism used is the credential mapping capability provided by the External Applications service to obtain the user's credentials for a remote application using a distinct security provider. For more information about WS-Security, see the Oracle Fusion Middleware Security and Administrator's Guide for Web Services. For more information about External Applications, see Section 37.2, "Working with External Applications".
Table 37-2 Identity Propagation Mechanisms
Service | Connection Type | Identity Propagation Mechanism |
---|---|---|
Conference |
Webex |
External Application |
Discussions |
Jive |
Oracle WS-Security |
Announcements |
see Discussion Forum |
|
Documents |
Oracle Content Server |
Proprietary ID propagation mechanism through socket connection. Can use SSL with mutual authentication, or clear socket with IP authorization (or use External Application option) |
File System |
N/A |
|
Portal 10g/11g |
JSR-170 (External Application) |
|
Day Adapters |
JSR-170 (External Application) |
|
|
EMail Connection |
External Application |
LDAP Connection |
External Application |
|
Events - Personal |
Exchange Server Connection |
External Application |
External Application |
HTTP Request from Browser |
External Application |
IMP |
Microsoft Live Communication Server (LCS) |
SOAP, Web Services calls. External Application |
Oracle WebLogic Communications Services (OWLCS) |
Oracle WS-Security |
|
Portlet Producers |
WSRP Producer (Secure) |
Oracle WS-Security (Recommended by WSRP Specification) |
WSRP Producer (Non-Secure) |
WSRP userContext in SOAP message (WSRP Specification) |
|
JPDK Producer (External App) |
External Application JPDK payload includes the user information and is conveyed to the producer in the ProviderUser. The information also includes a mapped username and password. (Proprietary, Legacy) |
|
JPDK Producer (Non-Secure) |
Username in render request (Proprietary, Legacy) |
|
Search |
Secure Enterprise Search (SES) |
Web Service Call |
Wiki |
Browser Connection |
SSO mechanisms - OSSO/OAM or other WLS supported SSO mechanism |
Worklist Service |
BPEL Connection |
Web Service call Oracle WS-Security |
The Web Services for Remote Portlets (WSRP) specification indicates that Web Services Security (WS-Security) can be leveraged for providing secure identity propagation between the consumer and the portlet producer. However, WSRP in and of itself does not provide secure identity propagation of the end user's identity to the portlet producer. The WSRP specification explicitly defers to other security standards for secure identity propagation and does not go into the specific WS-Security profiles or options that may be employed. In the absence of a secure mechanism, WSRP defines the concept of user categories, which can be mapped to security roles like the ones used by the JSR168 portlets. By using a combination of WSRP and WS-Security, you can ensure end-to-end security.
This section covers the following:
When using WSRP without WS-Security, the userContext
structure within the SOAP message contains user profile information and user category information. This information is not considered secure and should only be used for personalization and customization functionality. It should not be used for authorization of sensitive resources. This information is also exposed in the JSR168 APIs, isUserInRole(
role
)
and getUserPrincipal
. The code in Example 37-9 shows how a sample portlet's markup rendering code uses the isUserInRole
API to decide what content to display.
Example 37-9 isUserInRole(role) API
private void doViewHtml(RenderRequest request, RenderResponse response) throws PortletException, IOException { // To do: markup the required content. PrintWriter out = response.getWriter(); out.print("<p>Welcome"); out.println("</p>"); if (request.isUserInRole("moderator")) {out.println("<p>MODERATOR</p>" );} else {out.println("<p>not moderator</p>" );} if (request.isUserInRole("participant")) {out.println("<p>PARTICIPANT</p>" );} else {out.println("<p>not participant</p>" );} if (request.isUserInRole("viewer")) {out.println("<p>VIEWER</p>" );} else {out.println("<p>not viewer</p>" );} }
When WS-Security is leveraged with WSRP, the user's identity is propagated outside of the SOAP message body in the WS-Security header. This is a user assertion, using the Username Token format, and is digitally signed to authenticate the consumer and to ensure the integrity of the assertion.
When this mechanism is used, the JSR 168 APIs isUserInRole
and getUserPrincipal
are established based on the security context resulting from the WS-Security authentication, rather than the information in the SOAP message's userContext
.
Also, when an Anonymous (i.e., PUBLIC) client is mapped to a default user using the producer's Default User connection parameter, the WSRP producer must be configured with strict-authentication
and a grant must be added to the Policy store. For more information, see "Adding a Grant to the Policy Store for a Mapped User Identity" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
The use of WS-Security adds some complexity to the configuration and management of the WebCenter application and the set of producers it consumes. However, when the situation warrants its use, it becomes an important ingredient of the SOA architecture that ensures the security of the information being published by the WebCenter application.
Oracle WebCenter Framework supports the following token profiles (to digitally sign the security token and message body to ensure authenticity and integrity):
Username token without password
Username token with password
SAML token (uses the sender vouches method that the producer uses to confirm the subject assertion)
Digitally signing the security token and the SOAP message body accomplishes the following objectives:
Consumer Authentication
When a portlet producer is generating sensitive information, for example paystub information, it is imperative that it only responds to requests to show the information from a legitimate consumer.
By using WS-Security, and having the consumer digitally sign the security token and the message body, the producer can verify the signature using the public key of the legitimate consumer. If the signature cannot be verified, then it means that the request may have come from a fraudulent consumer. By requiring the verification of the digital signature, the sensitive information will only be sent to the legitimate consumer.
Assertion and Message Integrity
In addition to verifying the identity of the consumer making the Web Service requests, digitally signing the security token and the message body also ensures that the token and the message have not been tampered with. This prevents such problems as man-in-the-middle attacks where a legitimate request might be intercepted and the user name in the security token replaced with another user name to see the paystub information coming back for the other user. By digitally signing the token, it cannot be tampered with. Any modification to the token would result in the inability to verify the signature on the producer end, and would result in a SOAP fault to be returned instead of the requested paystub information.
Supported Producers
WS-Security implementation is supported by the Oracle WebCenter Suite WSRP container. Other WSRP vendors may also be able to support the WS-Security configuration of Username Token without password, with XML digital signature on the Username Token and the SOAP Message body.
Security Domain Implication
When using secure identity propagation as described in this section, the user name of the user authenticated to the consumer (WebCenter application) is propagated to the producer without any remapping or providing any credentials. There is an inherent assumption that the producer understands this user name and can locate this user in its associated security domain. Consequently, it is highly desirable to ensure that the consumer and producer share the same security provider (identity store) to simplify the management of this configuration.
Figure 37-7 summarizes the overall WSRP portlet security architecture.
Figure 37-7 WSRP Portlet Security Architecture
Before you configure the producer for WS-Security, you must first deploy your standards-compliant portlet producer to the Oracle WebCenter Suite WSRP Container by performing the steps described in Chapter 33, "Testing and Deploying Your Portlets".
After you have deployed the producer, configure the producer for WS-Security by performing the following steps:
Attaching a policy to the producer endpoint
Creating the keystores
Configuring the producer
Configuring the consumer
These steps are described in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter .
This section describes the available security services for your PDK-Java portlet.
For more detailed information about the PDK classes referred to in this section, see the JavaDoc on OTN by clicking Java Doc API on the Portlet Development page available at
http://www.oracle.com/technology/products/ias/portal/portlet_development_10g1014.html
The following assumptions are made to perform the tasks in this section:
You have followed through and understood Section 31.2, "Creating Java Portlets".
You built a portlet using the wizard and successfully added it to a page.
This section introduces the major features that are available to secure your PDK-Java portlet producers.
When a user first logs in, they must enter their password to verify their identity and obtain access.
Once the user is authenticated, the producer code has access to the authenticated user's identity from the PortletRenderRequest
that is available from the HttpServletRequest
object as follows:
PortletRenderRequest pr = (PortletRenderRequest)request.getAttribute (HttpCommonConstants.PORTLET_RENDER_REQUEST); String userName = pr.getUser().getName();
When using this user identity for sensitive operations, it is important to ensure that you have configured this producer to use basic message authentication to secure the integrity of the identity assertion.
Authorization determines if a particular user may view or interact with a portlet.
To this point, user authentication and authorization are covered, which do not check the authenticity of messages received by a producer. To completely secure your producers, you should also secure the communication with a producer. If the communication is not secured, then it is possible for someone to imitate an application instance and fool the producer into returning sensitive information. There are three types of communication security:
Server Authentication restricts access to a producer to a small number of recognized computers. This method compares the IP address or the host name of an incoming HTTP message with a list of trusted hosts. If the IP address or host name is in the list, then the message is passed to the producer. If not, it is rejected before reaching the producer.
Message Authentication provides consumer authentication and message integrity. It uses a shared key known to the client (WebCenter application) and the producer to digitally sign messages. See Section 37.13.5, "Message Authentication" for more information.
Message Encryption relies on the use of the HTTPS protocol for communication between applications and producers. Messages are strongly encrypted to protect the data therein. Encryption provides a high level of security, but it incurs a performance penalty due to the additional processing required for each message.
User Input Escape causes the application to escape any user input strings and treat them as text only to protect against XSS attacks, where an attacker attempts to pass in malicious scripts through user input forms. For example, if a portlet title is customizable, then an attacker might attempt to pass scripts or commands to the portlet through the title parameter entry. For this reason, the default behavior is to escape user input and thus disable any incoming scripts. See Section 37.13.6, "User Input Escape" for more information.
Portlets may act as windows into an application. They display summary information and provide a way to access the full functionality of the application. Portlets display some portions of the application in the WebCenter application and typically enable the user to perform some application tasks.
An application may need to authenticate the user accessing the application through the portlet. The following are the possible application authentication methods:
External Application. In this case, the Oracle Portal (Oracle Portal) user is different from the application user, but the application user name and password are managed by the Oracle Portal user.
No Application Authentication. In this case, the communication between producer and consumer is not protected at all.
An external application uses a different authentication server than the WebCenter application. This means that when a user is logged into the WebCenter application, you want to also log them into the external application without having to type in their user name or password.
Applications that manage the authentication of users can be loosely integrated with the WebCenter Framework if the administrator registers them as external applications. When a user who was previously authenticated by the WebCenter Framework accesses an external application for the first time, WebCenter Framework attempts to authenticate the user with the external application. The authentication process submits an HTTP request that combines the registration information and the user's user name and password for the application. If the user has not yet registered their user name and password for the external application, then the user is prompted for the required information before making the authentication request. When a user supplies a user name and password for an external application, WebCenter Framework maps the new user name and password to the WebCenter application user name and stores them. They will be used the next time the user needs authentication with the external application.
The advantages of an external application implementation are as follows:
Provides a single sign-on experience for users. However, users still must maintain different user names and passwords. In addition, the external application user name mapping must be maintained.
Allows integration with multiple portals independent of their user repositories and Oracle Single Sign-On.
Avoids the requirement of having access to the application source code.
The disadvantages of an external application implementation are as follows:
Does not share the same user repository as the portal, which requires additional maintenance of user information by the end user.
Transmits the user name and password to the producer in plain text, unless you implement Secure Sockets Layer (SSL).
The producer trusts the WebCenter application instance sending the request completely. The producer can determine if the user is logged in and the portal user name, but the application has not authenticated the user.
The advantages of no application authentication are as follows:
Provides the easiest form of integration and the fastest to implement.
The disadvantages of no application authentication are as follows:
Provides the least security.
Provides the weakest integration with the WebCenter application.
Portlet security managers may be implemented within a producer to restrict access to portlets depending on the user details. When a user views a page with a portlet instance on it, security managers determine whether the user has the appropriate privileges to see the portlet. Implementing access control methods in the producer restricts the retrieval of content from a portlet (that is, hides the portlet) from users without the appropriate privileges. Only if the specified characteristics, such as user details and preferences, pass the authorization logic will the content be retrieved for the user. If no portlet security methods are implemented in the producer, then any user name may be passed in, even fictitious, unauthenticated ones.
AuthLevelSecurityManager
has access to the following information about authorization level:
Strongly authenticated.
The user has signed into the WebCenter application, and requested the portlet in the context of that session.
Public or not authenticated.
The user has not logged in within the context of the current session, and does not have a persistent cookie to indicate that such a state previously existed.
To incorporate these security services into your Java portlet, you must update provider.xml
and set the security level to strong, weak, or public. Place the following XML right before the </portlet>
tag in provider.xml
:
<securityManager class="oracle.portal.provider.v2.security.AuthLevelSecurityManager"> <securityLevel>strong</securityLevel> </securityManager>
After you make this change to provider.xml
, refresh the producer.
For more information about the syntax of provider.xml
, see the producer JavaDoc on OTN:
http://www.oracle.com/technology/products/ias/portal/html/javadoc/xml_tag_reference_v2.html
If your portlet requires special security arrangements which are not provided by the implementations shipped with the PDK, then you must supply your own custom PortletSecurityManager
controller class. To do this, extend the oracle.portal.provider.v2.security.
PortletSecurityManager
class and supply implementations for the two methods specified by the interface. Then replace the class attribute of the securityManager
controller element in the XML producer definition with you new class name and configure child elements appropriately.
Message authentication uses a digital signature. The signature is generated using a Hashed Message Authentication Code (HMAC) algorithm and is based on user information, the shared key, and a UTC (Universal Time, Coordinated) timestamp. The producer authenticates the message using its own copy of the shared key. This technique can be used in Secure Sockets Layer (SSL) communication with a producer instead of client certificates.
For caching purposes, show request signatures are calculated each time a session is set up so producers using message authentication must always have Producer Sessions enabled. This also means that there is a trade-off between performance and security. Shorter session timeouts mean less chance of a message being re-sent illegally, but there is a performance overhead associated with reestablishing a provider session.
A single producer instance cannot support multiple shared keys because it could cause security and administration problems. For instance, if one copy of the shared key is compromised in some way, then the producer administrator has to create a key and distribute it to all of the application clients, who then must update their producer definitions. The way around this problem is to deploy different producer services, specifying a unique shared key for each service. Each producer service has its own deployment properties file so that each service is configured independently of the others. The overhead of deploying multiple producer services within the same producer adapter is relatively small.
While the signature element provides protection against interception and resending of messages, it does nothing to prevent interception and reading of message contents. Messages are still transmitted in plain text. If you are concerned about the content of messages being read by unauthorized people, then this must used in conjunction with SSL to encrypt the message.
The advantage of message authentication is as follows:
Ensures that the message received by a producer comes from a legitimate WebCenter application instance.
The disadvantages of message authentication are as follows:
Causes administration problems if a producer serves multiple portals. Entails performance implications if made very secure by having a short session timeout.
By accepting user input without escaping it to text, you run the risk of an XSS attack, where an attacker attempts to pass in malicious scripts through user input forms. For example, if a portlet title is customizable, then an attacker might attempt to pass scripts or commands to the portlet through the title string. PDK-Java provides the following features to ensure that you can protect your portlets from such attacks:
To prevent any script inside a portlet title from being executed, the framework default container renderer class encodes any script characters. This default behavior is controlled through a JNDI variable, escapeStrings
. When set to true
, the markup tags in portlet titles are rendered as visible tag characters. For example, a title customization of <i>title</i>
will be rendered as <i>title</i>
not title. This mode is secure, but, if it is not the desired behavior, then you can set escapeStrings
to false
for that producer.
escapeStrings
applies to all logical producers within a producer. You can set the value of escapeStrings
from the Fusion Middleware Control Console as you would any other JNDI variable. See Section 32.2.4.2, "Setting JNDI Variable Values" for more information.
If you have code that renders customized values, then you must ensure that you escape those input values appropriately to avoid XSS attacks. This requirement applies to code for rendering pages in any mode. PDK-Java supplies two new static methods for this purpose. They are in the Java class oracle.portal.provider.v2.url.UrlUtils
, and can be described as follows:
public static escapeString(
string_text
)
escapes any script characters in a given string. For example, less than < becomes <
. This method is unaffected by the escapeStrings
JNDI variable and is the secure, recommended method to use.
public static escapeStringByFlag(
string_text
)
escapes any script characters in a given string. This method is controlled by the escapeStrings
JNDI variable and is therefore less secure and not the recommended method to use.
For example:
title = UrlUtils.escapeString(data.getPortletTitle());
This section provides troubleshooting information to help diagnose security related issues for custom WebCenter applications.
This section includes the following troubleshooting notes:
Problem
When you run a page containing a content repository data control method, the following error message appears:
"Unable to locate the credential for key extapp in JPS credential store."
Cause
Credentials need to be provisioned explicitly using the change password task flow before you access the page that uses the data control method.
Solution
Since the data control is only a model and cannot do anything at the user interface level to allow credential provisioning, you must write an error handler that takes care of the redirection in the user interface. For information about writing an error handler, see the "Customizing Error Handling" section in the Oracle Application Development Framework Developer's Guide.
The following is a sample error handler:
public class ErrorHandler extends DCErrorHandlerImpl { public ErrorHandler(boolean b) { super(b); } public ErrorHandler() { super(true); } @Override public void reportException(DCBindingContainer formBnd, Exception ex) { if (ex instanceof AdapterException) { AdapterException ae = (AdapterException) ex; if (ae.getCause() != null && ae.getCause() instanceof ExtAppLoginException) { ExtAppLoginException eale = (ExtAppLoginException) ae.getCause(); Throwable t = eale.getCause(); if (t != null && (t instanceof ExtAppCredentialNotFoundException) || (t instanceof ExtAppInvalidUserCredential)) { String extAppId = eale.getExternalAppId(); showCredentialsProvisioningDialog(extAppId); return; } } } super.reportException(formBnd, ex); } private void showCredentialsProvisioningDialog(String extAppId) { FacesContext context = FacesContext.getCurrentInstance(); // Create the dialog UIViewRoot ViewHandler viewHandler = context.getApplication().getViewHandler(); UIViewRoot dialog = viewHandler.createView(context, "/oracle/adfinternal/extapp/view/pages/CredentialProvisionerDialog.jspx"); HashMap<String, Object> properties = new HashMap<String, Object>(); properties.put("width", new Integer(500)); properties.put("height", new Integer(350)); HashMap<String, Object> parameters = new HashMap<String, Object>(); parameters.put("oracle.extapp.id", extAppId); RequestContext reqContext = RequestContext.getCurrentInstance(); //launched from the button, need to specify this for the return listener //to be called. reqContext.launchDialog(dialog, parameters, null, true, properties); } }