23 Managing WebCenter Portal Security
Note:
Oracle WebCenter Portal has deprecated the support for Jive features (announcements and discussions). If you have upgraded from a prior release to Release 12c (12.2.1.4.0), Jive features remain available in your upgraded instance but Oracle support is not provided for these features. In the next release, Jive features will not be available even in the upgraded instances
Permissions:
To perform the tasks in this chapter, you must be granted the WebLogic Server Admin
role through the Oracle WebLogic Server Administration Console. Users with the Monitor
or Operator
roles can view security information but cannot make changes.
See also, Understanding Administrative Operations, Roles, and Tools.
Topics:
For information about specific aspects of configuring security for WebCenter Portal, see:
Introduction to Application Security
The recommended security model for WebCenter Portal is based on Oracle ADF Security, which implements the Java Authentication and Authorization Service (JAAS) model. For more information about Oracle ADF Security, see Introduction to Oracle ADF in Developing Fusion Web Applications with Oracle Application Development Framework.
Figure 23-1 shows the relationship between a WebCenter Portal application deployment and its services, servers, portlets, portlet producers, its identity, credential and policy stores, and Oracle Enterprise Manager.
Figure 23-1 Basic WebCenter Portal Application Architecture

Description of "Figure 23-1 Basic WebCenter Portal Application Architecture"
The diagram in Figure 23-2 shows a basic WebCenter Portal application after deployment with its back-end server connections.
Figure 23-2 WebCenter Portal Application Architecture with Back-End Server Connections

Description of "Figure 23-2 WebCenter Portal Application Architecture with Back-End Server Connections"
The diagram in Figure 23-3 shows the security layers for a WebCenter Portal application.
Figure 23-3 WebCenter Portal Security Layers

