Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter
11g Release 1 (11.1.1.4.0)

Part Number E12405-13
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

27 Managing WebCenter Portal Application Security

This chapter provides an introduction to securing WebCenter Portal applications, and describes the security configuration that is in place when WebCenter Portal applications and WebCenter Spaces are initially deployed. This chapter also includes a troubleshooting section that provides solutions for common security-related configuration issues.

This chapter includes the following sections:

For information about specific aspects of configuring security for WebCenter Portal applications, see:

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."

27.1 Introduction to WebCenter Application Security

The recommended security model for Oracle WebCenter is based on Oracle ADF Security, which implements the Java Authentication and Authorization Service (JAAS) model. For more information about Oracle ADF Security, see the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

Figure 27-1 shows the relationship between a WebCenter application deployment and its services, servers, portlets, portlet producers, its identity, credential and policy stores, and Oracle Enterprise Manager.

Figure 27-1 Basic WebCenter Application Architecture

Description of Figure 27-1 follows
Description of "Figure 27-1 Basic WebCenter Application Architecture"

The diagram in Figure 27-2 shows a basic WebCenter application after deployment with its back-end server connections.

Figure 27-2 WebCenter Application Architecture with Back-end Server Connections

Description of Figure 27-2 follows
Description of "Figure 27-2 WebCenter Application Architecture with Back-end Server Connections"

The diagram in Figure 27-3 shows the security layers for WebCenter applications.

Figure 27-3 WebCenter Security Layers

Description of Figure 27-3 follows
Description of "Figure 27-3 WebCenter Security Layers"

WebCenter Portal applications and WebCenter Spaces share the same four bottom security layers (WebCenter Security Framework, ADF Security, OPSS, and WebLogic Server Security). The application layer will, of course, depend on the implementation.

WebCenter Application Security

WebCenter provides support for:

WebCenter Security Framework

WebCenter Security Framework provides support for:

ADF Security

ADF Security provides support for:

Oracle Platform Security Services (OPSS)

OPSS provides support for:

WebLogic Server Security

WebLogic Server Security provides support for:

27.2 Default Security Configuration

This section describes the security configuration that is in place when WebCenter Portal applications and WebCenter Spaces are deployed, and the tasks that must be carried out after deployment:

27.2.1 Administrator Accounts

WebCenter Portal applications do not contribute any pre-seeded accounts, and therefore rely on the Fusion Middleware administrator account (weblogic by default) that is set up when Fusion Middleware is installed. Use this administrator account to log into Fusion Middleware Control and set up new accounts.

Although WebCenter Spaces does not contribute any pre-seeded accounts, there are certain pre-seeded grants that are given to the default Fusion Middleware administrator account (weblogic) for the WebCenter Spaces application. If your installation does not use weblogic as the account name for the Fusion Middleware administrator role, you must configure one or more other users for this role as described in Section 28.4.1, "Granting the WebCenter Spaces Administrator Role."

27.2.2 Application Roles and Enterprise Roles

Application roles differ from roles that appear in the identity store portion of the embedded LDAP server or in roles defined by the enterprise LDAP provider. Application roles are specific to an application and defined in an application-specific stripe of the policy store.

Enterprise roles, which are stored in the enterprise identity store, apply at the enterprise level. That is, the roles and permissions that you or a system administrator define within the enterprise identity store do not imply permissions within an application.

Within WebCenter Spaces or a WebCenter Portal application you can assign application roles and permissions to users in the corporate identity store. You can also assign application roles and permissions to enterprise roles defined in the enterprise identity store.

27.2.3 Default Identity and Policy Stores

By default, WebCenter applications are configured to use a file-based embedded LDAP identity store to store application-level user IDs, and a file-based LDAP policy store to store policy grants.

Although secure, the embedded LDAP identity store is not a "production-class" store and should be replaced with an external LDAP-based identity store such as Oracle Internet Directory for enterprise production environments. For a list of supported identity store LDAP servers, see "Supported LDAP Identity Store Types" in the Oracle Fusion Middleware Security Guide.

The default file-based policy store can only be used for single-node WebCenter Spaces configurations. For multi-node configurations, you must reassociate the policy and credential store with an external LDAP-based store as described in Chapter 29, "Configuring the Policy and Credential Store."

