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:
Section 23.1, "Introduction to WebCenter Application Security"
Section 23.3, "Troubleshooting Security Configuration Issues"
The content of this chapter is intended for Fusion Middleware administrators (users granted the Admin
role through the Oracle WebLogic Server Administration Console). Users with the Monitor
or Operator
roles can view security information but cannot make changes. See also, Section 1.8, "Understanding Administrative Operations, Roles, and Tools."
The 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
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
The diagram in Figure 23-3 shows the security layers for the WebCenter Spaces application.
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 provides support for:
Service Security Extension Framework
Permission-based authorization
Role-mapping based authorization
External applications and credential mapping
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)
Anonymous-role support
Authenticated-role support
Identity store, policy store, and credential store
Identity Management Services
Oracle Web Service Manager Security
WebLogic Server Security provides support for:
WebLogic authenticators
Identity asserters
J2EE container security
SSL
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:
Section 23.2.2, "Application Roles and Enterprise Roles in WebCenter Spaces"
Section 23.2.4, "Default Policy Store Permissions and Grants"
Section 23.2.5, "Post-deployment Security Configuration Tasks"
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."
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.
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, and OVD 11gR1 with the Local Store Adapter (LSA).
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 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."
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.
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:
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."
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."
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. |
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.
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.This section includes the following sub-sections:
Section 23.3.1, "Webcenter Spaces Does Not Find Users in LDAP Provider"
Section 23.3.2, "Group Space Gets Created with Errors When Logged in as OID User"
Section 23.3.3, "Users Cannot Self-Register when WebCenter Spaces Configured with Active Directory"
Section 23.3.4, "User Made Administrator Does Not Have Administrator Privileges"
Section 23.3.5, "OmniPortlet Producer Authorization Exception in SSO Environment"
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.
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.
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>
".
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:
Edit <MIDDLEWARE_HOME>/user_projects/domains/WebCenter/config/fmwconfig/jps-config.xml
.
Add this line in the general properties:
<property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/>
Restart the WLS_Spaces
server.
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
."
To fix the problem:
Set the user name attribute to sAMAccountName
while configuring Active Directory in the WebLogic Administration Console.
Use the HTTPS port of the LDAP and enable the SSL checkbox while configuring Active Directory in the WebLogic Administration Console.
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.
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
.
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.
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="*")