Setting Up External Security

13 Setting Up External Security

Security standards help organizations to prevent compromise of important information. WebCenter Sites provides you with robust security features to protect your data and attributes through security protocols, encryption of assets, and REST security.

The following topics describe implementing security protocols.

Setting Up External Security

Before the developers start coding templates and designing asset types, , you must decide with them on how to configure security on both the management and the delivery systems.

The following topics provide information about implementing and testing security on the WebCenter Sites systems:

Introduction to WebCenter Sites Security

Before developers design the online site or make changes to the user interface on the management system, you must implement your security protocols. The decisions you make about security configuration affects the way that you develop your online site.

At regular intervals, you should review your systems to determine whether they are working properly. The following figure shows an example of a secure WebCenter Sites system.

Figure 13-1 WebCenter Sites System

Description of "Figure 13-1 WebCenter Sites System"

The following topics provide overview information about the WebCenter Sites security measures available to you:

Understanding ACLs and Security

ACLs (access control lists) serve as the foundation of the security and user management model in your WebCenter Sites system. ACLs are sets of permissions that restrict access to both database tables and WebCenter Sites pages.

ACL restrictions are enforced only when the cc.security and the security.checkpagelets properties in the wcs_properties.json file are set to true. These properties are set to true by default. If you have to disable security for any reason, open the Property Management Tool from the Admin interface and set the cc.security property to false. However, Oracle recommends that you keep this property set to true on all systems to ensure that site development is designed to work with security enabled.

When planning security measures for your system, examine the list of default ACLs (described in System Defaults), and determine whether you require additional ACLs. You may have to create an ACL with a different combination of permissions than any of the system ACLs if your developers plan to create tables or make additions to the user interface.

Note:

Under no circumstances should you modify a system default ACL or modify the ACLs assigned to a WebCenter Sites system table or a WebCenter Sites content application table.

Understanding DefaultReader, secure.CatalogManager, and secure.TreeManager

WebCenter Sites and the WebCenter Sites content applications are delivered with several default user accounts. The DefaultReader account is assigned to all unauthorized site visitors (because anyone who visits a site hosted by WebCenter Sites must have a WebCenter Sites user identity).

By default, the DefaultReader user account has the following ACLs: Browser and Visitor. Visitor enables the tracking of visitors for demographic purposes. Security issues arise because many of the database tables also have the Browser ACL assigned to them, and various Oracle WebCenter Sites: Engage tables are assigned the Visitor ACL. Therefore, anyone using the DefaultReader account can examine information in the tables, although they cannot write to the tables as this user. To prevent someone from using the DefaultReader user account to view tables in your WebCenter Sites database, use the Property Management Tool in the Admin interface to set the following properties in the wcs_properties.json file to true:

secure.CatalogManager
secure.TreeManager

When these properties are set to true, the DefaultReader user cannot access the CatalogManager and TreeManager servlets—not even for read-only data.

Note:

For more information about permissions that are associated with each ACL, see Table 39-3. For more information about the descriptions of the ACLs, see Table 39-4.

Understanding BlobServer and Security

When you want to implement security for your blobs you must enable the security feature for the BlobServer servlet. You do this by using the Property Management Tool in the Admin interface to set the bs.security parameter in the wcs_properties.json file to true.

When bs.security=true, BlobServer refuses to serve a blob unless the URL for the blob contains evidence that the person requesting it has been authenticated as a valid user. What evidence? A value in the URL from the csblobid parameter whose value matches a session variable named csblobid. Therefore, when BlobServer security is enabled, your developers must code links to blobs differently than usual.

To protect the blob header names from being vulnerable, provide valid blob header names in the bs.validheadernames parameter in the wcs_properties.json file. Once this property value is set, it doesn't allow the user or hacker to inject any more blob header names through URL parameters. If this property's value is left empty, it allows all values for blob header names through URL parameters and might lead to HTTP header injection vulnerability.

For web pages that are stateless, that is without any session id, use Vanity URLs. Vanity URLs make it possible for images to have friendly links without query parameters. See Configuring Vanity URLs.

Implementing Security Goals

Typically, you have a different set of security goals for each of your WebCenter Sites systems: the development, management, and delivery systems.

See the following topics for information about implementing security on each WebCenter Sites system:

Implementing Security Goals for the Development System

Even though development systems are commonly behind firewalls, you should implement the same security configuration on the development system that is in place on the system the developers are designing for (management or delivery). This ensures the code will work properly on the target system, because the same conditions exist on both systems:

When you plan to use BlobServer security on the delivery system, templates that create URLs for blobs must be coded differently. Therefore, you must enable BlobServer security on the development system as well.
If your online site will require that visitors identify themselves, you must have the same security configuration in place on the development system that you will use on the delivery system.

Implementing Security Goals for the Management System

Security on the management system encompasses two main concepts:

Ensuring that only valid users can access the system (described in this chapter).
Ensuring that those valid users can access only the functions that are appropriate for them.

Implementing Security Goals for the Delivery System

The precautions that you take on the delivery system are more stringent by nature because when you deliver a site to the public, you must ensure that while visitors can access the content on your site, hackers cannot access areas that you do not want made public.

When you configure your delivery system, you disable the user interfaces to prevent anyone from adding assets or code through the interfaces or with any of the developer tools. Additionally, you restrict access to some servlets.

Implementing Security

The following topics describe configuring security measures: setting properties, changing passwords for default user accounts, using SSL for systems accessible outside your company's network, mapping URLs for specific WebCenter Sites servlets, and disabling certain parts of the applications on the delivery system.

Each topic states which steps should be performed on which system or systems.

Using Properties to Configure Security Settings

The properties that implement various kinds of security are located in the WebCenter Sites wcs_properties.json file.

Use the Property Management Tool to verify that the following properties are set to true:

cc.security
security.checkpagelets
secure.CatalogManager
secure.TreeManager
contentsecurity.enabled

If you plan to use BlobServer security, set bs.security to true.

To ensure that the session timeout value is appropriate for each system, set the cs.timeout property as follows:

On the development and management systems, set the timeout value for if you think that you safely can.
On the delivery system, set the timeout value for as short a time as you can without frustrating your visitors. Also, ensure the following:
- Remove the entire futuretense_cs directory from the web server. Do not remove it from the application server. If you do, use the Property Management Tool to set the cs.wrapper property in the wcs_properties.json file to false (the wrappers are the HTML files from that folder). If you forget, visitors on the site will see "404 Page Not Found" rather than system error messages.
- Go to SiteCatalog/OpenMarket/Xcelerate/UIFramework and rename all of the pages. At the very least, rename LoginPage and LoginPost.

In addition, there is one more property to specify for the delivery system: cs.wrapper. Wrappers are the HTML files located in the futuretense_cs directory on the web server. Also included in that directory is a subdirectory named Dev, which you should remove from your delivery system. However, if you decide to remove the entire futuretense_cs directory from the web server on the delivery system, you must set the cs.wrapper property to false.

Working with Users and Passwords

Be sure that the default user accounts were made secure after WebCenter Sites was installed on all systems. Oracle recommends using OAM and LDAP for strong user accounts and password policies.

Complete the following steps on all systems—development, management, and delivery:

Change the default password for the fwadmin user account (in the General Admin tree in the Admin interface, expand the Admin node, expand the User Access Management node, and then double-click Users).
Change the default administrator user name/password for your application server.
Change the default administrator user name/password for your web server.
If you have the sample sites installed, a mirror user was created for the Mirror to Server publishing method (username: mirroruser). Change the password for this user.
For any user accounts that have the SiteGod ACL, change the password frequently (in the General Admin tree in the Admin interface, expand the Admin node, expand the User Access Management node, and then double-click User). Handle any user account that has the SiteGod ACL as you would the UNIX root user.

Note:

Do not change the default password for the DefaultReader user.

If any of the sample sites except avisports or FirstSiteII were installed on either the management or delivery systems, delete all the sample users including editor, but do not delete the xceleditor ACL and do not delete the fwadmin user. Additionally, change the password for the mirroruser user.

Do not assign the xceleditor ACL to any user on the delivery system other than the system administrator of that system. This ACL allows access to the WebCenter Sites content applications if they are installed on that delivery system.

Working with SSL and Digital Certification

For any system accessible outside your company's network or containing proprietary data, such as a management system open to remote employees, it is recommended to use SSL to establish a secure, encrypted connection.

You must use a digital certificate approved by a trusted authority rather than a self-signed certificate. Using a self-signed certificate can have the following consequences:

Internal calls to the system made through Java may fail.
Some features of the user interface may not function correctly, for example, the left-hand navigation tree or publishing.

Working with URLs and the Web Server (Delivery System Only)

On the web server of the delivery system, be sure to give access to the following servlets only. Map only their URLs to the application server:

ContentServer
BlobServer
Satellite
CookieServer

Do not map URLs to the application server for any of the other servlets. Instead, map the URLs for the following servlets to an error page such as the 404 Not Found page:

HelloCS
CatalogManager
TreeManager
DebugServer
CacheServer
Inventory

Working with WebCenter Sites Forms and Pages (Delivery System Only)

On the delivery system, be sure to disable or completely remove the following pieces of the applications:

Remove the entire futuretense_cs directory from the web server. Do not remove it from the application server. If you do, use the Property Management Tool to set the cs.wrapper property in the wcs_properties.json file to false (the wrappers are the HTML files from that folder). If you forget, visitors on the site will see "404 Page Not Found" rather than system error messages.
Go to SiteCatalog/OpenMarket/Xcelerate/UIFramework and rename all of the pages. At the very least, rename LoginPage and LoginPost.

Testing Security

After you have implemented your security measures, test your systems.

Complete the following steps on your development, management, and delivery systems:

Ensure that you modify the passwords for the user accounts DefaultReader, ContentServer, editor, and fwadmin.
After you log in using the DefaultReader user account, set the properties secure.CatalogManager and secure.TreeManager to true.
Verify that the sample site users do not exist on the management or delivery systems.

Verify that you cannot log in with ContentServer/password using a CatalogManager URL:

http://<server>:<port>/<context>/CatalogManager?ftcmd=login&username=ContentServer&password=<password>

Verify that you cannot flush the entire cache as ContentServer/password using a CacheServer URL:

http://<server>:<port>/<context>/CacheServer?all=true&authusername=ContentServer&authpassword=password

Verify that you cannot log in to the application server as the default administrator user.
Verify that you cannot log in to the database as the default administrator user.
Verify that you cannot log in to the web server as the default administrator user.

Implementing Cryptography and Encryption Key Security

With WebCenter Sites, you can use secure server access to protect your system from security attacks. All access to assets is protected through cryptographic encryption.

WebCenter Sites Security Overview

secures the system by default and provides several options to further tighten security to meet your installation's requirements.

The system comes installed with a secured key store that provides the necessary encryption keys to properly handle passwords and data exchanges across the network through encryption techniques. This ensures that sensitive information is not visible to unauthorized individuals which could compromise the security of your system.

supports the Oracle Platform Security Services (OPSS) credential store for increased security. This credential store facility uses Oracle's advanced cryptography to create and maintain symmetrical encryption keys. The credential store location is identified by a properly configured JPS (Java Platform Security) provider. Access and modification of the credential store is protected by JPS permissions. Only authorized programs are permitted to access the credential store for reading, modification, or both.

For components that require cryptographic support across application server contexts or systems or both, the same encryption keys must be available. In other words, a data value encrypted at one location must be decrypted using the same key at the destination location. You must use copies of the central key store at each place where encryption and decryption are necessary.

About Security Configurations in WebCenter Sites

Configuration of the security is controlled by the SitesSecurityContext.xml configuration file. This file must reside on the classpath of external programs that require access to OPSS credential store (see OPSS documentation for configuration details). uses a standard naming convention for associating encryption keys to different functions within the product. There is not a single encryption key used in all cases. This permits changing the key by functional use at any time without affecting other functions. For any key store type, these four associative names are used:

masterkey – reserved for future use
tokenskey – the encryption key used by the token generator
generalkey – the encryption key used for all encrypted POST exchanges and sensitive information located in external files
passwordkey – the encryption key used when the user password in the database is encoded by symmetrical encryption

To enhance security, the set of four encryption keys is unique for every installation of .

Oracle Credential Store Facility (CSF) is a very secure key storage facility that is accessed through Java Platform Security (JPS). This facility can be used across all environments. It is not provider specific, as it is an integral part of Oracle security. Only symmetrical encryption keys created by Oracle OSDT (Oracle Security Developer Tools) can be stored in this facility. In the WebLogic environment, this credential store is protected by JPS permissions. Programs that access or manipulate contexts of the credential store must be granted permission. Those programs which do not have the proper permission are denied access. For situations requiring the highest level of security, this is the preferred option.

About the SitesSecurityContext.xml Configuration File

The SitesSecurityContext.xml file controls all aspects of the security environment which and its related utilities operate within. It is a Spring configuration file which instantiates the implementation classes for cryptography, encryption key storage, CSRF token generation, and internal security processing within the server. It is an integral part of security between the various system components.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

     <!-- Crypto support package -->
     <!-- Default Crypto package for WebLogic -->
     <bean id="cryptoPackage" class="com.fatwire.security.common.OracleSecurityCrypto" />

      <!-- Credential store support package -->
      <!-- Default Credential Store for WebLogic -->
      <bean id="credentialPackage" class="com.fatwire.security.common.WeblogicCredentialStore" >
          <property name="securityMetaInfo" ref="securityMetaInfo" />
      </bean>

     <!-- CSRF Token generation/validation package -->
     <bean id="tokenPackage" class="com.fatwire.auth.SecurityTokenImpl" >
     </bean>

     <bean id="securityMetaInfo" class="oracle.fatwire.security.common.SecurityMetaInfo" >
         <property name="uniquePrefix" value="Sites" />
     </bean>
	
     <!-- Security Basis -->
     <bean id="securityBasis" class="com.fatwire.security.common.SecurityBasis" >
		    <property name="securityCrypto" ref="cryptoPackage" />
		    <property name="securityToken" ref="tokenPackage" />
		    <property name="credentialStorage" ref="credentialPackage" />
         <property name="securityMetaInfo" ref="securityMetaInfo" />
     </bean>
		
     <!-- Security Context -->
     <bean id="securityContext" class="COM.FutureTense.Security.Context.AdvancedSecurityContextImpl" >
		    <property name="securityBasis" ref="securityBasis" />
		    <property name="convertCredentials" value="true" />
     </bean>
		
</beans>

The SitesSecurityContext.xml file is broken down into five beans; three are mandatory (cryptoPackage, credentialPackage, and securityBasis) and two used only by the server (tokenPackage and securityContent). When modified, the revised file must be placed on the classpath of all components that require it.

The beans in this file are described as:

cryptoPackage – this bean specifies which cryptographic package is initialized.
- com.fatwire.security.common.OracleSecurityCrypto – using OSDT. This cryptography package must be specified if the Oracle Credential Store Facility is to be used.
credentialPackage – this bean specifies which key storage is initialized.
- com.fatwire.security.common.WeblogicCredentialStore – WebLogic specific CSF implementation.
tokenPackage –this bean is required for the server only. The class keyword selects the proper class implementation (default is com.fatwire.auth.SecurityTokenImpl). You have the option to implement your own security token generator which implements the securityToken interface.
securityMetaInfo – This bean is required to specify a prefix for an application that uses the credential store. The prefix is added to keys and passwords so that different applications can use the same credential store. The prefix for WebCenter Sites is Sites.
securityBasis –this bean binds all security components together and is not to be modified. The property entries refer to other bean definitions. The securityToken property is only specified on the server.
securityContext – this bean is required for server only. It defines the class which handles all internal security processing. This bean is not to be modified.

This file must be available on the classpath for each application that requires cryptographic encryption and access to a key store facility. Copies of this file must be configured with the same cryptography and credential store packages for the applications that require access to OPSS credential store (see OPSS documentation for configuration details).

Working with WebCenter Sites Security Utilities

There are several utilities available with the WebCenter Sites system to aide in the creation and maintenance of encryption key storage. These utilities are located in site-security.jar and are executed by calling by the specific class names from the Java command. When running, it is necessary to define the classpath for all the necessary jars required by the utilities.

Any Java SE environment trying to access Weblogic CSF for getting keys needs to be setup for some configuration stated as follows, and the programs that access or manipulate contexts of the credential store must be granted permission.

Create folders called config, fmwconfig and lib. Place the following files in the folders created.

config: ‘java.policy’(<weblogic_Home_Path>\oracle_common\modules\oracle.jps\domain_config\jse) 'SitesSecurityContext.xml'(from config of Sites)
fmwconfig: 'bootstrap', 'keystores.xml' and 'jps-config-jse.xml' (<weblogic_Home_Path>\user_projects\domains\<domain_name>\config\fmwconfig)
lib: The JARS mentioned below need to be here. You can get the JAR files at WEB-INF/lib under the deployed sites instance or at ${ORACLE_HOME}/wcsites/webcentersites/sites-home/lib.

The following is a sample shell script that runs a utility class when the class name is supplied as the first argument:

#!/bin/sh
# Set JAVA_HOME 
JAVA_HOME="/fmw/jdk/bin"
# Set CLASS_PATH 
weblogicPath=<Path to weblogic>
fmwConfigPath=./fmwconfig
oracleCommonPath=${weblogicPath}/oracle_common
oracleJps=${oracleCommonPath}/modules/oracle.jps

jpsConfigPath=${fmwConfigPath}/jps-config-jse.xml
javaPolicy=./config/java.policy

jpsManifestJar=${oracleJps}/jps-manifest.jar


javaOpts=-cp .:./config
javaOpts=${javaOpts}:./lib/sites-security.jar

javaOpts=${javaOpts}:${jpsManifestJar}
javaOpts=${javaOpts}:./lib/commons-codec-1.7.jar
javaOpts=${javaOpts}:./lib/commons-configuration-1.9.jar
javaOpts=${javaOpts}:./lib/commons-lang-2.5.jar
javaOpts=${javaOpts}:./lib/commons-logging-1.1.3.jar
javaOpts=${javaOpts}:./lib/log4j-1.2.17.jar
javaOpts=${javaOpts}:./lib/quartz-2.2.1.jar
javaOpts=${javaOpts}:./lib/sites-request-authenticator.jar
javaOpts=${javaOpts}:./lib/sites-cs.jar
javaOpts=${javaOpts}:./lib/spring-core-4.3.0.RELEASE.jar
javaOpts=${javaOpts}:./lib/xercesImpl-2.11.0.jar
javaOpts=${javaOpts}:./lib/xml-apis-1.4.01.jar
javaOpts=${javaOpts}:./lib/javaee-api-7.0.jar


$JAVA_HOME/java ${javaOpts} -Doracle.security.jps.config=${jpsConfigPath} -Dcommon.components.home=${oracleCommonPath} -Djava.security.policy=${javaPolicy} com.fatwire.security.util.$1 $2 $3

Description of Java Classes

com.fatwire.security.util.CreateDefaultCredentialStore: This utility populates the OPSS store with a randomly generated set of Oracle encryption keys. The replace argument should be set to yes if the utility should replace any WebCenter Sites encryption keys that exist.

Arguments

product=sites

replace=no | yes (default is no)

com.fatwire.security.util.ExportFromCSF extracts the salts for each of the WebCenter Sites keys in the current store and writes the values to the export.keys file in the working directory. The export file is used as input to an import utility program listed below.

Arguments: (optional)

export.keys

com.fatwire.security.util.ImportToCSF.class takes the extracted salts from the export.keys file, creates each of the WebCenter Sites encryption keys using the associated salt, and adds to the output credential store. The output credential store is defined by the location property in the jps-config.xml.

Arguments:

product=sites

import=export.keys

replace=no | yes (default is no)

Working with ESAPI Security Validation

The server employs the Enterprise Security API to check for and prevent security vulnerabilities that could occur from injection of malicious web data. The validation expressions contained in the ESAPI.properties file can be modified - this file is in the WEB-INF/classes folder when you install the server.

Further information about ESAPI is available at https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API.

Using REST Security

Through REST security, you can authenticate users to access assets and manage different roles of users with respect to application resources.

The following topics provide information about REST security:

REST Authorization

REST authorization grants privileges to perform REST operations on application resources which map to objects in WebCenter Sites. REST authorization uses the "deny everything by default" model. If a privilege is not explicitly granted to a particular group, that privilege is denied. General administrators are responsible for authorizing users after the application is deployed and registered with the WEM Framework.

The following topics provide information about REST authorization:

Security Model

The security model is based on objects, groups, and actions. Objects and groups are predefined in (objects in map to REST resources in the Framework). Actions are privileges (READ, CREATE) that you create in . You must configure security per object type in the Admin interface:

Figure 13-2 Add New Security Configuration Form

Description of "Figure 13-2 Add New Security Configuration Form"

An object is any entity such as a site, a user, or an asset. Protected objects are of the following types:
- Asset Type
- Site
- User Locale
- Application
- Asset
- Role
- ACL
- Index
- User
- Group
Security groups are used to manage multiple user's permissions to operate on objects.
Objects of a given type are accessible to a user only if the user belongs to at least one group with privileges to perform specified actions on objects of the given type.
An action is a security privilege: LIST, HEAD, READ, UPDATE, CREATE, DELETE. Groups are assigned privileges to operate on the objects allowed to the groups. Some objects, such as ACLs, are list-only (they are created directly in , but not over REST).

A security configuration is an array that specifies:

The protected object type and objects
Groups that are able to access the objects
Actions that groups (and their members) can perform on the objects

Privilege Resolution Algorithm

When configuring a security privilege, you can specify that the privilege applies to all objects of a certain type or a single object of a certain type. For example, granting the privilege to UPDATE (POST) any site allows users in the group to modify the details of all sites in the WEM Framework. Granting the privilege to UPDATE (POST) the avisports site allows users in the group to modify avisports site details in WEM.

The Asset object type requires you to specify the site to which the security setting applies, because assets are always accessed from a particular site. You can refine the AssetType object type by specifying a subtype. For example, if you set the DELETE privilege on asset type Content_C, you perform a DELETE request on the REST resource /types/Content_C (that is, to delete the Content_C asset type from the system).

Because you can grant privileges to groups only, the total privileges for a user are not obvious until they are computed across all of the groups to which the user belongs. The WEM Framework provides a privilege resolution algorithm. Its basic steps are listed below:

REST finds the groups in which the user has membership.
REST determines which groups can perform which REST operations on which REST resources. If site or subtype is specified, each is taken into account.
REST compares the results of steps 1 and 2. If at least one group from step 1 is in the list of groups from step 2, then access is granted. Otherwise, access is denied.

Authorizing Users to Access Application Resources

Before authorizing users to access application resources, see REST Authorization for background information relating to the steps provided in the following topics:

Viewing REST Security Configurations
Creating a Group
Adding Users to a Group
Configuring Security for REST Resources.

Note:

To configure security for REST resources, you must assign privileges to groups. To view the list of groups, continue with Viewing REST Security Configurations. To create groups, see Creating a Group.

Viewing REST Security Configurations

A security configuration identifies which groups have which permissions to which REST resources. WebCenter Sites defines security configurations for two default groups. They are RestAdmin and SiteAdmin_AdminSite.

To view REST security configurations:

Log in to the Admin interface as a general administrator.
In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, and then double-click Configure Security.

The Security Configurations window opens in the main window.

Figure 13-3 Security Configuration Form

Description of "Figure 13-3 Security Configuration Form"
Depending on your requirements, continue as follows:
- To create a group, see Creating a Group.
- To add users to a group, see Adding Users to a Group.
  
  Note:
  
  To complete this step, ensure that the required groups exist. You must assign privileges to the groups.
- To configure security privileges for REST resources, see Configuring Security for REST Resources.

Creating a Group

Log in to the Admin interface as a general administrator.
In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Groups node, and then double-click Add New.
In the Add New Group form, enter a name and brief description about the group you want to create.
Click Save.

The group you created is now listed under the Groups node.
Now that you have created a group, you can:
- Add users to the group.
- Configure REST security for the group.

Adding Users to a Group

Add users to a group to determine the permissions that they will have to operate on REST resources associated with applications.

Log in to the Admin interface as a general administrator.
In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Assign Users to Groups node, and then double-click Add New.
In the Assign Groups to User form, select users and assign them to any combination of the listed groups.

Figure 13-4 Assign Groups to User Form

Description of "Figure 13-4 Assign Groups to User Form"

Note:

If the user you want to assign to the group is not listed, that user is a member of a group. To assign the user to another group, see step 5.
Click Save.

The user names you selected are listed under the Assign Users to Groups node. To view the groups that include a particular user, double-click the user name.
(Optional). If the name of the user you want to assign to a given group is not displayed in the User Name field, do the following:
1. In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand Assign Users to Groups, and then double-click the name of the user you want to assign to another group.
2. In the Inspect form, click Edit to open the Edit User Groups form.
3. In the Groups field, select the groups to which you want to assign the user, and then click Save.
Now that you have added users to a group, you can do the following:
- Create a group. For more information, see Creating a Group.
- Configure security for a group. For more information, see Configuring Security for REST Resources.

Configuring Security for REST Resources

When configuring security, you specify which object types and objects must be accessible to groups, and which actions the groups can perform on the objects.

To configure security for REST resources:

Log in to the Admin interface as a general administrator.
In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.
In the Add New Security Configuration form, set security for object types and objects.

The following tables show a summary of possible security configurations.

Table 13-1 Available Actions (Security Privileges)

Action	Description
Create	Group members can create specified resources.
Delete	Group members can delete specified resources.
List	Group member can retrieve specified resources.
Read/Head	Group members can read specified resources. Read returns the requested resources. Head returns metadata describing the requested resources.
Update	Group members can modify specified resources. Note: Create and Update are each paired with the Read/Head privilege. Assigning one of these privileges to a group automatically assigns the Read/Head privilege to the group.

Table 13-2 Summary of Possible Security Configuration Options

Object Type	Name	Subtype	Site	Possible Actions
ACLs	Any	N/A	N/A	List
Application (see note 1)	Any	N/A	N/A	Create, Update, Delete
Application	AppName	N/A	N/A	Update, Delete
Asset	Any	N/A	Any	List, Read/Head, Create, Update, Delete
Asset	Any	N/A	SiteName	List, Read/Head, Create, Update, Delete
Asset	AssetType	N/A	SiteName	List, Read/Head (see note 2), Create, Update, Delete
Asset	AssetType and AssetName	N/A	SiteName	Read/Head, Update, Delete
AssetType	Any	N/A	N/A	List, Read/Head, Create, Delete
AssetType	AssetType	N/A	N/A	Read/Head, Delete
AssetType	AssetType	Any	N/A	List
AssetType	AssetType	Subtype	N/A	Read/Head
Group	Any	N/A	N/A	List
Group	GroupName	N/A	N/A	Read/Head
Index	Any	N/A	N/A	List, Read/Head, Create, Update, Delete
Index	IndexName	N/A	N/A	Read/Head, Update, Delete
Role	Any	N/A	N/A	List, Read/Head, Create, Update, Delete
Role	Role	N/A	N/A	Read/Head, Update, Delete
Site	Any	N/A	N/A	List, Read/Head (see note 3), Create, Update, Delete
Site	SiteName	N/A	N/A	Read/Head, Update, Delete
User	Any	N/A	N/A	List, Read/Head, Create, Update, Delete
User	UserName	N/A	N/A	Read/Head, Update, Delete
UserDef	Any	N/A	N/A	List
UserLocales	Any	N/A	N/A	List