Description of "Figure 23-3 WebCenter Portal Security Layers"
WebCenter Portal applications 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 Portal Application Security
WebCenter Portal provides support for:
-
Application role management and privilege mapping
-
Self-registration
-
Portal-level security management
-
External application credential management
WebCenter Portal Security Framework
The WebCenter Portal Security Framework provides support for:
-
Service Security Extension Framework (a common permission-based and role-mapping based model for specifying the security model for services)
-
Permission-based authorization
-
Role-mapping based authorization
-
External applications and credential mapping
ADF Security
ADF Security provides support for:
-
Page authorization
-
Task flow authorization
-
Secure connection management
-
Credential mapping APIs
-
Logout invocation, including logout from SSO-enabled configurations with Oracle Access Manager and Oracle SSO
-
Secured login URL for ADF Security-based applications (the adfAuthentication servlet)
Oracle Platform Security Services (OPSS)
OPSS provides support for:
-
Anonymous-role
-
Authenticated-role
-
Identity store, policy store, and credential store
-
Identity Management Services
-
Oracle Web Service Manager Security
-
Authorization
-
Policy and Credential Lifecycle
WebLogic Server Security
WebLogic Server Security provides support for:
-
WebLogic authenticators
-
Identity asserters
-
J2EE container security
-
SSL
Default Security Configuration
This section describes the security configuration that is in place when a WebCenter Portal application is deployed, and the configuration tasks that should be carried out after deployment:
Administrator Accounts
Although the WebCenter Portal application does not contribute any pre-seeded accounts, there are certain pre-seeded grants that are given to the default system administrator account (weblogic
) for the WebCenter Portal application. If your installation does not use weblogic
as the account name for the system administrator role, you must configure one or more other users for this role as described in Managing Users and Application Roles.
Note:
The weblogic
account is a system administrator account and should not be used to create user-level artifacts. The weblogic
account should only be used to create new user accounts in Fusion Middleware
Control.
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 Portal 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.
Default Identity and Policy Stores
By default, WebCenter Portal is configured to use a file-based embedded LDAP identity store to store application-level user IDs, and an Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later) 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 list of supported versions of identity store types, see Oracle Fusion Middleware 12c Certifications.
Caution:
The default file-based policy store should only be used for development, and only for single-node WebCenter Portal configurations. For enterprise deployments you must reassociate the policy and credential store with a database, or with an external LDAP-based store as described in Configuring the Identity Store.
The policy and credential stores can use either the default database store or Oracle Internet Directory 11gR1 or 10.1.4.3. 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 Securing Applications with Oracle Platform Security Services. For more information on reconfiguring the identity store and the policy and credential stores, see Configuring the Identity Store and Managing Users and Application Roles.
Note:
By default, discussions are configured to use the embedded LDAP identity store: All users in the embedded LDAP store can log onto the discussions server, and all users in the Administrators
group have administrative privileges on the discussions server.
If you reassociate the identity store with an external LDAP server, you must either move the system administrator account to the external LDAP (as described in 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 Migrating the Discussions Server to Use an External LDAP.
Both WebCenter Portal and Content Server must share the same LDAP server. For more information, see Configuring Oracle WebCenter Content to Share the WebCenter Portal Identity Store LDAP Server.
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 topics:
Permission-based Authorization
Permission-based authorization is used for tools, such as lists, where access control is implemented within the WebCenter Portal application using Oracle Platform Security Services (OPSS). WebCenter Portal 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 Portal, see Managing Security Across Portals.
Role-mapping Based Authorization
Tools and services that need to access "remote" (back-end) resources require role-mapping based authorization. For example, for discussions, role mapping is required when WebCenter Portal users (mapping to one or more application roles) must be mapped to another set of roles on the discussions server.
For example, in the WebCenter Portal application:
-
WebCenter Portal roles are mapped to corresponding roles on the back-end discussions server.
-
When a user is granted a new WebCenter Portal role, a similar grant (privilege) is granted in the back-end discussions server. For example, when user Pat is granted
Discussions-Create/Edit/Delete
permissions in WebCenter Portal, Pat is granted corresponding permissions in the back-end discussions server.
For more information, see Understanding Discussion Server Role Mapping.
Default Policy Store Permissions for WebCenter Portal
Out-of-the box, WebCenter Portal provides the following default roles:
Default application roles:
-
Administrator
-
Application Specialist
-
Portal Creator
-
Authenticated-User
-
Public-User
For more information about the default application roles, see Managing Security Across Portals.
Default role in a portal:
-
Portal Manager
Note:
The portal-level roles of
Participant
andViewer
are no longer created by default. In order to create portals faster and eliminate unneeded roles, there are fewer default portal-level roles created by default.
Default Code-based Grants
WebCenter Portal makes internal calls to APIs on the security platform that are secured with permission checks. Consequently, the 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).
Similarly, WebCenter Portal must pre-authorize access to various operations that it wants to expose using the WebCenter Portal permissions, and then invoke the OPSS APIs as privileged actions.
Post-deployment Security Configuration Tasks
After deploying WebCenter Portal, you should consider the following security-related configuration tasks for your site:
-
Reassociating the identity store to use an external LDAP
By default, WebCenter Portal uses an embedded LDAP for the 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 Configuring the Identity Store.
Note:
By default, WebCenter Portal's discussions server 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 the discussions server.If you reassociate the identity store with an external LDAP server, you must either move the system administrator account to the external LDAP (as described in 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 Migrating the Discussions Server to Use an External LDAP.
For WebCenter Portal, both the WebCenter Portal application and Content Server must share the same LDAP server. For more information, see Configuring Oracle WebCenter Content to Share the WebCenter Portal Identity Store LDAP Server.
-
Configuring SSO
Single Sign-On (SSO) lets users log in once across WebCenter Portal and components rather than having to log in for each sub-application (for example, to accessing a wiki page). 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 Portal supports four single sign-on solutions: Oracle Access Manager (OAM), Oracle Single Sign-on (OSSO), a SAML-based single sign-on solution, 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 Configuring Single Sign-On.
-
Configuring SSL
Secure Sockets Layer (SSL) provides additional security for connections between WebCenter Portal and 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 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.
Setting the Policy Store Refresh Interval and Other Cache Settings
This section provides recommended cache settings that should be configured after installation. Although settings for cache sizes and maximum group hierarchies should be based on your specific environment, the following sections provide recommendations that you can use as a starting point. For a complete list of tuning parameters and recommended values for WebCenter Portal, see Oracle WebCenter Portal Performance Tuning in Tuning Performance.
This section includes the following topics:
Setting the Policy Store Refresh Interval
The authorization policies used by WebCenter Portal use an in-memory cache with a default policy refresh time of 10 minutes. When a portal is created in a multi-node high availability environment, and you need a node failure to replicate the policy data more quickly, you can shorten the policy store refresh interval by modifying the domain-level jps-config.xml
file, and adding the following entry:
oracle.security.jps.ldap.policystore.refresh.interval=<time_in_milli_seconds>
This should be added to the PDP service node:
<serviceInstance provider="pdp.service.provider" name="pdp.service">
Note that the policy refresh interval should not be set to too small a value as the frequency at which the server cached policy is refreshed may impact performance.
After modifying the jps-config.xml
file, restart all servers in the domain. For more information, see Refreshing the Policy Cache in Securing Applications with Oracle
Platform Security Services.
Setting the Connection Pool Cache
This section describes the recommended settings for the connection pool cache.
To set the connection pool cache:
Setting User Cache Settings
This section describes the recommended settings for user cache settings.
To set user cache settings: