23 Managing Security

This chapter provides an introduction to securing custom WebCenter applications, and describes the security configuration that is in place when custom WebCenter 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:

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

23.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 23-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 23-1 Basic WebCenter Application Architecture

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

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

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

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

The diagram in Figure 23-3 shows the security layers for the WebCenter Spaces application.

Figure 23-3 WebCenter Spaces Security Layers

Description of Figure 23-3 follows
Description of "Figure 23-3 WebCenter Spaces Security Layers"

The security layers for a custom WebCenter application could have the same four bottom layers (WebCenter Security Framework, ADF Security, OPSS, and WebLogic Server Security) depending on how the application was structured. The application layer will, of course, depend on the implementation.

WebCenter Spaces Application Security

WebCenter Spaces provides support for:

  • Application role management and privilege mapping

  • Self-registration

  • Group space security management

  • Account management

  • External application credential management

WebCenter Security Framework

WebCenter Security Framework provides support for:

  • Service Security Extension Framework

  • 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 support

  • Authenticated-role support

  • Identity store, policy store, and credential store

  • Identity Management Services

  • Oracle Web Service Manager Security

WebLogic Server Security

WebLogic Server Security provides support for:

  • WebLogic authenticators

  • Identity asserters

  • J2EE container security

  • SSL

23.2 Default Security Configuration

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

23.2.1 Administrator Accounts

Custom WebCenter 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 24.6, "Granting the WebCenter Spaces Administrator Role to a WebCenter Spaces User."

23.2.2 Application Roles and Enterprise Roles in WebCenter Spaces

Application roles and permissions are defined within WebCenter Spaces and are stored in an application-specific stripe of the policy store. Consequently, WebCenter Spaces roles apply only to WebCenter Spaces; WebCenter Spaces roles and permissions do not extend to other applications.

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 the application 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 WebCenter Spaces.

Within WebCenter Spaces 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.

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

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 (such as Oracle Internet Directory) as described in Chapter 25, "Configuring the Policy and Credential Store."

The policy store can only be configured to use Oracle Internet Directory 11gR1 and 10.1.4.3. When using an external LDAP-based store, the credential store and policy store must be configured to use the same LDAP server.

The identity store can be configured to use the following LDAP servers:

  • Oracle Internet Directory (OID) 11gR1 and 10.1.4.3

  • Oracle Virtual Directory (OVD) 11gR1 and 10.1.4

  • Sun iPlanet version 4.1.3

  • Active Directory shipped as part of Windows 2000

  • Open LDAP version 2.0.7

  • Novell NDS version 8.5.1

For more information on reconfiguring the identity, policy and credential stores, see Chapter 24, "Configuring the Identity Store" and Chapter 25, "Configuring the Policy and Credential Store."

Note:

Oracle WebCenter Discussions requires an external LDAP-based identity store. Consequently, if you want to use the Discussions service (which relies on Oracle WebCenter Discussions) you must reassociate the identity store with one of the external LDAP servers listed above.

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

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

23.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:

23.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 Section 34.3, "Managing Application Roles and Permissions."

23.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:

  • Default application and group space roles for WebCenter Spaces are mapped to the corresponding service roles. For default mappings, see Table 34-4 and Table 34-5.

  • When a new user is granted an application or group space role, a similar grant (privilege) is granted in the back-end server. For example, when user Pat is granted Discussions-Manage permissions in WebCenter Spaces, Pat is granted corresponding permissions in the back-end discussion server. See also, Section 34.1.4, "Understanding Discussions Server Role and Permission Mapping."

23.2.4.3 Default Policy Store Permissions for WebCenter Spaces

The tables in this section describe out-of-the-box permissions and roles for WebCenter Spaces:

  • Table 23-1 shows the default permissions for pre-seeded application roles in the WebCenter Spaces policy store. Application roles determine what users can do in their personal space.

  • Table 23-2 shows the default permissions for group space roles that come pre-seeded with out-of-the-box group space templates: Community of Interest (COI), Group Project, Blank. When a new group space is created, these group space roles and their corresponding permissions are added to the policy store at runtime.