See REST Security Configuration Reference for configuring the different object types.

Note:

For an example of setting security for applications, see step 3.
READ allows reading associations on the named site.
READ allows reading users and asset types on the named site.

REST Security Configuration Reference

The following reference topics support Table 13-2. The topics provide details of the tabulated security configurations.

Configuring REST Security for ACL Resources

When you assign security privileges to ACLs, you determine which groups can view the ACL resource list.

To configure group security for ACLs:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select ACLs.
In the Name field, select Any.

Figure 13-5 Add New Security Configuration for ACLs

Description of "Figure 13-5 Add New Security Configuration for ACLs"
Select the Groups and Actions as required.
Click Save to save the configuration.

Configuring REST Security for Application Resources

When you assign security privileges to applications, you determine which groups can perform which operations on the specified applications.

To configure group security for applications:

In the General Admin tree expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Application.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-3 Add New Security Configuration Field Names

Field	Definition
Name	Select the name of the application you want to make available to the groups, or select Any to make all applications available to the groups.
Groups	Select the groups that have privileges to operate on the applications.
Action	Assign the security privileges to the groups. Your options depend on your selections in the previous fields. For example, if you selected Any and Create, members of your selected groups can create the assets which make the applications accessible in WEM.

Configuring REST Security for Asset Resources

When you assign security privileges to assets, you determine which groups can perform which operations on the specified assets.

To configure group security for Assets:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Asset.
In the Site field, select the appropriate site.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-4 Add New Security Configuration Form Field Names

Field	Definition
Site	Select the site associated with the asset you want to make available to the groups, or select Any to make all assets, system wide, available to the groups.
Name	Select the asset type associated with the asset you want to make available to the groups, or select Any to make all assets available to the groups. To make a specified asset of the selected asset type available to the groups, click the Browse button.
Groups	Select the groups that have privileges to operate on the assets.
Action	Assign the security privileges to the groups. Your options depend on your selections in the previous fields. For example, if you selected a specific site, a specific asset type, and List, members of your selected groups can perform searches in the specified site for assets of the specified asset type.

Configuring REST Security for Asset Type Resources

When you assign security privileges to asset types, you determine which groups can perform which operations on the specified asset types.

To configure group security for asset types:

In the General Admin tree expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Asset Type.
In the Name field, select Any.

Figure 13-6 Add New Security Configuration Form for Field Names

Description of "Figure 13-6 Add New Security Configuration Form for Field Names"
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-5 Add New Security Configuration Field Names

Field	Definition
Name	Select the asset types you want to make available to the groups, or select Any to make all asset types available to the groups.
Subtype	(Optional) Select the subtype of the asset type you want to make available to the groups. Note: If you selected the Any option in the Name field, then the Subtype field is not displayed.
Groups	Select the groups that have privileges to operate on the asset types.
Action	Assign the security privileges to the groups. Your options depend on your selections in the previous fields. For example, if you selected Any and Create, members of your selected groups can create asset types.

Configuring REST Security for Engage Resources

When you assign security privileges to Engage resources, you determine which groups can perform which operations on Engage.

To configure group security for groups:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Engage.
In the Site field, select the appropriate site.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-6 Add New Security Configuration Form Field Names

Field	Definition
Site	Select the site associated with the asset you want to make available to the groups, or select Any to make all assets, system wide, available to the groups.
Name	Select the asset type associated with the asset you want to make available to the groups, or select Any to make all assets available to the groups. To make a specified asset of the selected asset type available to the groups, click Browse.
Groups	Select the groups that have privileges to operate on the assets.
Action	Assign the security privileges to the groups. Your options depend on your selections in the previous fields. For example, if you selected a specific site, a specific asset type, and List, members of your selected groups can perform searches in the specified site for assets of the specified asset type.

Configuring REST Security for Group Resources