The policy and credential stores can use either Oracle Internet Directory 11gR1 or 10.1.4.3, or Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later). Note that when using an external LDAP-based store, the policy and credential stores must use the same LDAP server. Similarly, when using a database, the policy and credential stores must use the same database.

For more information about the supported identity store and policy and credential store configurations, see "Supported LDAP-, DB-, and File-Based Services" in the Oracle Fusion Middleware Security Guide. For more information on reconfiguring the identity, policy and credential stores, see Chapter 28, "Configuring the Identity Store"and Chapter 29, "Configuring the Policy and Credential Store."

Note:

By default, Oracle WebCenter Discussions is configured to use the embedded LDAP identity store: All users in the embedded LDAP store can log on to the discussions server, and all users in the Administrators group have administrative privileges on Oracle WebCenter Discussions.

If you reassociate the identity store with an external LDAP server, you must either move the Fusion Middleware administrator account to the external LDAP (as described in Section 28.5, "Moving the Administrator Account to an External LDAP Server"), or if you choose not to move the administrator account, you must perform some additional steps to identify the new administrator account for the discussions server as described in Section 28.5.1, "Migrating the WebCenter Discussions Server to Use an External LDAP."

For WebCenter Spaces, both WebCenter Spaces and Oracle Content Server must share the same LDAP server. For more information, see Section 28.6, "Configuring the Oracle Content Server to Share the WebCenter Spaces Identity Store LDAP Server."

27.2.3.1 File-based Credential Store

The out-of-the-box credential store is wallet-based (that is, file-based) and is contained in the file cwallet.sso. The location of this file is specified in the Oracle Platform Security configuration file jps-config.xml. When you reassociate the policy store to an LDAP directory, the application credentials are automatically migrated to the same LDAP directory as the policy store.

27.2.4 Default Policy Store Permissions and Grants

The ADF Security permissions model supports both permission-based and role-based authorization. These two types of authorization, and the default Policy Store permissions and code based grants are discussed in the following sections:

27.2.4.1 Permission-based Authorization

Permission-based authorization is used for services, such as Lists, where access control is implemented within the WebCenter application using Oracle Platform Security Services (OPSS). WebCenter Spaces provides extensive user and role management tools with which you can create application roles, and define what permissions should be granted to those roles. For information on managing users and roles in WebCenter Spaces, see "Managing Application Roles and Permissions" in Oracle Fusion Middleware User's Guide for Oracle WebCenter.

27.2.4.2 Role-mapping Based Authorization

Services that need to access "remote" (back-end) resources require role-mapping based authorization. For example, for the Discussions service, role mapping is required when the users of a WebCenter application (mapping to one or more group space roles) must be mapped to another set of roles on the Oracle WebCenter Discussions Server.

In WebCenter Spaces:

  • WebCenter Spaces roles are mapped to corresponding roles on the Oracle WebCenter Discussions Server.

  • When a user is granted a new WebCenter Space role, a similar grant (privilege) is granted in the back-end server. For example, when user Pat is granted Discussions-Create/Edit/Delete permissions in WebCenter Spaces, Pat is granted corresponding permissions in the back-end discussion server.

See also, "Understanding Discussions Server Role and Permission Mapping" in Oracle Fusion Middleware User's Guide for Oracle WebCenter.

27.2.4.3 Default Policy Store Permissions for WebCenter Spaces

Out-of-the box, WebCenter Spaces provides the following default roles:

Default application roles:

  • Administrator

  • Authenticated-User

  • Public-User

For more information about the default application roles, see "Default Permissions for Application Roles" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter.

Default roles in a space:

  • Moderator

  • Participant

  • Viewer

For more information about the default role within a space, see "Default Permissions for Roles in a Space" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter.

27.2.4.4 Default Code-based Grants