Table 23-1 Default Application Roles and Permissions in WebCenter Spaces


 Default Application Roles
Permissions Administrator Spaces-User Public-User

Application

      

Manage

✔

    

Configure

✙

    

View

✙

✔

✔

Group Spaces

      

Manage

✔

    

Configure

✙

    

View

✙

    

Create

✙

✔

  

Group Space Templates

      

Manage

✔

    

View

✙

    

Create

✙

✔

  

Pages

      

Manage

✔

    

Delete

✙

    

Edit

✙

    

Personalize

✙

    

View

✙

    

Create

✙

✔

  

Discussions

      

Manage

✔

    

Links

      

Manage

✔

    

Delete

✙

    

Create

✙

    

People Connections

      

Manage

✔

    

Edit

✙

✔

  

Share

✙

✔

  

Table 23-2 Default Group Space Roles and Permissions in WebCenter Spaces

Default Roles Moderator Participant Viewer Spaces-User Public-User
Template COI Project Blank COI Project Blank COI Project Blank

Group Space Access

Manage

✔

✔

✔

                

Configure

✙

✙

✙

                

View

✙

✙

✙

✔

✔

✔

✔

✔

✔

    

Group Space Services(Pages, Events, Links, Lists, Notes)

Manage

✔

✔

✔

                

Design

✔

✔

✔

  

✔

✔

          

Contribute

✔

✔

✔

✔

✔

✔

          

View

✔

✔

✔

✔

✔

✔

✔

✔

✔

    

Announcements

Manage

✔

✔

              

n/a

  

Edit

✙

✙

  

✔

✔

        

n/a

  

View

✙

✙

  

✔

✔

  

✔

✔

  

n/a

  

Discussions

Manage

✔

✔

              

n/a

  

Edit

✙

✙

  

✔

✔

        

n/a

  

View

✙

✙

  

✔

✔

  

✔

✔

  

n/a

  

Documents

Manage

✔

✔

              

n/a

  

Delete

✔

✔

  

✔

✔

        

n/a

  

View

✔

✔

  

✔

✔

  

✔

✔

  

n/a

  

Create

✔

✔

  

✔

✔

        

n/a

  

Legend Description
✔ Shows an explicitly granted permission or action.
✙ Shows an implied permission because of an explicitly granted permission. The permission implementation itself does the implication.

23.2.4.4 Default Code-based Grants

WebCenter applications make internal calls to APIs on the security platform that are secured with permission checks. To facilitate this, 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), and CRUD on application roles. In the case of WebCenter Spaces, CRUD permission are granted by default, out of the box.

Similarly, WebCenter applications must pre-authorize access to various operations that it wants to expose using the WebCenter permissions (described in Table 23-1 and Table 23-2), and then invoke the OPSS APIs as privileged actions.

23.2.5 Post-deployment Security Configuration Tasks

After deploying your custom WebCenter 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 24, "Configuring the Identity Store."

    Note:

    Oracle Content Server and Oracle WebCenter Discussions rely on external LDAP-based identity stores. Consequently, if you want to use the Documents service (which relies on Oracle Content Server) or the Discussions service (which relies on Oracle WebCenter Discussions) you must reassociate the identity store to use an external LDAP server. For more information on reconfiguring the identity store, see Chapter 24, "Configuring the Identity Store."

  • Reassociating the policy store to use an external LDAP

    By default, custom WebCenter applications use a file-based system-jazn-data.xml policy store to store policy grants. You should consider using an LDAP-based policy store. For information on how to configure the policy store to use an LDAP server, see Chapter 25, "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 application and the set of producers it consumes, it helps ensure the security of the information being published by the WebCenter 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 28, "Configuring WS-Security for WebCenter Applications and Components."

  • 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 26, "Configuring WebCenter Applications and Components to Use SSO."

  • 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 27, "Securing WebCenter Applications and Components with 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.

23.3 Troubleshooting Security Configuration Issues

This section includes the following sub-sections:

23.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 24, "Configuring the Identity Store." Restart the Administration Server and Managed Servers for the domain.

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

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

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

23.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.12.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="*")