When you assign security privileges to groups, you determine which groups can perform which operations on the specified groups.

To configure group security for groups:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Group.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-7 Add New Security Configuration Field Names

Field	Definition
Name	Select the groups you want to make available to the groups, or select Any to make all groups available to the groups.
Groups	Select the groups that have privileges to operate on the groups.
Action	Assign the security privileges to the groups. Your options depend on your selections in the previous fields. For example, if you selected Any and List, members of your selected groups can view a listing of the groups in the system.

Configuring REST Security for Indexed Asset Type Resources

When you assign security privileges to indexed asset types, you determine which groups can perform which operations on the specified indexed asset types.

Note:

Before configuring security for indexed asset types, you must enable indexing for the WebCenter Sites "Global Search" and "Asset Type Search." See Setting Up Search Indices.

When assigning groups security privileges to groups, determine which groups can perform which operations on the specified groups.

To configure group security for indexed asset types:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Group.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-8 Add New Security Configuration Form Field Names

Field	Definition
Name	Select the name of the indexed asset type you want to make available to the groups. Select Any to make all indexed asset types available to the groups. Select Global to make all indexed asset types associated with the "Global Search" available to the groups.
Groups	Select the groups that have privileges to operate on the indexed asset types.
Action	Assign the security privileges to the groups. Your options depend on your selections in the previous fields. For example, if you selected Any and List, members of your selected groups can search for assets of all types that are indexed on the system.

Configuring REST Security for Role Resources

When you assign security privileges to roles, you determine which groups can perform which operations on the specified roles.

To configure group security for role resources:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Role.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-9 Add New Security Configuration Form Field Names

Field	Definition
Name	Select the name of the role you want to make available to the groups, or select Any to make all roles available to the groups.
Groups	Select the user groups that have privileges to operate on the roles.
Action	Assign the security privileges to the groups. Your options depend on your selections in the previous fields. For example, if you selected Any and Create, members of your selected groups can create roles.

Configuring REST Security for Site Resources

When you assign security privileges to sites, you determine which groups can perform which operations on the specified sites.

To configure group security for sites:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Site.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-10 Add New Security Configuration Form Field Names

Field	Definition
Name	Select the name of the site you want to make available to groups, or select Any to make all sites available to groups.
Groups	Select the user groups that have privileges to operate on the sites.
Action	Assign the security privileges to the groups. Your menu options depend on your selections in the previous fields. For example, if you selected Any and Create, members of your selected groups can create sites.

Configuring REST Security for User Resources

When you assign security privileges to users, you determine which groups can perform which operations on the specified users.

To configure group security for user resources:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select User.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-11 Add New Security Definition Field Names

Field	Definition
Name	Select the name of the user you want to make available to groups, or select the Any option to make all users available to groups.
Groups	Select the groups that have privileges to operate on the users.
Action	Assign the security privileges to the groups. Your menu options depend on your selections in the previous fields. For example, if you selected Any and Create, members of your selected groups can create users.

Configuring REST Security for UserDef Resources

When you assign security privileges to user definitions, you determine which groups can view the user definitions for the system.

To configure group security for userdef resources:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select UserDef.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-12 Add New Security Configuration Form Field Names

Field	Definition
Name	The only available option is to make all user definitions available to groups.
Groups	Select the groups that have privileges to view user definitions.
Action	The only available security privilege you can assign to the groups is Read/Head, which enables the members of your selected groups to view the user definitions on the system.

Configuring REST Security for UserLocale Resources

When you assign security privileges to user locales, you determine which groups can view the UserLocale resource list.

To configure group security for userlocale resources:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select UserLocales.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configuration.

Table 13-13 Add New Security Configuration Field Names

Field	Definition
Name	The only available option is to make all user locales available to groups.
Groups	Select the groups that have privileges to view user locales.
Action	The only available security privilege you can assign to the groups is to view a listing of the user locales on the system.

Configuring REST Security for Visitor Resources

When you assign security privileges to visitors, you determine which groups can view the Visitor assets.

To configure group security for visitor resources:

In the General Admin tree, expand the Admin node, expand the User Access Management node, expand the REST Security node, expand the Configure Security node, and then double-click Add New.

The Add New Security Configuration form opens.
In the Type field, select Visitor.
In the Name field, select Any.
Select the Groups and Actions as required.
Click Save to save the configurations.

Table 13-14 Add New Security Configuration Field Names

Field	Definition
Name	The only available option is to make all visitors available to groups.
Groups	Select the groups that have privileges to view a list of visitors.
Action	The only available security privilege you can assign to the groups is to view a listing of the visitors.