WebCenter applications make internal calls to APIs on the security platform that are secured with permission checks. Consequently, the WebCenter application must be granted appropriate permissions to invoke the OPSS APIs (for example, the permission to access the policy store and grant or revoke permissions (PolicyStoreAccessPermission, or grant basic permissions to application roles). In the case of WebCenter Spaces, basic application role permissions are granted by default as described in "Default Permissions for Application Roles" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter.

Similarly, WebCenter applications must pre-authorize access to various operations that it wants to expose using the WebCenter permissions, and then invoke the OPSS APIs as privileged actions.

27.2.5 Post-deployment Security Configuration Tasks

After deploying your WebCenter Portal application or WebCenter Spaces, consider the following security-related configuration tasks for your site:

  • Reassociating the identity store to use an external LDAP

    By default, WebCenter applications use an embedded LDAP for its identity store. Although secure, the out-of-the-box embedded LDAP may not scale appropriately for large enterprise production environments. For instructions on how to configure the identity store to use an external LDAP such as Oracle Internet Directory (OID), see Chapter 28, "Configuring the Identity Store."

    Note:

    By default, Oracle WebCenter Discussions is configured to use the embedded LDAP identity store: All users in the embedded LDAP store can log on to the discussions server, and all users in the Administrators group have administrative privileges on Oracle WebCenter Discussions.

    If you reassociate the identity store with an external LDAP server, you must either move the Fusion Middleware administrator account to the external LDAP (as described in Section 28.5, "Moving the Administrator Account to an External LDAP Server"), or if you choose not to move the administrator account, you must perform some additional steps to identify the new administrator account for the discussions server as described in Section 28.5.1, "Migrating the WebCenter Discussions Server to Use an External LDAP."

    For WebCenter Spaces, both WebCenter Spaces and Oracle Content Server must share the same LDAP server. For more information, see Section 28.6, "Configuring the Oracle Content Server to Share the WebCenter Spaces Identity Store LDAP Server."

  • Reassociating the policy store to use an external LDAP or database

    By default, WebCenter Portal applications use a file-based system-jazn-data.xml policy store to store policy grants. You should consider using an LDAP-based or database policy store. For information on how to configure the policy store to use an LDAP server or database, see Chapter 29, "Configuring the Policy and Credential Store."

  • Configuring WS-Security

    Although the use of WS-Security adds complexity to the configuration and management of a WebCenter Portal application and the set of producers it consumes, it helps ensure the security of the information being published by the WebCenter Portal application. Adding WS-Security provides authentication for the consumer, and message-level security.

    For information on how to configure WS-Security for WebCenter applications and components, see Chapter 32, "Configuring WS-Security."

  • Configuring SSO

    Single Sign-On (SSO) allows users to log in once across WebCenter applications and components rather than having to log in for each sub-application (for example, for accessing a wiki page in WebCenter Spaces). Users do not have to maintain a separate user ID and password for each application or component that they access. However, you can still configure a variety of authentication methods, so that more sensitive applications can be protected using more stringent methods. WebCenter supports four single sign-on solutions: Oracle Access Manager (OAM), Oracle Single Sign-on (OSSO), a SAML-based single sign-on solution for Oracle WebCenter applications only, and an SSO solution for Microsoft clients, using Windows authentication based on the Simple and Protected Negotiate (SPNEGO) mechanism and the Kerberos protocol. For a discussion of these solutions and an overview of single sign-on, see Chapter 30, "Configuring Single Sign-on."

  • Configuring SSL

    Secure Sockets Layer (SSL) provides additional security for connections between WebCenter applications or components by providing an additional authentication layer, and by encrypting the data exchanged. For connections between applications or components where the data exchanged is sensitive, consider securing the connection with SSL. For a list of the connections that can and should be protected with SSL in a production environment, see Chapter 31, "Configuring SSL."

    Note:

    Using SSL is computationally intensive and adds overhead to a connection. SSL should therefore not be used where it is not required, and is best reserved for production environments.

27.3 Troubleshooting Security Configuration Issues

This section includes the following sub-sections:

27.3.1 Webcenter Spaces Does Not Find Users in LDAP Provider

Problem

Weblogic Server was configured with an external LDAP provider. Users in the external LDAP can log in to WebCenter Spaces, but when you try to assign the administrator role, in WebCenter Spaces, to a user from the external LDAP, no users are found.

Solution

Change the Control Flag for the DefaultAuthenticator Authentication Provider to Sufficient as described in Chapter 28, "Configuring the Identity Store." Restart the Administration Server and Managed Servers for the domain.

27.3.2 Group Space Gets Created with Errors When Logged in as OID User

Problem

When logged in to WebCenter as an OID user (for example, orcladmin), and you try to create a group space, the group space gets created but with errors. The error message appears as "No matching users were found with search string <login user>".

Solution

The following property is missing in the jps-config.xml file:

<property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/> 

To fix this:

  1. Edit <MIDDLEWARE_HOME>/user_projects/domains/WebCenter/config/fmwconfig/jps-config.xml.

  2. Add this line in the general properties:

    <property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/>

  3. Restart the WLS_Spaces server.

27.3.3 Users Cannot Self-Register when WebCenter Spaces Configured with Active Directory

Problem

Users cannot self-register with Active Directory after configuring WebCenter Spaces to use AD authenticator. When a user tries to self-register, the following error message appears:

"User not created. Either the user name or the password does not adhere to the registration policy or the identity store is unavailable. Specify the required user credentials or contact your administrator for assistance."

Solution

To fix the problem:

  1. Set the user name attribute to sAMAccountName while configuring Active Directory in the WebLogic Administration Console.

  2. Use the HTTPS port of the LDAP and enable the SSL checkbox while configuring Active Directory in the WebLogic Administration Console.

27.3.4 User Made Administrator Does Not Have Administrator Privileges

Problem

After logging in as orcladmin and making a user an administrator, after logging out and logging in as that user, the Administrator link is still not available.

Solution

The problem is due to duplicate cn entries in the identity store. Since cn is mapped to the username attribute, it must be unique. Remove the duplicate from the identity store and the user should have the appropriate privileges.cn.

27.3.5 OmniPortlet Producer Authorization Exception in SSO Environment

Problem

OmniPortlet producer receives an authorization exception when it tries to store connection information in the Credential Store Framework (CSF) wallet when WebCenter is configured with SSO.

Solution

Grant the required permissions to ssofilter.jar by connecting to the Oracle WebCenter Administration Server using WLST (for more information, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands") and running the following grant commands:

grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_user,keyName=*",
permActions="*")
grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_default,keyName=*",
permActions="*")
grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1
.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_user,keyName=*",
permActions="*")

27.3.6 Deploying the SAML SSO-specific Discussions EAR file Produces an Exception

Problem

Undeploying the Discussions EAR file and deploying the SAML SSO-specific Discussions EAR file and then starting the application in the WLS Administration Console produces the following exception:

java.lang.ClassCastException:
org.apache.xerces.parsers.XIncludeAwareParserConfiguration

Solution

Restart the WC_Collaboration server. This should fix the issue and the Discussions application will be in an active state.

27.3.7 Configuring SAML Single Sign-on Produces 403 Error

Problem

While testing a SAML SSO configuration you encounter 403 errors, and after turning on debug logging, as described in Section 30.4.2.4, "Checking Your Configuration," you see the following kind of error logs in the destination server:

####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLLib> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831335> <BEA-000000> <SAMLSignedObject.verify(): validating
signature>
####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLService> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831336> <BEA-000000> <SAMLDestinationSiteHelper: Signature
verification failed with exception: org.opensaml.InvalidCryptoException:
SAMLSignedObject.verify() failed to validate signature value>
####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLService> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831336> <BEA-000000> <SAMLDestinationSiteHelper: Unable to validate
response -- returning SC_FORBIDDEN>
####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLService> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831336> <BEA-000000> <SAMLSingleSignOnService.doACSGet: Failed to get
SAML credentials -- returning>

Solution

Chances are that something went wrong with your certificate setup due to which SAML assertions are not getting validated. This is likely because the certificate registered in the SAML Identity asserter is incorrect. Export the certificate used for SAML SSO setup in the WebCenter Spaces domain specified by certAlias and certPassword and copy it to a accessible location in the destination domain.

  1. Update the relevant config section in the wcsamlsso.properties file in the WebCenter Spaces domain (for example, if the certificate was invalid for the SOA configuration, update the certPath in the soa_config section).

  2. Open the WebLogic Server Admin Console, and from the WC_Spaces domain go to Security Realm > Providers > Credential Mapping > wcsamlcm > Management > Relying Parties and delete the relying parties relevant to the domain (for example, for SOA, they would be Worklist Integration, Worklist Detail, and Worklist SDP.)

  3. Go to Destination Domain > Security Realm > Providers > Authentication >wcsamlia > Management > Asserting Parties and delete the corresponding asserting parties.

  4. Open the Certificates tab and delete the certificate as well.

  5. Go back to the WebCenter Spaces domain and re-run the scripts for creating asserting-relying parties pairs. For SOA, for example, you would need to re-run:

    $WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistIntegration.py
    $WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistDetail.py
    $WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistSDP.py
    
  6. Test your configuration again. If all works well, you can disable SAML logging.