5 Managing Security and User Access

This chapter describes concepts and tasks for managing Oracle WebCenter Content Server system security and user access. It covers the following topics:

5.1 Introduction to WebCenter Content and Content Server Security

The Content Server instance is deployed on the Oracle WebCenter Content (WebCenter Content) domain, which is deployed on the Oracle WebLogic Server domain in Oracle Fusion Middleware. Security is supported at multiple levels including the Content Server instance, the Oracle WebLogic Server domain, and Oracle Platform Security Services (OPSS).

Access to content in the Content Server repository requires a Content Server administrator to manage content, users, and groups, as well as roles, permissions, and accounts. An Oracle WebLogic Server administrator functions as the Content Server administrator. The Oracle WebLogic Server administrator must log in to the Content Server instance and set up the primary Content Server administrator account and password, if no such user was configured during deployment. After the Content Server administrator is configured, then management tasks can be performed on the Content Server instance.

Most user management tasks must be performed using the Oracle WebLogic Server Administration Console rather than the User Admin applet in the Content Server instance. By default, WebCenter Content uses the Oracle WebLogic Server user store to manage user names and passwords for the Content Server instance. For an enterprise-level system, Oracle Platform Security Services (OPSS) can be used instead of the default Oracle WebLogic Server user store to authenticate users.

Content Server software offers two levels of security for repository content: security groups (which are required) and accounts (which are optional). Each content item is assigned to a security group, and if accounts are enabled then content items can also be assigned to an account. Users are assigned a certain level of permission (Read, Write, Delete, or Admin) for each security group and account, which enables them to work with a content item only to the extent that they have permissions to the item's security group and account.

Access control lists (ACLs) can be configured for the Content Server instance to provide extended control of content access to enterprise users. An access control list is a list of users, groups, or Enterprise roles with permission to access or interact with a content item.

This section covers the following topics:

5.1.1 Changes in Security Compared to Content Server 10g

In 11g Release 1 (11.1.1) of WebCenter Content, the Content Server instance is deployed with the WebCenter Content domain on an Oracle WebLogic server. WebCenter Content and the Content Server system typically use Oracle Platform Security Services (OPSS) to authenticate and manage user access through the Oracle WebLogic Server Administration Console.

If you have used Content Server version 10gR3 or earlier, be aware of the following key changes to security:

  • During Content Server installation and configuration, an Oracle WebLogic Server administration user must be specified for the Content Server system administration user. For details, see Oracle WebCenter Content Installation Guide.

  • When Content Server software is installed, a JPS user provider (JpsUserProvider) is set up by default to communicate with the Oracle WebLogic Server user store for user authentication and access.

  • All users are authenticated through external security and are considered external Content Server users. The first time users log in to the Content Server system through Oracle WebLogic Server, they are added to the Content Server database, and administrators can view the external user information through the Repository Manager. External users are not automatically included in Content Server user lists, such as the Author field on a content Check In page.

  • By default, the Content Server system uses the Oracle WebLogic Server user store to manage user names and passwords. Most user management tasks must be performed with the Oracle WebLogic Server Administration Console instead of the Content Server User Admin applet. Although a Content Server administrator can use the User Admin applet to create local users and to assign passwords and roles on the Content Server system, for local users to be authenticated for access to the Content Server system they must also be created and assigned passwords and roles using the Oracle WebLogic Server Administration Console.

    Note:

    Any user created solely on the Content Server system is not recognized by the Oracle WebLogic Server domain.

  • The Oracle WebLogic Server user store also manages some additional user metadata such as e-mail and display names. You can use the Oracle WebLogic Server Administration Server interface to edit these values.

    User metadata can be changed in the Content Server system, but only after users have logged in to the Content Server instance at least one time to establish themselves as users in the Content Server metadata. After the first login, users can update their User Profile page, or a Content Server administrator can set user attribute values with the User Admin applet.

  • Users can be assigned groups with the Oracle WebLogic Server Administration Console. When a user logs in to the Content Server instance, the user's groups are mapped to Content Server roles. For Oracle WebLogic Server groups to be recognized in the Content Server instance, roles with the exact same names as the Oracle WebLogic Server groups must be created in the Content Server instance and assigned to security groups. If this is not done, the Oracle WebLogic Server groups assigned to users have no impact on users' privileges in the Content Server.

  • Configuration with an external user store, such as the LDAP server for Oracle Internet Directory (OID), is performed using the Oracle WebLogic Server Administration Server instead of the Content Server Admin Server. The Oracle WebLogic Server Administration Server has an embedded Lightweight Directory Access Protocol (LDAP) server, but it can be configured to work with other LDAP servers such as Oracle Internet Directory (OID) for Enterprise-level systems. Integration with an external user store applies to the domain and all its servers; the Oracle WebLogic Server Administration Server could be shut down, and WebCenter Content and other applications could continue to use the configured LDAP server.

For more information on security integration and configuration, see Section 5.2, "Oracle Fusion Middleware Security Configuration for WebCenter Content."

5.1.2 Security within Content Server

The administrator sets up initial user and content security within the Content Server system by using the User Admin application to define user roles, permissions to groups, and accounts. Then the administrator uses the Oracle WebLogic Server Administration Console to create users and assign each user to one or more of the Content Server roles, which in turn are assigned specific permissions to security groups. If accounts are enabled on the Content Server system, the administrator can assign users specific permissions to certain accounts, which then limits the permissions the users might otherwise have through their assigned roles.

For details, see Section 5.3, "User Types, Logins, and Aliases," Section 5.4, "Security Groups, Roles and Permissions," and Section 5.5, "Accounts."

The following components also can be used to provide additional internal Content Server security:

  • Security can be customized for user access by using the Extranet Look component, which is installed (disabled) with Content Server. For details, see Section 5.9.1, "Login/Logout Customization."

    Note:

    The Extranet Look component is not applicable when the Oracle WebLogic Server domain is used as the web server for the Content Server instance. Modification of the security implementation is controlled through direct customization of the Oracle WebLogic Server domain and administrative configuration.

  • Security can be customized for user access and search results by using the Need to Know component. This component enables you to further configure user access restrictions, modify the display of search results, alter search behavior, and set up hit list roles. To use this component, you must install and enable it. For more information, see Appendix B, "Need to Know Component".

Be aware that Internet Explorer 7 supplies the following message to users logging in with basic authentication without a secure connection:

Warning: This server is requesting that your username and password be sent in an insecure manner

The behavior (sending user name and password in text) is not new for basic authentication and does not cause problems.

5.1.3 Additional Security Options

The Content Server can combine authentication methods. For example, you can define some users with the Oracle WebLogic Server Administration Console, allow some users to log in using their Microsoft domain identity, and grant other users access to the Content Server instance based on their external Lightweight Directory Access Protocol (LDAP) credentials. However, authentication is configured through Oracle WebLogic Server, so the combination of methods is limited. Users can authenticate against multiple authentication stores, but because of the Oracle Platform Security Services (OPSS) and Oracle WebLogic Server integration, only one of the configured user stores can be used to extract authorization (group) information.

Note:

As of 11g Release 1 (11.1.1.6.0) Oracle WebCenter Content supports use of the Oracle Virtual Directory library (libOVD) feature, which enables a site to use multiple providers for login and group membership information. For example, it would be possible to use both Oracle Internet Directory (OID) and Active Directory as sources of user and role information. For information, see "Multi-LDAP Configuration in Oracle WebLogic Server" in Oracle Fusion Middleware Application Security Guide.

The following options can be used to provide additional security:

  • Security can be customized to support encrypted socket communication and authentication by using the Security Providers component, which is installed (enabled) by default with the Content Server system. This component enables a Secure Sockets Layer (SSL) provider, which can be configured to use certificates for socket or server authentication.

    If you use SSL and HTTPS to connect to WebCenter Content, and are unable to connect through WebDAV, try connecting to the Content Server instance through the browser using the same URL you used in your WebDAV connection string. This lets you see if there is a problem with the certificate, which is used to encrypt communications. If you get a dialog box stating a problem with the certificate, resolve the issue and then try to connect through WebDAV again.

  • For users to access the Content Server instance using different web server front ends, when one server front end is HTTPS and the other is HTTP, you can customize the Content Server configuration using the BrowserUrlPath component. This component is installed (disabled) by default with the Content Server system and supports a web server front end using HTTPS and a load balancer that forwards itself as the HTTP Host header. If you only use one access method (only HTTPS, or only HTTP), or you are not using a load balancer that blocks the "Host" parameter from the browser, then this component is unnecessary. For more information, see Section 5.9.2, "Browser URL Customization."

  • Extended security attributes can be assigned to external users or to users for a specific application. The extended attributes are merged into pre-existing user attributes and enable additional flexibility in managing users. For more information, see Section 5.9.3, "Extended User Attributes."

  • The Content Server instance can be customized to filter data input for illegal or corruptive HTML constructs. For more information, see Section 5.9.4, "Filter Data Input."

In all environments, a comprehensive understanding of your organization's security needs and a thorough planning phase is crucial to a successful security integration.

5.2 Oracle Fusion Middleware Security Configuration for WebCenter Content

This section describes security configuration information for integrating Oracle Fusion Middleware, including Oracle WebLogic Server and Oracle Platform Security Services (OPSS), with WebCenter Content and the Content Server system.

5.2.1 LDAP Authentication Providers

The Oracle WebLogic Server domain includes an embedded Lightweight Directory Access Protocol (LDAP) server that acts as the default security provider data store for the Default Authentication, Authorization, Credential Mapping, and Role Mapping providers. WebCenter Content provides the default JPS User Provider to communicate with Oracle WebLogic Server. For information on the embedded LDAP server, see "Managing the Embedded LDAP Server" in Oracle Fusion Middleware Securing Oracle WebLogic Server, and "Configure the Embedded LDAP Server" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

In almost all cases, a WebCenter Content production system identity store must be reassociated with an external LDAP authentication providers rather than use the embedded LDAP server. Once the new LDAP authentication provider is configured, then you migrate users from the embedded LDAP provider to the new LDAP provider. For information on WebCenter Content configuration for external LDAP providers, see Oracle WebCenter Content Installation Guide.

Note:

As of 11g Release 1 (11.1.1.6.0) Oracle WebCenter Content supports use of the Oracle Virtual Directory library (libOVD) feature, which enables a site to use multiple providers for login and group membership information. For example, it would be possible to use two Oracle Internet Directory (OID) providers as sources of user and role information. For information, see "Multi-LDAP Configuration in Oracle WebLogic Server" in Oracle Fusion Middleware Application Security Guide.

Table 5-1 lists some of the LDAP providers that can be configured for user authentication.

Table 5-1 LDAP Authenticator Types

LDAP Authentication Provider Authenticator Type

Microsoft AD

ActiveDirectoryAuthenticator

SunOne LDAP

IPlanetAuthenticator

Directory Server Enterprise Edition (DSEE)

IPlanetAuthenticator

Oracle Internet Directory

OracleInternetDirectoryAuthenticator

Oracle Virtual Directory

OracleVirtualDirectoryAuthenticator

EDIRECTORY

NovellAuthenticator

OpenLDAP

OpenLDAPAuthenticator

EmbeddedLDAP

DefaultAuthenticator


5.2.2 Configuring WebCenter Content to Use SSL

You can configure Oracle Fusion Middleware to secure communications with WebCenter Content using SSL, which is an industry standard for securing communications. Oracle Fusion Middleware supports SSL version 3, as well as TLS version 1.

This section covers the following topics:

For additional information, see "Configuring SSL" in Oracle Fusion Middleware Securing Oracle WebLogic Server. For information on Web Tier configuration, see "SSL Configuration in Oracle Fusion Middleware" in Oracle Fusion Middleware Administrator's Guide.

5.2.2.1 Configuring WebCenter Content for Two-Way SSL Communication

Oracle WebCenter Content uses both the Oracle WebLogic Server and Sun secure socket layer (SSL) stacks for two-way SSL configurations.

  • For the inbound Web service bindings, WebCenter Content uses the Oracle WebLogic Server infrastructure and, therefore, the Oracle WebLogic Server libraries for SSL.

  • For the outbound Web service bindings, WebCenter Content uses JRF HttpClient and, therefore, the Sun JDK libraries for SSL.

Due to this difference, start Oracle WebLogic Server with the following JVM option.

  1. Open the following file:

    • On UNIX operating systems, open $MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.sh.

    • On Window operating systems, open MIDDLEWARE_HOME\user_projects\domains\domain_name\bin\setDomainEnv.bat.

  2. Add the following lines in the JAVA_OPTIONS section, if the server is enabled for one-way SSL (server authorization only):

    -Djavax.net.ssl.trustStore=your_truststore_location
    

    For two-way SSL, the keystore information (location and password) is not required.

In addition, perform the following steps to enable two-way SSL for WebCenter Content to invoke another application.

Note:

Both the server and client are assumed to have been configured for SSL with mutual authentication.

  1. On the client side, provide the keystore location.

    1. From the SOA Infrastructure menu, choose SOA Administration then Common Properties.

    2. At the bottom of the page, click More SOA Infra Advanced Configuration Properties.

    3. Click KeystoreLocation.

    4. In the Value column, enter the keystore location.

    5. Click Apply.

    6. Click Return.

  2. On the client side, provide the keystore location in DOMAIN_HOME\config\soa-infra\configuration\soa-infra-config.xml.

    <keystoreLocation>absolute_path_to_the_keystore_location_and_the_file_name
    </keystoreLocation> 
    
  3. During design time in Oracle JDeveloper, update the reference section in the composite.xml file with the oracle.soa.two.way.ssl.enabled property.

    <reference name="Service1" 
       ui:wsdlLocation=". . ."> 
       <interface.wsdl interface=". . ."/> 
         <binding.ws port=". . ."> 
          <property name="oracle.soa.two.way.ssl.enabled">true</property> 
      </binding.ws> 
     </reference> 
    
  4. In Oracle Enterprise Manager Fusion Middleware Control Console, select WebLogic Domain, then domain_name.

  5. Right-click domain_name and select Security then Credentials.

  6. Click Create Map.

  7. In the Map Name field, enter a name (for example, SOA), and click OK.

  8. Click Create Key.

  9. Enter the following details.

    Field Description

    Select Map

    Select the map created in Step 7 (for this example, SOA).

    Key

    Enter the key name (KeystorePassword is the default).

    Type

    Select Password.

    User Name

    Enter the keystore user name (KeystorePassword is the default).

    Password

    Enter the password that you created for the keystore.


    Note:

    When you set up SSL on an Oracle WebLogic Server domain, a key alias is required. You must enter mykey as the alias value. This value is required.

  10. Set the keystore location in Oracle Enterprise Manager Fusion Middleware Control Console. See Step 1 for instructions.

  11. Modify the composite.xml syntax to use https and sslport to invoke WebCenter Content. For example, change the syntax shown in bold:

    <?xml version="1.0" encoding="UTF-8" ?> 
    <!-- Generated by Oracle SOA Modeler version 1.0 at [4/1/09 11:01 PM]. --> 
    <composite name="InvokeEchoBPELSync" 
    revision="1.0" 
    label="2009-04-01_23-01-53_994" 
    mode="active" 
    state="on" 
    xmlns="http://xmlns.oracle.com/sca/1.0" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" 
    xmlns:ui="http://xmlns.oracle.com/soa/designer/"> 
    <import 
    namespace="http://xmlns.oracle.com/CustomApps/InvokeEchoBPELSync/BPELProcess1"
      location="BPELProcess1.wsdl" importType="wsdl"/>
    <import namespace="http://xmlns.oracle.com/CustomApps/EchoBPELSync/
    BPELProcess1"location="http://hostname:port/soa-infra/services/default/EchoBPEL
    Sync/BPELProcess1.wsdl"
    importType="wsdl"/>
    

    to use https and sslport:

    location="https://hostname:sslport/soa-infra/services/default/EchoBPELSync
    /BPELProcess1.wsdl"
    

5.2.2.2 Invoking References in One-Way SSL Environments in Oracle JDeveloper

When invoking a Web service as an external reference from WebCenter Content in one-way SSL environments, ensure that the certificate name (CN) and the host name of the server exactly match. This ensures a correct SSL handshake.

For example, if a Web service is named adfbc and the certificate has a server name of host, the following results in a SSL handshake exception.

<import namespace="/adfbc1/common/"
location="https://host.example.com:8002/CustomApps-adfbc1-context-root/AppModuleService?WSDL"
          importType="wsdl"/> 
<import namespace="/adfbc1/common/" location="Service1.wsdl" 
          importType="wsdl"/> 

If you switch the order of import, the SSL handshake passes.

<import namespace="/adfbc1/common/" location="Service1.wsdl" 
          importType="wsdl"/> 
<import namespace="/adfbc1/common/" 
location="https://host.example.com:8002/CustomApps-adfbc1-context-root/AppModuleService?WSDL" 
          importType="wsdl"/> 

Note the following restrictions around this issue:

  • There are no options for ignoring host name verification in Oracle JDeveloper as exist with the Oracle WebLogic Server Administration Console. This is because the SSL kit used by Oracle JDeveloper is different. Only the trust store can be configured from the command line. All other certificate arguments are not passed.

  • In the WSDL file, https://hostname must match with that in the certificate, as described above. You cannot perform the same procedures as you can with a browser. For example, if the host name is host.example.com in the certificate's CN, then you can use host, host.example.com, or the IP address from a browser. In Oracle JDeveloper, always use the same name as in the certificate (that is, host.example.com).

5.2.2.3 Configuring WebCenter Content, Oracle HTTP Server for SSL Communication

Follow these procedures to configure SSL communication between WebCenter Content and Oracle HTTP Server.

For addition information, see "Configuring SSL for the Web Tier" in Oracle Fusion Middleware Administrator's Guide.

Configure Oracle HTTP Server for SSL Communication:

  1. Append ssl.conf with the <Location /cs> location directive, where port is the port number of the target managed server.

    <Location /cs>
          WebLogicPort 8002
          SetHandler weblogic-handler
          ErrorPage http://host.example.com:port/error.html
    </Location>
    
  2. Start the Oracle WebLogic Server as described in Section 5.2.2.1, "Configuring WebCenter Content for Two-Way SSL Communication."

Configure Certificates for Oracle Client, Oracle HTTP Server, and Oracle WebLogic Server:

  1. Export the user certificate from the Oracle HTTP Server wallet.

    orapki wallet export -wallet . -cert cert.txt  -dn 'CN=\"Self-Signed Certificate for ohs1 \",OU=OAS,O=ORACLE,L=REDWOODSHORES,ST=CA,C=US'
    
  2. Import the above certificate into the Oracle WebLogic Server truststore as a trusted certificate.

    keytool -file cert.txt -importcert -trustcacerts -keystore DemoTrust.jks
    
  3. Export the certificate from the Oracle WebLogic Server truststore.

    keytool -keystore DemoTrust.jks -exportcert -alias wlscertgencab -rfc -file
    certgencab.crt
    
  4. Import the above certificate to the Oracle HTTP Server wallet as a trusted certificate.

    orapki wallet add -wallet . -trusted_cert -cert certgencab.crt -auto_login_only
    
  5. Restart Oracle HTTP Server.

  6. Restart the Oracle WebLogic Server as described in Section 5.2.2.1, "Configuring WebCenter Content for Two-Way SSL Communication."

5.2.2.4 Switching from Non-SSL to SSL Configurations for WebCenter Content

Switching from non-SSL to SSL configurations for WebCenter Content requires the Frontend Host and Frontend HTTPS Port fields to be set in the Oracle WebLogic Server Administration Console. Not doing so results in exception errors when you attempt to create to-do tasks.

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the Environment section, select Servers.

  3. Select the name of the managed server (for example, UCM_server1).

  4. Select Protocols, then select HTTP.

  5. In the Frontend Host field, enter the host name on which the WebCenter Content domain is located.

  6. In the Frontend HTTPS Port field, enter the SSL listener port.

  7. Click Save.

5.2.2.5 Configuring SSL Between WebCenter Content Instance and Oracle WebCache

The Test Web Service page, in an Oracle WebCache and Oracle HTTP Server environment, may require communication back through Oracle WebCache. Therefore, SSL must be configured between the WebCenter Content instance and Oracle WebCache (that is, export the user certificate from the Oracle WebCache wallet and import it as a trusted certificate in the Oracle WebLogic Server truststore).

See "Enabling SSL for Oracle Web Cache Endpoints" in Oracle Fusion Middleware Administrator's Guide.

5.2.2.6 Using a Custom Trust Store for One-Way SSL

To invoke WebCenter Content over HTTPS when using a custom trust store created with a tool such as keytool or orapki, perform the following actions in Oracle JDeveloper.

  1. To fetch a WSDL file in the reference section, set the trust store information in Tools, then Preferences, then Http Analyzer, then HTTPS Setup, then Client Trusted Certificate Keystore.

  2. During deployment to a SSL-enabled server, use the JSSE property at the command line:

    jdev -J-Djavax.net.ssl.trustStore=your_trusted_location
    

5.2.2.7 Enabling an Asynchronous Process to Invoke an Asynchronous Process

To enable an asynchronous process deployed to a SSL-enabled, managed server to invoke another asynchronous process over HTTP, start by assuming you create the following environment:

  • Asynchronous BPEL process A that invokes asynchronous BPEL process B

  • Asynchronous BPEL process A is deployed to a one-way SSL enabled, managed server

  • All WSDL reference and bindings use plain HTTP

At run time, the WSDL is looked for over HTTPS, and the callback message from asynchronous BPEL process B fails.

To resolve this issue, the callbackServerURL property must be passed at the reference binding level in the composite.xml file. This explicitly indicates the value of the callback URL for the given reference invocation. If the client composite is running in a SSL-managed server, then the callback defaults to SSL.

<reference name="Service1" ui:wsdlLocation="http://localhost:8000/soa-infra/services/default/
                AsyncSecondBPELMTOM/BPELProcess1.wsdl"> 
    <interface.wsdl interface="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1# 
                wsdl.interface(BPELProcess1)" callbackInterface="http://xmlns.oracle.com/Async/ 
                AsyncSecondBPELMTOM/BPELProcess1#wsdl.interface(BPELProcess1Callback)"/> 
    <binding.ws port="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#
                wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)" 
        location="http://localhost:8000/soa-infra/services/default/AsyncSecondBPELMTOM 
                /bpelprocess1_client_ep?WSDL"> 
            <wsp:PolicyReference URI="oracle/wss_username_token_client_policy" 
                orawsp:category="security" orawsp:status="enabled"/>
            <wsp:PolicyReference URI="oracle/wsaddr_policy"  orawsp:category="addressing"
                orawsp:status="enabled"/> 
            <property name="callbackServerURL">http://localhost:8000/</property> 
    </binding.ws> 
    <callback> 
            <binding.ws port="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#
                wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1Callback_pt)"> 
              <wsp:PolicyReference URI="oracle/wss_username_token_service_policy"
                  orawsp:category="security" orawsp:status="enabled"/> 
            </binding.ws> 
    </callback> 
</reference> 

5.2.2.8 Configuring RIDC SSL for Valid Certificate Path

To use Remote Intradoc Client (RIDC) and self-signed certificates, you must import the certificate into your local JVM certificate store so the certificate will be trusted.

  1. Retrieve the key from the Content Server instance. For example:

    openssl s_client -connect host.example.com:7045 2>/dev/null
    
    CONNECTED(00000003)
    ---
    Certificate chain
      
     0 s:/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING ONLY/CN=hostname 
    i:/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING ONLY/CN=CertGenCAB
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIB6zCCAZUCEItVMwHDFXAnYG//RoVbXQgwDQYJKoZIhvcNAQEEBQAweTELMAkG
    A1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
    A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkx
    EzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDkwMzI5MjM0NDM0WhcNMjQwMzMwMjM0
    NDM0WjB5MQswCQYDVQQGEwJVUzEQMA4GA1UECBYHTXlTdGF0ZTEPMA0GA1UEBxYG
    TXlUb3duMRcwFQYDVQQKFg5NeU9yZ2FuaXphdGlvbjEZMBcGA1UECxYQRk9SIFRF
    U1RJTkcgT05MWTETMBEGA1UEAxYKZGFkdm1jMDAyMjBcMA0GCSqGSIb3DQEBAQUA
    A0sAMEgCQQCmxv+h8kzOc2xyjMCdPM6By5LY0Vlp4vzWFKmPgEytp6Wd87sG+YDB
    PeFOz210XXGMx6F/14/yFlpCplmazWkDAgMBAAEwDQYJKoZIhvcNAQEEBQADQQBn
    uF/s6EqCT38Aw7h/406uPhNh6LUF7XH7QzmRv3J1sCxqRnA/fK3JCXElshVlPk8G
    hwE4G1zxpr/JZu6+jLrW
    -----END CERTIFICATE-----
    subject=/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING
    ONLY/CN=host
    issuer=/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING
    ONLY/CN=CertGenCAB
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 625 bytes and written 236 bytes
    ---
    New, TLSv1/SSLv3, Cipher is RC4-MD5
    Server public key is 512 bit
    Compression: NONE
    Expansion: NONE
    SSL-Session:
       Protocol  : TLSv1
       Cipher    : RC4-MD5
       Session-ID: 23E20BCAA4BC780CE20DE198CE2DFEE4
       Session-ID-ctx:
       Master-Key:
    4C6F8E9B9566C2BAF49A4FD91BE90DC51F1E43A238B03EE9B700741AC7F4B41C72D2990648DE103
    BB73B3074888E1D91
       Key-Arg   : None
       Start Time: 1238539378
       Timeout   : 300 (sec)
       Verify return code: 21 (unable to verify the first certificate)
    ---
    
  2. Copy and paste the Server Certificate including the surrounding -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. Save the certificate into a new file. For example:

    /tmp/host.pem:
    
    -----BEGIN CERTIFICATE-----
    MIIB6zCCAZUCEItVMwHDFXAnYG//RoVbXQgwDQYJKoZIhvcNAQEEBQAweTELMAkG
    A1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
    A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkx
    EzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDkwMzI5MjM0NDM0WhcNMjQwMzMwMjM0
    NDM0WjB5MQswCQYDVQQGEwJVUzEQMA4GA1UECBYHTXlTdGF0ZTEPMA0GA1UEBxYG
    TXlUb3duMRcwFQYDVQQKFg5NeU9yZ2FuaXphdGlvbjEZMBcGA1UECxYQRk9SIFRF
    U1RJTkcgT05MWTETMBEGA1UEAxYKZGFkdm1jMDAyMjBcMA0GCSqGSIb3DQEBAQUA
    A0sAMEgCQQCmxv+h8kzOc2xyjMCdPM6By5LY0Vlp4vzWFKmPgEytp6Wd87sG+YDB
    PeFOz210XXGMx6F/14/yFlpCplmazWkDAgMBAAEwDQYJKoZIhvcNAQEEBQADQQBn
    uF/s6EqCT38Aw7h/406uPhNh6LUF7XH7QzmRv3J1sCxqRnA/fK3JCXElshVlPk8G
    hwE4G1zxpr/JZu6+jLrW
    -----END CERTIFICATE-----
    
  3. Import the certificate into the local JVM certificate store. You will need the keystore password. For example (the password is changeit):

    sudo /opt/java/jdk1.6.0_12/bin/keytool -import -alias host -keystore 
    /opt/java/jdk1.6.0_12/jre/lib/security/cacerts -trustcacerts -file 
    /tmp/host.pem
    
    Enter keystore password: changeit 
    Owner: CN=hostd, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown,
    ST=MyState, C=US
    Issuer: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown,
    ST=MyState, C=US
    Serial number: -74aaccfe3cea8fd89f9000b97aa4a2f8
    Valid from: Sun Mar 29 16:44:34 PDT 2009 until: Sat Mar 30 16:44:34 PDT 2024
    Certificate fingerprints:
        MD5:  94:F9:D2:45:7F:0D:E3:87:CF:2B:32:7C:BF:97:FF:50
        SHA1: A8:A5:89:8B:48:9B:98:34:70:56:11:01:5C:14:32:AC:CB:18:FF:1F
        Signature algorithm name: MD5withRSA
        Version: 1
    Trust this certificate? [no]:  yes
    Certificate was added to keystore
    

5.2.3 Configuring WebCenter Content for Single Sign-On

Oracle provides several single sign-on solutions. Oracle Access Manager (OAM) is the recommended single sign-on (SSO) solution for Oracle Fusion Middleware enterprise-class installations including WebCenter Content. OAM is part of Oracle's suite of enterprise-class products for identity management and security. For more information, see "Choosing the Right SSO Solution for Your Deployment" in Oracle Fusion Middleware Application Security Guide.

If your enterprise-class installation uses Microsoft desktop logins that authenticate with a Microsoft domain controller with user accounts in Active Directory, then configuring Windows Native Authentication (WNA) single sign-on may be an option. See Section 5.2.3.6, "Configuring WebCenter Content and Single Sign-On for WNA."

Note:

WebDAV (/dav) is protected by basic authentication per WebDAV protocol and is not protected by SSO, which typically requires form-based login. If you want to use a custom SSO solution for WebDAV, then a custom component is necessary.

Configuration information is provided in the following sections:

5.2.3.1 Configuring Oracle Access Manager 11g with WebCenter Content

This section describes how to integrate WebCenter Content with Oracle Access Manager (OAM) 11g. Configuration information is provided for WebCenter Content: Content Server (CS), WebCenter Content: Records (URM), WebCenter Content: Inbound Refinery (IBR), and WebCenter Content: Site Studio (SS).

Before you can configure OAM 11g, install the software using the instructions provided in "Installing the Oracle Identity Management 11g Software" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  1. Configure OAM 11g, Oracle HTTP Server (OHS), and WebGate as described in "Setting Up OAM Agents" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

    1. Append entries to the mod_wl_ohs.conf file to add WebCenter Content Uniform Resource Identifiers (URIs) to forward. Use the appropriate location entries from the following example. Each entry in the example maps the incoming path to the appropriate Oracle WebLogic Server on which the corresponding application resides.

      In the following list of entries, hostname represents the name of the computer hosting the WebCenter Content server, and portnumber represents the port number of the Oracle WebLogic Server on which the corresponding applications resides. Replace hostname and portnumber with your system's host name and port name.

      Note:

      The URIs you forward depend on the WebCenter Content functionality that you have installed. Use the appropriate location entry for your functionality. For example: /cs, /adfAuthentication, /_ocsh, /ibr, /urm.

      For Site Studio, the URI to forward is configured by the customer. For example, if the site is accessed as /mysite, then you need to append a location entry for /mysite.

      Caution:

      The Content Server location /cs can be customized, so the /cs designation can not guarantee that HTTP requests will include the correct location. If /cs has been changed, then forward the location the administrator has configured.

      # WebCenter Content Server
      <Location /cs>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # WebCenter Content Server authentication
      <Location /adfAuthentication>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # WebCenter online help
      <Location /_ocsh>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # IBR
      <Location /ibr>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # URM
      <Location /urm>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # SS
      <Location /customer-configured-site-studio
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
    2. Use the OAM 11g remote registration tool (oamreg) to register an OAM Agent, specifying WebCenter Content URIs to protect and to make public. See "Provisioning an OAM Agent with Oracle Access Manager 11g" in Oracle Fusion Middleware Application Security Guide.

      For more information, see "Setting Up OAM Agents" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

      Note:

      The URIs you protect and make public depend on the WebCenter Content functionality that you have installed: Content Server (UCM), Inbound Refinery (IBR), Records (URM), Site Studio (SS).

      For Site Studio, the URI to protect is configured by the customer. For example, if the site is accessed as /mysite, then you need to specify the URI /mysite.

      Functionality Type URI

      UCM

      Protect

      /adfAuthentication

      UCM

      Public

      /cs

      UCM

      Public

      /_ocsh

      IBR

      Protect

      /ibr/adfAuthentication

      IBR

      Public

      /ibr

      URM

      Protect

      /urm/adfAuthentication

      URM

      Public

      /urm

      SS

      Protect

      /customer-configured-for-site-studio


    Note:

    If the URL for WebCenter Content does not link correctly after completing the OAM 11g configuration, you might need to change the server host and server port values. For details, see Section 5.2.3.5, "Configuring the WebCenter Content URL for Single Sign-On."

  2. Configure the WebCenter Content domain by ensuring you perform these tasks. See "Deploying the Oracle Access Manager 11g SSO Solution" in Oracle Fusion Middleware Application Security Guide.

    1. Configure the OAM Identity Asserter. The control flag for the OAM Identity Asserter must be set to REQUIRED, and both OAM_REMOTE_USER and ObSSOCookie must be selected as Active Types.

      See "Identity Asserter for Single Sign-on Function," "About Using the Identity Asserter for SSO with OAM 11g and 11g WebGates," and "Configuring Identity Assertion for SSO with Oracle Access Manager 11g" in Oracle Fusion Middleware Application Security Guide.

    2. Configure the Authentication provider. This is necessary to specify the external LDAP server for the user store, such as Oracle Internet Directory (OID) or Oracle Virtual Directory (OVD), to match the LDAP server used by OAM. For example, if OAM is using OID, then an OID Authentication provider must be added to the WebCenter Content domain.

      Note:

      When the Oracle WebLogic Server domain for WebCenter Content is configured to use a different authentication provider than the DefaultAuthenticator provider, the new authentication provider must be the first authentication provider listed in the security realm configuration, or WebCenter Content will fail to load any user privileges. Make sure to re-order the authentication providers so the new authentication provider is listed before the DefaultAuthenticator provider. Also ensure that the DefaultAuthenticator control flag is set to SUFFICIENT. For more information, see Section 5.2.3.4, "Configuring the First Authentication Provider."

      See "Installing the Authentication Provider with Oracle Access Manager 11g" and "Setting Up Providers for Oracle Access Manager Identity Assertion" in Oracle Fusion Middleware Application Security Guide.

      See Table 12-1 in Oracle Fusion Middleware Application Security Guide for information on the differences when deploying the Authentication Provider with OAM 10g versus OAM 11g.

    3. Configure the OPSS (OAM) Single Sign-On provider.

      See "Configuring Oracle WebLogic Server for a Web Application Using ADF Security, OAM SSO, and OPSS SSO" in Oracle Fusion Middleware Application Security Guide.

  3. After installing and configuring OAM 11g, check that you can access all of the configured applications, and that the login is giving you access to all of your configured applications without prompting you to sign in again. Also test global logout where available and make sure you are logged out of all other related applications.

    For more information, see "Configuring Centralized Log Out for Oracle Access Manager 11g" in Oracle Fusion Middleware Application Security Guide and Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

5.2.3.2 Configuring Oracle Access Manager 10g with WebCenter Content

This section describes how to integrate WebCenter Content with Oracle Access Manager (OAM) 10g. Configuration information is provided for WebCenter Content Server (CS), WebCenter Content: Records (URM), and WebCenter Content: Inbound Refinery (IBR).

Note:

Deploying WebCenter Content version 11gR1 in an environment using OAM version 10g requires additional configuration to process logout requests properly. For detailed information, see the section "Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates" in the Oracle Fusion Middleware Application Security Guide.

Before you can configure OAM, install the software. See information on OAM integration in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Enterprise Content Management Suite, and information on installing the OAM 10g software in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  1. Configure OAM 10g, Oracle HTTP Server (OHS), and WebGate as described in "Deploying SSO Solutions with Oracle Access Manager 10g" in Oracle Fusion Middleware Application Security Guide.

    1. Append entries to the mod_wl.conf file to add WebCenter Content Uniform Resource Identifiers (URIs) to forward. Use the appropriate location entries from the following example. The entries in the following Location list map the incoming paths to the appropriate Oracle WebLogic Server on which the corresponding applications reside.

      In the following list of entries, hostname represents the name of the computer hosting the WebCenter Content server, and portnumber represents the port number of the Oracle WebLogic Server on which the corresponding applications resides. Replace hostname and portnumber with your system's host name and port name.

      Note:

      The URIs you forward depend on the WebCenter Content functionality that you have installed. Use the appropriate location entry for your functionality. For example: /cs, /adfAuthentication, /_ocsh, /ibr, /urm.

      For Site Studio, the URI to forward is defined by the customer. For example, if the site is accessed as /mysite, then you need to append a location entry for /mysite.

      Caution:

      The Content Server location /cs can be customized, so the /cs designation can not guarantee that HTTP requests will include the correct location. If /cs has been changed, then forward the location the administrator has configured.

      # WebCenter Content Server
      <Location /cs>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # WebCenter Content Server authentication
      <Location /adfAuthentication>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # WebCenter online help
      <Location /_ocsh>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # IBR
      <Location /ibr>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # URM
      <Location /urm>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # SS
      <Location /customer-configured-for-site-studio>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portname>
      </Location>
      
    2. Use the OAM 10g Configuration tool (oamcfgtool) to specify WebCenter Content URIs to protect.

      The OAM Configuration tool is a command-line utility, which you can use to launch a series of scripts to request information and set up the required profiles and policies in OAM. For details about oamCtgTool, see Oracle Fusion Middleware Application Security Guide. .

      Note:

      The URIs you protect depend on the WebCenter Content functionality that you have installed: WebCenter Content (UCM), Inbound Refinery (IBR), Records (URM), Site Studio (SS).

      For Site Studio, the URI to protect is configured by the customer. For example, if the site is accessed as /mysite, then you need to specify the URI /mysite.

      Functionality URI

      UCM

      /adfAuthentication

      IBR

      /ibr/adfAuthentication

      URM

      /urm/adfAuthentication

      SS

      /customer_configured_site_studio


      Note:

      If the URL for WebCenter Content does not link correctly after completing the OAM configuration, you might need to change the server host and server port values. For details, see Section 5.2.3.5, "Configuring the WebCenter Content URL for Single Sign-On."

    3. Configure the WebGate to handle the end_url in order to complete the setup for OAM global logout. Without this additional configuration, you are logged out, but not redirected to the end URL because OAM 10g WebGate does not process end_url. For information about configuration procedures, see Oracle Fusion Middleware Application Security Guide.

    4. Add the URL /oamsso/logout.html to the logout URL setting for the AccessGate so the single sign-on logout works properly. For details, see topics on configuring a single sign-on logout URL and AccessGate configuration parameters in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

  2. Configure the WebCenter Content domain by performing the following tasks. For details, see "Deploying SSO Solutions with Oracle Access Manager 10g" in Oracle Fusion Middleware Application Security Guide.

    1. Configure the OAM Identity Asserter. The control flag for the OAM Identity Asserter must be set to REQUIRED.

      See "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g" in Oracle Fusion Middleware Application Security Guide.

    2. Configure the Authentication provider. This is necessary to specify the external LDAP server for the user store, such as Oracle Internet Directory (OID) or Oracle Virtual Directory (OVD), to match the LDAP server used by OAM. For example, if OAM is using OID, then an OID Authentication provider must be added to the WebCenter Content domain.

      Note:

      When the Oracle WebLogic Server domain for WebCenter Content is configured to use a different authentication provider than the DefaultAuthenticator provider, the new authentication provider must be the first authentication provider listed in the security realm configuration, or WebCenter Content will fail to load any user privileges. Make sure to re-order the authentication providers so the new authentication provider is listed before the DefaultAuthenticator provider. Also ensure that the DefaultAuthenticator control flag is set to SUFFICIENT. For more information, see Section 5.2.3.4, "Configuring the First Authentication Provider."

      See "Installing and Setting Up Authentication Providers for OAM 10g" and "Configuring the Authenticator for Oracle Access Manager 10g" in Oracle Fusion Middleware Application Security Guide.

      See Table 12-1 in Oracle Fusion Middleware Application Security Guide for information on the differences when deploying the Authentication Provider with OAM 10g versus OAM 11g.

    3. Configure the OPSS (OAM) Single Sign-On provider.

      See "Configuring Single Sign-On using Oracle Access Manager 10g" in Oracle Fusion Middleware Application Security Guide.

  3. After installing and configuring OAM 10g, check that you can access all of the configured applications, and that the login is giving you access to all of your configured applications without prompting you to sign in again. Also test global logout where available and make sure you are logged out of all other related applications.

    For more information, see "Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates" in Oracle Fusion Middleware Application Security Guide, and Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

5.2.3.3 Configuring Oracle Single Sign-On for WebCenter Content

Oracle Single Sign-On (OSSO) is part of the 10g Oracle Application Server suite. OSSO is an enterprise-level single sign-on solution that works with the OC4J application server in conjunction with Oracle Internet Directory and Oracle HTTP Server (OHS) 11g.

If OSSO is already in place as the enterprise solution for your existing Oracle deployment, Oracle Fusion Middleware continues to support the existing OSSO as a solution. However, Oracle recommends that you consider upgrading to OAM 11g Single Sign-On solution.

This section provides information for integrating WebCenter Content with OSSO. Configuration information is provided for WebCenter Content (UCM), Records (URM), Inbound Refinery (IBR), and Site Studio (SS).

See also Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management, Oracle Fusion Middleware Application Security Guide, Oracle Fusion Middleware Upgrade Planning Guide, and Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management.

Before you can configure OSSO, ensure that the software is installed. OSSO and Oracle Delegated Administration Service are not part of the 11g release. Customers must download the 10.1.4.* versions of these products, which are compatible with 11g Oracle Internet Directory and Oracle Directory Integration Platform, to form what was known in 10g as the Application Server Infrastructure. For deployment instructions on these 10g products, read Chapter 4 "Installing and Configuring JAZN-SSO/DAS" in the Oracle Application Server Enterprise Deployment Guide (B28184-02) for Oracle Identity Management release 10.1.4.0.1. This manual is available on Oracle Technology Network at:

https://download.oracle.com/docs/cd/B28196_01/core.1014/b28184/toc.htm

  1. Configure OSSO. For details, see Oracle Fusion Middleware Application Security Guide.

    1. Append WebCenter Content Uniform Resource Identifier (URI) entries to the mod_wl_ohs.conf file. Use the appropriate location entries from the following example. Each entry in the example maps the incoming path to the appropriate Oracle WebLogic Server on which the corresponding application resides.

      In the following list of entries, hostname represents the name of the computer hosting the WebCenter Content server, and portnumber represents the port number of the Oracle WebLogic Server on which the corresponding applications resides. Replace hostname and portnumber with your system's host name and port name.

      Note:

      The URIs you forward depend on the WebCenter Content functionality that you have installed. Use the appropriate location entry for your functionality. For example: /cs, /adfAuthentication, /_ocsh, /ibr, /urm.

      For Site Studio, the URI to forward is configured by the customer. For example, if the site is accessed as /mysite, then you need to append a location entry for /mysite.

      Caution:

      The Content Server location /cs can be customized, so the /cs designation can not guarantee that HTTP requests will include the correct location. If /cs has been changed, then forward the location the administrator has configured.

      # WebCenter Content Server
      <Location /cs>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # WebCenter Content Server authentication
      <Location /adfAuthentication>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # WebCenter online help
      <Location /_ocsh>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # IBR
      <Location /ibr>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # URM
      <Location /urm>
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
      # SS
      <Location /customer-configured-site-studio
            SetHandler weblogic-handler
            WebLogicHost <hostname>
            WebLogicPort <portnumber>
      </Location>
      
    2. Modify the mod_osso.conf file (at ORACLE_HOME/ohs/conf/) to include WebCenter Content Uniform Resource Identifiers (URIs) to protect.

      Note:

      The URIs you protect depend on the WebCenter Content functionality that you have installed: Content Server (UCM), Inbound Refinery (IBR), Records (URM), and Site Studio (SS).

      For Site Studio, the URI to protect is configured by the customer. For example, if the site is accessed as /mysite, then you need to specify the URI /mysite.

      Functionality URI

      UCM

      /adfAuthentication

      IBR

      /ibr/adfAuthentication

      URM

      /urm/adfAuthentication

      SS

      /customer_configured_site_studio


  2. Configure the WebCenter Content domain by ensuring you perform these tasks. See "Configuring Single Sign-On using OracleAS SSO 10g" in Oracle Fusion Middleware Application Security Guide.

    1. Add and configure the OSSO Identity Asserter for the Oracle WebLogic Server for WebCenter Content. Oracle recommends the following Authentication Providers: OSSO Identity Asserter, OID Authenticator, Default Authenticator.

      The OID Authenticator provider is for the Oracle Internet Directory server, which is used in production-level systems. The Default Authenticator provider is for the Oracle WebLogic Server embedded LDAP server.

      Ensure that OSSOIdentityAsserter is set as the primary provider authenticator for the domain, so that user profiles can be retrieved from the associated Oracle Internet Directory server. If necessary, reorder the providers so they appear in the following order, with control flags set as listed:

      OSSOIdentityAsserter (REQUIRED)

      OIDAuthenticator (SUFFICIENT)

      DefaultAuthenticator (SUFFICIENT)

      Note:

      When the Oracle WebLogic Server domain for WebCenter Content is configured to use a different authentication provider than the DefaultAuthenticator provider, the new authentication provider must be the first authentication provider listed in the security realm configuration, or WebCenter Content will fail to load any user privileges. Make sure to re-order the authentication providers so the new authentication provider is listed before the DefaultAuthenticator provider. Also ensure that the DefaultAuthenticator control flag is set to SUFFICIENT. For more information, see Section 5.2.3.4, "Configuring the First Authentication Provider."

    2. Configure the Authentication provider. This is necessary to specify the external LDAP server for the user store, such as Oracle Internet Directory (OID) or Oracle Virtual Directory (OVD), to match the LDAP server used by OAM. For example, if OSSO is using OID, then an OID Authentication provider must be added to the Oracle UCM domain.

Note:

If the URL for WebCenter Content does not link correctly after completing the OSSO configuration, you might need to change the server host and server port values. For details, see Section 5.2.3.5, "Configuring the WebCenter Content URL for Single Sign-On."

5.2.3.4 Configuring the First Authentication Provider

When the Oracle WebLogic Server domain for WebCenter Content is configured to use an authentication provider other than its default authentication provider for user authentication (such as Oracle Internet Directory or another LDAP provider), the primary provider must be the first authentication provider listed in the security realm configuration, or login authentication will fail.

If the primary provider is not listed first (for example, it is listed below the Oracle WebLogic Server provider, DefaultAuthenticator), then WebCenter Content will fail to successfully load users' Group membership and therefore fail to load any user privileges. You can use the Oracle WebLogic Server Administration Console to change the order in which the configured authentication providers are called. For details, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

Note:

When you use Oracle Internet Directory, all WebCenter Content administrator and other users must be defined in Oracle Internet Directory.

Note:

The Content Server system assigns a Content Server administrator role to administrative users defined in the internal Oracle WebLogic Server user store. This is true regardless of whether Oracle Internet Directory is used or not used. However, if you use Oracle Internet Directory and the Oracle Internet Directory Authentication provider is not listed first, then any request by the Content Server instance to retrieve the roles of the Oracle WebLogic Server defined administrative users will fail.

Note:

As of 11g Release 1 (11.1.1.6.0) Oracle WebCenter Content supports use of the Oracle Virtual Directory library (libOVD) feature, which enables a site to use multiple providers for login and group membership information. For example, it would be possible to use both Oracle Internet Directory (OID) and Active Directory as sources of user and role information. For more information, see "Multi-LDAP Configuration in Oracle WebLogic Server" in Oracle Fusion Middleware Application Security Guide.

5.2.3.5 Configuring the WebCenter Content URL for Single Sign-On

When you configure an Oracle application for use with Single Sign-On (SSO) and have set up Oracle Access Manager (OAM) and Oracle Single Sign-On (OSSO), the WebCenter Content GET_ENVIRONMENT service provides the server name, server port, and relative webroot to the application service call (for example, the Oracle WebCenter Doclib service). However, the values provided by GET_ENVIRONMENT might not be correct for your SSO configuration.

If you want to redirect the application service to use the OHS server host and server port (because both OAM and OSSO solutions require front-end applications with OHS), you must modify the WebCenter Content server host and server port configuration values.

You can use either of the following two methods to modify the WebCenter Content server host and server port values:

  • Use the Oracle WebLogic Server Administration Console. See Section 2.4.1, "Modifying Server Configuration Parameters for Content Server."

  • Use the WebCenter Content standalone application named SystemProperties.

    1. Go to the WebCenter Content domain directory.

    2. Change the directory to ucm/cs/bin

    3. Run the standalone application: ./SystemProperties

    4. On the SystemProperties screen, select the Internet tab.

    5. Update the HTTP Server address to the OHS (or Load Balancer) server host and server port values.

    6. Exit the SystemProperties screen.

    7. Restart the Oracle WebLogic Server domain.

5.2.3.6 Configuring WebCenter Content and Single Sign-On for WNA

Setting up WebCenter Content and single sign-on (SSO) with Microsoft clients for Windows Native Authentication (WNA) requires configuring the Microsoft Active Directory, the client, and the Oracle WebLogic Server domain. Details including system requirements for SSO with Microsoft clients are provided in "Configuring Single Sign-On with Microsoft Clients" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

As part of configuring SSO with Microsoft clients, you must specify a LDAP authentication provider to access the external Microsoft Active Directory. Oracle WebLogic Server offers a LDAP provider already configured for Microsoft Active Directory: the Active Directory Authentication provider. See "Configuring LDAP Authentication Providers" in Oracle WebLogic Server Securing Oracle WebLogic Server.

Note:

When the Oracle WebLogic Server domain for WebCenter Content is configured to use a different authentication provider than the DefaultAuthenticator provider, the new authentication provider must be the first authentication provider listed in the security realm configuration, or WebCenter Content will fail to load any user privileges. Make sure to re-order the authentication providers so the new authentication provider is listed before the DefaultAuthenticator provider. Also ensure that the DefaultAuthenticator control flag is set to SUFFICIENT. For more information, see Section 5.2.3.4, "Configuring the First Authentication Provider."

As part of configuring SSO with Microsoft clients, you must configure the Negotiate Identity Assertion provider in Oracle WebLogic Server security realm. The identity assertion provider decodes Simple and Protected Negotiate (SPNEGO) tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users. Use the Oracle WebLogic Server Administration Console to add a new provider in the appropriate security realm in the domain structure, assign it a name, then select NegotiateIdentityAsserter for its Type. Activate the changes and restart the Oracle WebLogic Server. Now your server can use the Kerberos ticket it receives from the browser.

You must redeploy each WebCenter Content application (Content Server, Inbound Refinery, Records) that will be used in the Windows Native Authentication (Kerberos) environment, using an associated deployment plan. A deployment plan is a XML document. Oracle provides a plan for each of the three Oracle UCM applications: cs-deployment-plan.xml, ibr-deployment-plan.xml, and urm-deployment-plan.xml. You also can implement a deployment plan using the Oracle WebLogic Scripting Tool.

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. Click Deployments in the Domain Structure navigation tree.

  3. On the Control tab, click Next until you see the WebCenter Content deployment you want to change:

    • Oracle WebCenter Content Server

    • Oracle WebCenter Content: Inbound Refinery

    • Oracle WebCenter Content: Records

  4. Select the checkbox to the left of the deployment to be changed.

  5. Click Update.

  6. Under the Deployment plan path, select Change Path.

  7. Navigate to and select the appropriate plan file:

    • cs-deployment-plan.xml (for Content Server)

    • ibr-deployment-plan.xml (for Inbound Refinery)

    • urm-deployment-plan.xml (for Records)

  8. Verify that Redeploy this application using the following deployment files is selected.

  9. Click Next.

  10. Click Finish.

  11. To verify that SSO with Microsoft clients is configured properly, point a browser to the Microsoft Web application or Web service you want to use. If you are logged on to a Windows domain and have Kerberos credentials acquired from the Active Directory server in the domain, you should be able to access the Web application or Web service without providing a username or password.

cs-deployment-plan.xml

Use the provided cs-deployment-plan.xml file, or create a .xml file and name it cs-deployment-plan.xml.

<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan
    xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd"
    global-variables="false">
  <application-name>cs.ear</application-name>
  <variable-definition>
   <variable>
      <name>http-only</name>
      <value>false</value>
    </variable>
  </variable-definition>
  <module-override>
    <module-name>cs.war</module-name>
    <module-type>war</module-type>
    <module-descriptor external="false">
      <root-element>weblogic-web-app</root-element>
      <uri>WEB-INF/weblogic.xml</uri>
      <variable-assignment>
        <name>http-only</name>
        <xpath>/weblogic-web-app/session-descriptor/cookie-http-only</xpath>
      </variable-assignment>
    </module-descriptor>
  </module-override>
</deployment-plan>

ibr-deployment-plan.xml

Use the provided ibr-deployment-plan.xml file, or create a .xml file and name it ibr-deployment-plan.xml.

<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd" global-variables="false">
  <application-name>ibr.ear</application-name>
  <variable-definition>
   <variable>
      <name>http-only</name>
      <value>false</value>
    </variable>
  </variable-definition>
  <module-override>
    <module-name>ibr.war</module-name>
    <module-type>war</module-type>
    <module-descriptor external="false">
      <root-element>weblogic-web-app</root-element>
      <uri>WEB-INF/weblogic.xml</uri>
      <variable-assignment>
        <name>http-only</name>
        <xpath>/weblogic-web-app/session-descriptor/cookie-http-only</xpath>
      </variable-assignment>
    </module-descriptor>
  </module-override>
</deployment-plan>

urm-deployment-plan.xml

Use the provided urm-deployment-plan.xml file, or create a .xml file and name it urm-deployment-plan.xml.

<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan 
    xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd" 
    global-variables="false">
  <application-name>urm.ear</application-name>
  <variable-definition>
   <variable>
      <name>http-only</name>
      <value>false</value>
    </variable>
  </variable-definition>
  <module-override>
    <module-name>urm.war</module-name>
    <module-type>war</module-type>
    <module-descriptor external="false">
      <root-element>weblogic-web-app</root-element>
      <uri>WEB-INF/weblogic.xml</uri>
      <variable-assignment>
        <xpath>/weblogic-web-app/session-descriptor/cookie-http-only</xpath>
      </variable-assignment>
    </module-descriptor>
  </module-override>
</deployment-plan>

5.2.4 Configuring Oracle Infrastructure Web Services

Oracle Infrastructure Web services provide the ability to create and attach policy sets to subjects on a global scope (domain, server, application, or SOA composite). Oracle Infrastructure Web services are implemented according to the Web services for Java EE 1.2 specification, which defines the standard Java EE runtime architecture for implementing Web services in Java. The specification also describes a standard Java EE Web service packaging format, deployment model, and runtime services, all of which are implemented by Oracle Infrastructure Web services.

For information on applying OWSM security to Web services, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Serices.

Differences in behavior, and any limitations, for Oracle Infrastructure Web services supported on IBM WebSphere are described in "Managing Web Services on IBM WebSphere" in Oracle Fusion Middleware Third-Party Application Server Guide.

5.3 User Types, Logins, and Aliases

This section covers the following topics:

5.3.1 Introduction to User Login Types

Oracle WebCenter Content Server software supports the following user login types:

5.3.1.1 External Users

External users are defined outside the WebCenter Content system and authenticated by external security using the Oracle WebLogic Server Administration Console and Oracle Platform Security Services (OPSS). Once authenticated, external users can access the Content Server instance through Oracle WebLogic Server. Generally, external users are users in a trusted domain to whom you grant access, but do not manage through the WebCenter Content system. Their passwords are owned by the Oracle WebLogic Server domain, the network domain, or another provider such as Oracle Internet Directory, although the User Admin applet can be used to set a user password when converting an external user to a local user. Unlike local users, undefined external users are not assigned the guest role.

The first time users log in to the Content Server instance through Oracle WebLogic Server they are added to the Content Server database, and administrators can view external user information through the Repository Manager. However, external users are not automatically included in user lists, such as the Author field on a content Check In page. If an Override checkbox is selected on a user's User Profile page, any user information defined in the Content Server database overrides the user information derived from the external user base.

The Admin User applet only shows users after they have logged in at least one time to a Content Server instance. All users from the Oracle WebLogic Server user store or other user store outside the Content Server instance are shown as external users.

By default, external security integrations map a limited set of user information (user name, password, roles, accounts, and some additional information such as e-mail address) from the external user base to the Content Server instance. If you are using LDAP integration, then additional user information, such as e-mail address or user locale, can be mapped from the embedded LDAP server with the Oracle WebLogic Server Administration Console and integrated with Oracle Platform Security Services.

The following is a list of common characteristics of external users:

  • Login (authentication) is defined by: User ID and password are stored in a user database external to the WebCenter Content system, such as:

    • Trusted domain (such as Oracle WebLogic Server)

    • Lightweight Directory Application Protocol (LDAP)

    • Other database

  • Access (authorization) is determined by: Credentials (for example, roles) from a trusted domain or other user database (such as the Oracle WebLogic Server user store, Oracle Internet Directory, or another LDAP provider) and WebCenter Content.

  • User login: Oracle WebLogic Server and the Content Server instance must be running for users to log in.

  • User password: User passwords are defined on Oracle WebLogic Server or another user database (such as a LDAP server) by the administrator. Users cannot change their passwords on the Content Server instance.

  • Interface issues: User names do not appear in the content check-in lists. However, users can participate in workflows.

Follow this process to set up roles, groups, and accounts for external users:

  1. Set up security groups. See Section 5.4.2.1, "Adding a Security Group on Content Server."

  2. Establish roles. See Section 5.4.4.1, "Creating a Role on Content Server."

  3. Arrange permissions. See Section 5.4.4.5, "Adding and Editing Permissions on Content Server."

  4. (Optional) Use accounts. See Section 5.5.2.1, "Enabling Accounts on Content Server."

For details about creating external users, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

5.3.1.2 Local Users

Local users are defined by an administrator within the Content Server instance. Administrators assign these users one or more roles, which provide the user with access to security groups.

Caution:

Local users are not supported on the Oracle WebLogic Server domain. Although Oracle WebCenter Content Server administrators can create and configure local users with the User Admin applet, for local users to be authenticated for access to the Content Server instance, the users and passwords also must be created with the Oracle WebLogic Server Administration Console. The default user type supported in 11g Release 1 (11.1.1) is External Users.

The following is a list of common characteristics of local users:

  • Logins (authentication) are created by: Administrator in the Content Server system.

  • Access (authorization) is determined by: Content Server roles, which provide access to security groups.

  • User login: Local users cannot log in to the Content Server Admin Server because the Admin Server requires logging in through Oracle WebLogic Server.

  • User password: Users can change their passwords.

  • Interface issues: User names appear in the content check-in lists. Users can specify whether to change full name, e-mail address, and user type.

  • Considerations: Previously recommended for 1000 or fewer users, but now recommended only when required by the system administrator for purposes such as troubleshooting the Content Server system. Because of performance considerations, do not configure more than 1000 local users.

Follow this process to set up local users:

  1. Set up security groups. See Section 5.4.2.1, "Adding a Security Group on Content Server."

  2. Establish roles. See Section 5.4.4.1, "Creating a Role on Content Server."

  3. Arrange permissions. See Section 5.4.4.5, "Adding and Editing Permissions on Content Server."

  4. Assign user logins. See Section 5.3.3.1, "Adding a User Login."

  5. (Optional) Use accounts. See Section 5.5.2.1, "Enabling Accounts on Content Server."

5.3.2 Introduction to User Logins and Aliases

User logins are the names associated with the people who access the Content Server system. In 11g Release 1 (11.1.1) and later, by default user logins must be created on the Oracle WebLogic Server domain that hosts WebCenter Content and the Content Server instance. Authentication and credentials are handled by default with the Oracle WebLogic Server user store and associated security software instead of by the Content Server. For more information, see Oracle Fusion Middleware Application Security Guide.

Note:

Instructions for using the Oracle WebLogic Server Administration Console apply to users and groups in the Oracle WebLogic Authentication provider only. If you customize the default security configuration to use a custom Authentication provider, use the administration tools supplied by that security provider to create a user. If you are upgrading to the Oracle WebLogic Server Authentication provider, you can load existing users and groups into its database. See "Migrating Security Data" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Caution:

Although user logins still can be created and managed on the Content Server with the User Admin applet, they are not valid for authentication purposes unless they also have been created with the Oracle WebLogic Server Administration Console.

If you use a LDAP server and create a user login with the same name as a local user defined in the Content Server system with the User Admin applet, the LDAP user is authenticated against LDAP when logging in, but receives roles assigned to the local user.

The Oracle WebLogic Server administrator assigns one or more groups to each user. A group provides the user access to files within the security groups. Undefined users are assigned to the guest group, which allows viewing of documents only in the Public security group by default.

You can also create a group of users that can be then referenced by a single name, or alias, in workflows, subscriptions, and projects. For example, it is much easier to add an alias called Support to a workflow than it is to add user1, user2, user3, and so on.

If you log in to multiple browser windows on the same computer using different login methods (such as standard login, Microsoft login, or self-registered login), the Content Server can become confused about which user is logged in to each window. Remember to close any open browser windows while testing different login methods.

Important:

User logins are case sensitive.

5.3.3 Managing Logins and Aliases

By default, user logins must be created and managed with the Oracle WebLogic Server Administration Console. For information and instructions on creating and managing user logins, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help. If you customize the default security configuration to use another Authentication provider, such as Oracle Internet Directory, use the administration tools supplied by that security provider to create and manage user logins.

If you need to set up a user (other than the Content Server administrator) to work with a standalone Content Server utility such as System Properties, you can use the User Admin applet in the Content Server system to create a local user. However, a user created with the User Admin applet cannot be authenticated for any other functions than standalone Content Server utilities, unless the user is also created with the Oracle WebLogic Server Administration Console.

The remainder of this section discusses the tasks involved in managing only Content Server user logins for standalone utilities.

5.3.3.1 Adding a User Login

Note:

As of 11g Release 1 (11.1.1), user logins must be added using the Oracle WebLogic Server Administration Console. Although user logins can be managed in the Content Server system for special purposes, they are not valid for authentication to the Content Server system until they have been created with the Oracle WebLogic Server Administration Console. For information and instructions on creating and managing these user logins, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

To add a user login only for use with Content Server standalone utilities:

  1. From the User Admin Screen: Users Tab, click Add.

  2. Set the Authorization Type from the menu. For more information, see Section 5.3.1, "Introduction to User Login Types."

  3. Click OK.

    The Add/Edit User Screen is displayed.

  4. Enter information about the user.

    • If you enter a password, you must reenter the same password in the Confirm Password field.

    • Keep in mind that the user name and password are case-sensitive.

  5. Assign roles to the user.

  6. If accounts are enabled, assign accounts to the user.

  7. Click OK.

5.3.3.2 Editing a User Login

Note:

As of 11g Release 1 (11.1.1), user logins must be edited using the Oracle WebLogic Server Administration Console. Although user logins can be managed in the Content Server system for special purposes, they are not valid for authentication to the Content Server system until they have been created with the Oracle WebLogic Server Administration Console. For information and instructions on editing and managing user logins, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

To edit a user login only for use with Content Server standalone utilities:

  1. From the Users tab of the User Admin Screen, double-click the user name, or select the user name and click Edit.

    The Add/Edit User Screen or Add/Edit User Screen: Info Tab (Global User) is displayed.

  2. Edit the user login as necessary.

If you change the user locale for a user who has the sysmanager role, you must restart the Admin Server service for the Admin Server interface to appear in the user's locale language.

5.3.3.3 Deleting a User Login

Note:

As of 11g Release 1 (11.1.1), user logins must be deleted using the Oracle WebLogic Server Administration Console. Although user logins can be managed in the Content Server system for special purposes, they are not valid for authentication to the Content Server system until they have been created with the Oracle WebLogic Server Administration Console. For information and instructions on deleting and managing user logins, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

To delete a user login only for use with Content Server standalone utilities:

  1. On the Users tab of the User Admin Screen, select the user name.

  2. Click Delete.

    A confirmation screen is displayed.

  3. Click Yes.

If you delete a user who is involved in a workflow, you are prompted to confirm the deletion. You must adjust the workflow and remove the user from the list of workflow reviewers.

5.3.3.4 Creating an Alias

Note:

As of 11g Release 1 (11.1.1), user logins must be managed using the Oracle WebLogic Server Administration Console. Although user logins can be managed in the Content Server system for special purposes, they are not valid for authentication to the Content Server system until they have been created with the Oracle WebLogic Server Administration Console. For information and instructions on creating and managing user logins, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

To define an alias only for use with Content Server standalone utilities:

  1. Display the User Admin Screen: Aliases Tab.

  2. Click Add.

    The Add New Alias/Edit Alias Screen is displayed.

  3. In the Alias Name field, enter a name that identifies the group of users.

  4. In the Description field, enter a detailed description of the alias.

  5. Click Add.

    The Select Users Screen is displayed.

  6. Select the user names from the list.

    • To narrow the list of users on the Select Users screen, select Use Filter, click Define Filter, select the filter criteria, and click OK.

    • To select a range of users, click one user login and then hold down the Shift key while clicking another user login.

    • To select users individually, hold down the Ctrl key while clicking each user login.

  7. Click OK.

  8. Close the User Admin screen.

5.3.3.5 Editing an Alias

Note:

As of 11g Release 1 (11.1.1), user logins must be managed with the Oracle WebLogic Server Administration Console. Although user logins can be managed in the Content Server system for special purposes, they are not valid for authentication to the Content Server system until they have been created with the Oracle WebLogic Server Administration Console. For information and instructions on editing and managing user logins, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

To edit an alias only for use with Content Server standalone utilities:

  1. Display the User Admin Screen: Aliases Tab.

  2. Highlight an alias and click Edit.

    The Add New Alias/Edit Alias Screen is displayed.

  3. Alter the information as needed.

  4. In the Description field, enter a detailed description of the alias.

  5. Click OK.

  6. Close the User Admin screen.

5.3.3.6 Deleting an Alias

Note:

As of 11g Release 1 (11.1.1), user logins must be managed with the Oracle WebLogic Server Administration Console. Although user logins can be managed in the Content Server system for special purposes, they are not valid for authentication to the Content Server system until they have been created with the Oracle WebLogic Server Administration Console. For information and instructions on deleting and managing user logins, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

To delete an alias only for use with Content Server standalone utilities:

  1. Display the Add New Alias/Edit Alias Screen.

  2. Highlight the alias to be deleted and click Delete.

    A screen appears, asking you to confirm the deletion. Click Yes to delete the entry or No to retain it.

  3. Close the User Admin screen.

5.3.4 User Information Fields

This section covers these topics:

5.3.4.1 About User Information Fields

User information defines the unique attributes of a user, such as full name, password, and e-mail address. User information fields describe a user in the same way that metadata fields describe a content item. User information is stored in the Content Server database, and can be used to sort users, display user information on Content Server web pages, or customize the display of web pages based on user attributes.

The following user information fields are predefined in the system. These fields cannot be deleted, and the field name and type cannot be changed.

Name Type Caption Is Option List

dFullName

Long Text

Full Name

False

dEmail

Long Text

E-mail Address

False

dUserType

Text

User Type

True

dUserLocale

Text

User Locale

True


5.3.4.2 Managing User Information Fields

This section describes the tasks involved in managing user information fields.

5.3.4.2.1 Adding a New User Information Field

To add a new user information field:

  1. On the User Admin Screen: Information Fields Tab, click Add.

    The Add Metadata Field Name Screen is displayed.

  2. Enter a new field name. Duplicate names are not allowed. Maximum field length is 29 characters. The following are not acceptable: spaces, tabs, line feeds, carriage returns and ; ^ ? : @ & + " # % < * ~ |

  3. Click OK.

    The Edit Metadata Field Screen is displayed.

  4. Configure the properties for the field, and click OK.

  5. Click Update Database Design.

5.3.4.2.2 Editing an Option List

To edit an option list key:

  1. On the Edit Metadata Field Screen, select Enable Option List.

  2. Click Edit.

    The Option List Screen is displayed.

  3. Add, edit, or delete option values.

    • Each value must appear on a separate line.

    • A blank line will result in a blank value in the option list.

  4. To sort the list, select sort options and click Sort Now.

  5. Click OK.

5.3.4.2.3 Editing a User Information Field

To edit a user information field:

  1. Double-click the field, or select the field and click Edit.

    The Edit Metadata Field Screen is displayed.

  2. Add, edit, or delete option values.

  3. Click OK.

5.4 Security Groups, Roles and Permissions

This section covers the following topics:

5.4.1 Introduction to Content Server Security Groups

A security group is a set of files grouped under a unique name. Every file in the Content Server repository belongs to a security group. Access to security groups is controlled by the permissions, which are assigned to roles on the Content Server system. Roles are assigned to users where they are managed with Oracle WebLogic Server.

Users are assigned groups with the Oracle WebLogic Server Administration Console. When a user logs in to the Content Server instance, the user's groups are mapped to Content Server roles. Oracle WebLogic Server user groups that start with a @ ("at") symbol are mapped to Content Server accounts.

For Oracle WebLogic Server groups to be recognized in the Content Server system, roles with the exact same names must be created in the Content Server system and assigned to security groups. If this is not done, the Oracle WebLogic Server groups assigned to users have no impact on users' privileges on the Content Server system.

Security groups enable you to organize content files into distinct groups that can be accessed only by specific users. For example, files could be assigned to a security group with the name HRDocs, which could represent documents under the Human Resources designation, and could be accessed only by people who worked in the Human Resources department. There are two predefined security groups:

  • Public: By default, any user can view documents in the Public group without logging in.

  • Secure: System files are stored in the Secure group and are available only to the system administrator.

5.4.1.1 Best Practices for Working with Security Groups

Keep these considerations in mind when you define security groups:

  • Define security groups before anyone checks in files that must be secure.

  • The number of security groups should be kept at a minimum to provide optimum search performance and user administration performance. If your security model requires more than 50 security classifications, you should enable accounts and use them to control user permissions. This number varies depending on Search Performance and User Admin Performance.

  • Put all files that share the same access into one security group.

  • Set up a logical naming convention for your security groups. For example, use department names if you are setting up an intranet, and use levels of security (internal, classified, and so forth) if you are setting up an extranet.

For example, Figure 5-1 shows three defined security groups (Public, HRDocs, and EngDocs). They are associated with five users assigned different roles (Admin, Contributor, Guest, Sysadmin, Subadmin) and specific sets of permissions (Read, Write, Delete, Admin).

Figure 5-1 Example of Defining Security Groups

Description of Figure 5-1 follows
Description of "Figure 5-1 Example of Defining Security Groups"

5.4.1.2 Performance Considerations

Your user access choices for security groups and roles can affect the following system performance areas:

5.4.1.2.1 Search Performance

Search performance is affected by the number of security groups a user has permission to access. To return only content that a user has permission to view, the database WHERE clause includes a list of security groups. The WHERE clause either includes all of the security groups the user has permission to access, or it includes all of the security groups the user does not have permission to access. Which approach is taken depends on whether the user has permission to more than 50% or fewer than 50% of the defined security groups.

For example, if 100 security groups are defined, and a user has permission to 10 security groups, the 10 security groups will be included in the WHERE clause. In contrast, for a user with permission to access 90 security groups, the WHERE clause includes the 10 security groups the user does not have permission to access.

Therefore, if a user has permission to almost 50% of the security groups, the search performance is less efficient. If a user has permission to all or none of the security groups, the search performance is more efficient.

5.4.1.2.2 User Admin Performance

The total number of security groups multiplied by the total number of roles determines the number of rows in the RoleDefinition database table, which affects the performance of the User Admin application for operations involving local users. To determine the approximate time required to perform an operation in the User Admin application, such as adding a security group or changing permission for a role, use the following formula:

(# of security groups) X (# of roles) / 1000 = Time of operation in seconds

For example, using a PC with a 400 MHz processor, 128 MB of RAM, it took approximately 10 seconds to add a security group, or role, or both, using the User Admin application when the RoleDefinition table has 10,000 rows.

As the number of security groups increases, administration performance is affected more than consumer search performance.

5.4.2 Managing Content Server Groups

The following tasks are used to manage security groups using the Content Server system.

For information on managing groups, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

5.4.2.1 Adding a Security Group on Content Server

To create a security group and assign permissions:

  1. From the User Admin Screen, select Security then Permissions by Group.

    The Permissions By Group Screen is displayed.

  2. Click Add Group to display the Add New Group Screen.

  3. Enter a group name and description.

  4. Click OK.

  5. Set permissions for the security group:

    1. Select the security group.

    2. Select the role to edit.

    3. Click Edit Permissions.

    4. After enabling the permissions that you want the role to have for the group, click OK to close the Permissions by Group screen.

5.4.2.2 Deleting a Security Group on Content Server

Note:

Never delete a security group or account if it is associated with a content item stored in the Content Server repository.

To delete a security group:

  1. Make sure that no content items are assigned to the security group you want to delete. You cannot delete a security group if content still exists in that security group.

  2. From the User Admin Screen, select Security then Permissions by Group.

    The Permissions By Group Screen is displayed.

  3. Select the group you want to delete.

  4. Click Delete Group.

    A confirmation screen is displayed.

  5. Click Yes.

    The security group is deleted.

  6. After you have deleted the security group, click OK to close the Permissions by Group screen.

5.4.3 Introduction to Content Server Roles and Permissions

A role is a set of permissions (Read, Write, Delete, Admin) for each security group. You can think of a role as a user's job. Users can have different jobs for various security groups. Users can also have different jobs to identify the different teams in which they participate. You can:

  • Define roles.

  • Assign multiple roles to a user.

  • Set up multiple users to share a role.

  • Set the role's permissions to multiple security groups.

For example, Figure 5-2 shows three roles and the permissions those roles have to the same security group.

Figure 5-2 Example of Roles and Their Permissions

Description of Figure 5-2 follows
Description of "Figure 5-2 Example of Roles and Their Permissions"

Roles are assigned to one or more users by the system administrator to provide access to the security groups. Figure 5-3 shows the EngUsers role with only Read permission to the HRDocs security group. However, this role provides Read, Write, and Delete permissions to the EngDocs security group. This provides an added measure of security, ensuring that only users who need access to certain documents can modify them.

Figure 5-3 Example of Roles and Security Group Access

Description of Figure 5-3 follows
Description of "Figure 5-3 Example of Roles and Security Group Access"

5.4.3.1 Predefined Roles

The following roles are predefined on the Content Server system:

Roles Description

admin

The admin role is assigned to the system administrator. By default, this role has Admin permission to all security groups and all accounts, and has rights to all administration tools.

contributor

The contributor role has Read and Write permission to the Public security group, which enables users to search for, view, check in, and check out content.

guest

The guest role has Read permission to the Public security group, which enables users to search for and view content.

sysmanager

The sysmanager role has privileges to access the Admin Server on the Content Server system.


5.4.3.2 About Permissions

Each role allows the following permissions for each security group: Read (R), Write (W), Delete (D), or Admin (A). The permission that a user has to access the files in a security group is the highest permission defined by any of the user's roles. If a user has the guest and contributor roles, where guest is given Read permission and contributor is given Write permission to the Public security group, the user will have Write permission to content in the Public security group.

As shown in Figure 5-4, Joe Smith and Ann Wallace have permissions to two security groups:

  • Joe Smith has Read, Write, and Delete permission to the EngDocs security group, but only Read permission to the HRDocs security group. As a member of the EngUsers role, he has been given Read, Write, and Delete access to Engineering Documents, but only Read access to Human Resource documents.

  • Ann Wallace has Read, Write, and Delete permission to the HRDocs security group, but only Read permission to the EngDocs security group. As a member of the HRUsers role, she has been given Read, Write, and Delete access to Human Resource documents, but only Read access to Engineering documents.

Figure 5-4 Example of Assigned Permissions

Description of Figure 5-4 follows
Description of "Figure 5-4 Example of Assigned Permissions"

5.4.3.3 Predefined Permissions

Each role allows the following permissions to be assigned for each security group:

Permission Description

Read

Allowed to view documents in the security group.

Write

Allowed to view, check in, check out, and get a copy of documents in the security group. The author can change the security group setting of a document if the author has Write permission in the new security group.

Delete

Allowed to view, check in, check out, get a copy, and delete documents in the security group. The configuration setting AuthorDelete=true adds delete permission to all security groups to which the author has Write permission.

Admin

Allowed to view, check in, check out, get a copy, and delete files in the security group. If the user has Workflow rights, the user can start or edit a workflow in the security group.

The user is allowed to check in documents in the security group with another user specified as the Author. As a non-author of a document, the user can change the security group setting of the document if the user has Write permission in the new security group.


5.4.4 Managing Content Server Roles and Permissions

Roles and permissions are defined and managed on the Content Server system. Roles are assigned to user logins, which by default are managed with the Oracle WebLogic Server Administration Console.

The following tasks are used to manage user roles.

5.4.4.1 Creating a Role on Content Server

To create a role and configure permissions on the Content Server system:

  1. From the User Admin Screen, select Security then Permissions by Role.

    The Permissions By Role Screen is displayed.

  2. Click Add New Role.

    The Add New Role Screen is displayed.

  3. Enter a Role Name.

  4. Set permissions for the role:

    1. Select the role.

    2. Select the security group to edit.

    3. Click Edit Permissions.

    4. Edit the permissions.

    5. Click OK and close the Permissions By Role Screen.

5.4.4.2 Deleting a Role on Content Server

To delete a role on the Content Server system:

  1. Make sure that no users are assigned to the role to delete. (You can not delete a role if any users are assigned to it.)

  2. From the User Admin Screen, select Security then Permissions by Role.

    The Permissions By Role Screen is displayed.

  3. Select the role to delete.

  4. Click Delete Role.

    A confirmation screen is displayed.

  5. Click Yes.

5.4.4.3 Assigning Roles to a User with Oracle WebLogic Server

To assign roles to a user for the Content Server system, use the Oracle WebLogic Server Administration Console. While roles are defined on Content Server, they must be assigned to users with the Administration Console.

Users can be assigned groups with the Oracle WebLogic Server Administration Console. For Oracle WebLogic Server groups to be recognized in the Content Server system, roles with the exact same names must be created in the Content Server system and assigned to security groups.

5.4.4.4 Assigning Roles for a Similar User with Oracle WebLogic Server

To assign roles when creating a user for the Content Server system that has similar access to that of another user login, use the Oracle WebLogic Server Administration Console. While roles are defined on the Content Server system, they must be assigned to users with the Administration Console.

Users can be assigned groups with the Oracle WebLogic Server Administration Console. For Oracle WebLogic Server groups to be recognized in the Content Server system, roles with the exact same names must be created in the Content Server system and assigned to security groups.

5.4.4.5 Adding and Editing Permissions on Content Server

To add permissions to a role or edit existing permissions on the Content Server system:

  1. From the User Admin Screen, select Security then Permissions by Role.

    The Permissions By Role Screen is displayed.

  2. Either select an existing role, or add a new role.

    The permissions associated with the security groups are displayed.

  3. Select an item in the Groups/Rights column.

  4. Click Edit Permissions.

    The Edit Permissions Screen is displayed.

  5. Specify the permissions to associate with this role and security group. See Section 5.4.3.3, "Predefined Permissions."

  6. Click OK.

5.5 Accounts

Accounts are defined and managed on the Content Server system. Account permissions are assigned to user logins with the Oracle WebLogic Server Administration Console.

This section covers the following topics:

5.5.1 Introduction to Content Server Accounts

Accounts give you greater flexibility and granularity in your security structure than security groups alone provide. Accounts and account permissions are assigned to users with the Oracle WebLogic Server Administration Console, and the server maps groups to Content Server roles and accounts. An account also can be assigned to each content item. To access a content item that has an account assigned to it, the user must have the appropriate permission to the account.

Oracle WebLogic Server user groups that start with a @ ("at") symbol are mapped to Content Server accounts.

Note:

If you enable accounts and use them, then later choose to disable accounts, you can have the perception of losing data. The repository remains intact. However, if you make certain changes to the security model, then you also must update the users' access rights so they can continue to access the secure content.

To avoid this situation, examine your requirements and the WebCenter Content security model of groups and accounts to determine what would best match your needs. Unless you are certain that you want to use accounts, do not enable them.

There are several ways accounts can be created:

You must enable accounts to use them. For more information, see Section 5.5.2.1, "Enabling Accounts on Content Server."

5.5.1.1 Accounts and Security Groups

When accounts are used, the account becomes the primary permission to satisfy before security group permissions are applied. You can also think of a user's access to a particular document as the intersection between their account permissions and security group permissions.

For example, the EngAdmin role has Read, Write, Delete, and Admin permission to all content in the EngDocs security group. A user is assigned the EngAdmin role, and is also assigned Read and Write permission to the AcmeProject account. Therefore, the user has only Read and Write permission to a content item that is in the EngDocs security group and the AcmeProject account.

Figure 5-5 shows the intersection of the AcmeProject account and EngDocs security group permissions.

Figure 5-5 Example of Security Group Permissions

Description of Figure 5-5 follows
Description of "Figure 5-5 Example of Security Group Permissions"

Security group permissions are ignored if the account does not permit access to any content. Remember that the account acts as a filter that supersedes the permissions defined by the user's roles.

5.5.1.2 Hierarchical Accounts

Accounts can be set up in a hierarchical structure, which enables you to give some users access to entire branches of the structure, while limiting permissions for other users by assigning them accounts at a lower level in the structure. Figure 5-6 shows a typical hierarchical account structure.

Figure 5-6 Example of Hierarchical Account Structure

Description of Figure 5-6 follows
Description of "Figure 5-6 Example of Hierarchical Account Structure"

Important:

Because account names form part of the directory path for the URL of a content item, account names cannot exceed 30 characters.

  • If you use slashes to separate the levels in account names (for example, Eng/Acme/Budget), the Content Server system creates a weblayout directory structure according to your account structure. (However, each actual directory will not be created until a content item is assigned to the account during the check-in process.) Each lower level in the account name becomes a subdirectory of the upper level, with an @ symbol prefix to indicate that the directory is an account level.

    When using an embedded LDAP server, do not use the slash. The usage of backslashes (/) and forward slashes (\) is not recommended for security groups when using a WebLogic Console.

  • If a user has permission to a particular account prefix, they have access to all accounts with that prefix. For example, if you are assigned the Eng/XYZ account, you have access to the Eng/XYZ account and any accounts that begin with the Eng/XYZ prefix (such as Eng/XYZ/Schedule and Eng/XYZ/Budget).

    Important:

    The account prefix does not have to include slashes. For example, if you have accounts called abc, abc_docs, and abcdefg, all users who have access to the abc account will have access to the other two accounts as well.

To handle the security structure depicted above, you would create the following accounts:

  • Eng

  • Eng/Acme

  • Eng/XYZ

  • Eng/Acme/Schedule

  • Eng/Acme/Budget

  • Eng/XYZ/Schedule

  • Eng/XYZ/Budget

Figure 5-7 Example of a Security File Structure

Description of Figure 5-7 follows
Description of "Figure 5-7 Example of a Security File Structure"

5.5.1.3 Performance Considerations

Consider the following performance issues when using accounts in your security model:

  • Theoretically, you can create an unlimited number of accounts without affecting Content Server performance. A system with over 100,000 pieces of content has only limited administration performance problems at 200 accounts per person; however, there is significant impact on search performance with over 100 accounts per person. (Note that these are explicit accounts, not accounts that are implicitly associated with a user through a hierarchical account prefix. A user can have permission to thousands of implicit accounts through a single prefix.)

  • For performance reasons, do not use more than approximately 50 security groups if you enable accounts.

  • Ensure that your security groups and accounts have relatively short names.

5.5.1.4 External Directory Server Considerations

Accounts are available whether or not your Content Server instance is integrated with an external directory server (such as the default Oracle WebLogic Server). When you use accounts with an external directory, ensure that you follow these guidelines:

  • Set up a global group with the appropriate users in it to match the account.

  • Associate group names to either a role or an account by configuring mapping prefixes.

5.5.2 Managing Content Server Accounts

The following tasks are involved in managing accounts.

5.5.2.1 Enabling Accounts on Content Server

To enable accounts on the Content Server system:

Important:

If you enable accounts and use them, then choose to disable accounts, you can have the perception of losing data. The repository remains intact. However, if you make certain changes to the security model, then you also must update the security settings for users so they can continue to access the content.

  1. On the Content Server portal, choose Administration then Admin Server.

  2. On the Admin Server page, select General Configuration.

  3. On the General Configuration page, select Enable Accounts to enable accounts.

  4. Save the changes.

  5. Restart the Oracle WebCenter Content Server instance.

Alternately, you can access the General Configuration page from the Admin Server, then add the following line to the Additional Configuration Variables field, which shows the contents of the IntradocDir/config/config.cfg file:

UseAccounts=true

Save the changes, and restart the Content Server instance.

5.5.2.2 Creating Predefined Accounts on Content Server

To create a predefined account on the Content Server system:

  1. From the User Admin screen, select Security then Predefined Accounts.

    The Predefined Accounts Screen is displayed.

  2. Click Add.

    The Add New Predefined Account Screen is displayed.

  3. Add the name of the new account. Keep the names short and consistent. For example, set up all of your accounts with a three-letter abbreviation by location or department (MSP, NYC, etc.). Account names can be no longer than 30 characters, and the following are not acceptable: spaces, tabs, line feeds, carriage returns, and the symbols : ; ^ ? : & + " # % < > * ~.

  4. Click OK.

  5. If you already have content checked into the Content Server system and you are using a database with full text indexing, rebuild your search index.

    If you are using only the metadata database search indexer engine, you do not need to rebuild your search index.

5.5.2.3 Creating Accounts When Checking In Content on Content Server

Generally, you should create predefined accounts rather than creating an account during content checkin. See Section 5.5.2.2, "Creating Predefined Accounts on Content Server."

To create an account at the time you check in a content item, you must have User Admin rights, and perform these tasks:

  1. Display the Content Check In Form page.

  2. Enter all required and optional information.

  3. Type an account name in the Account field.

  4. Click Check In.

    The new account is assigned to the content item.

5.5.2.4 Deleting Predefined Accounts on Content Server

Note:

Never delete an account if it is associated with a content item stored in the Content Server repository.

To delete a predefined account on the Content Server system:

  1. Select Security then Predefined Accounts.

    The Predefined Accounts Screen is displayed.

  2. Select the account to delete.

  3. Click Delete.

    The account is deleted immediately.

You can delete an account even if content with that account still exists. The account value will remain assigned to the content item, but will be considered a user-defined account.

5.5.2.5 Assigning Accounts to a User with Oracle WebLogic Server

To assign an account to a user, use the Oracle WebLogic Server Administration Console to create a group and then assign it to one or more users. The group name must start with the @ sign and end with permissions delimited by an underscore. The following example creates a group named testaccount and assigns it Read, Write, and Delete permissions: @testaccount_RWD. You must also change the JpsUserProvider and ensure an underscore is in the Accounts Permissions Delimiter field. For more information, see Section 4.5.1.2.6, "When to Use JpsUserProvider."

Accounts assigned to a user on Oracle WebLogic Server are mapped to the Content Server instance. For more information, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

5.5.3 An Content Server Accounts Case Study

In this example, Xalco is a worldwide software company with offices in London, New York, and Paris. They have a Content Server system hosted in the London office, with access from the other offices through the corporate WAN. At the same time, Xalco is replicating some files out to an area of their public web site. Initially, the Sales and Finance departments at each location want to use their instance to publish files. The New York office is small and has no Sales department.

The following sections provide sample information for the Xalco case study:

5.5.3.1 Xalco Security

  • Xalco staff and security levels:

    • London: David Smith, Worldwide CFO, and Jim McGuire, UK Sales Manager

    • New York: Catherine Godfrey, Regional Finance Manager

    • Paris: Helene Chirac, Finance Clerk (Europe)

  • Xalco levels of security clearance (security groups) for Xalco content:

    • Public: Files suitable for consumption by members of the public (public content is replicated to the Xalco web site)

    • Internal: Files which have unrestricted access internally, but are not suitable for public consumption

    • Sensitive: Files which are commercially sensitive, and restricted to middle managers and above

    • Classified: Highly-sensitive files, suitable only for board members

  • Xalco staff access:

    • David Smith: As Worldwide CFO, he requires full access to all files held in the instance.

    • Jim McGuire: As UK Sales Manager, he must have full control of Sales files in London, and have visibility of sales activities in Paris. As a manager, he has clearance to the Sensitive level.

    • Helene Chirac: Based in the Paris office, she must view only files relating to Finance in Europe, and she has clearance only to the Internal level.

    • Catherine Godfrey: As a Regional Finance Manager based in New York, she must contribute Finance files for New York and view all other Finance documents. As a manager, she has clearance to Sensitive level.

5.5.3.2 Xalco Accounts

Access varies by location and job function, so this is reflected in the account structure:

  • London has Finance and Sales departments, so it needs two accounts:

    • London/Finance

    • London/Sales

  • New York has only a Finance department:

    • NewYork/Finance

  • Paris has both Finance and Sales departments:

    • Paris/Finance

    • Paris/Sales

This results in three top-level accounts (London, NewYork, Paris) and five lower-level accounts.

5.5.3.3 Xalco Roles

Two roles must be created for each security group (one for Consumers and one for Contributors)

  • PublicConsumer

  • PublicContributor

  • InternalConsumer

  • InternalContributor

  • SensitiveConsumer

  • SensitiveContributor

  • ClassifiedConsumer

  • ClassifiedContributor

5.5.3.4 Roles and Permissions Table

To give specific users the ability to start workflows, you would need to add Admin permission and Workflow rights to the Contributor role.

Role Public Internal Sensitive Classified

PublicConsumer

R

 

 

 

PublicContributor

RWD

 

 

 

InternalConsumer

 

R

 

 

InternalContributor

 

RWD

 

 

SensitiveConsumer

 

 

R

 

SensitiveContributor

 

 

RWD

 

ClassifiedConsumer

 

 

 

R

ClassifiedContributor

 

 

 

RWD


5.5.3.5 Roles and Users Table

Role David Smith Helene Chirac Jim McGuire Catherine Godfrey

PublicConsumer

 

X

 

 

PublicContributor

X

 

X

X

InternalConsumer

 

X

 

 

InternalContributor

X

 

X

X

SensitiveConsumer

 

 

 

 

SensitiveContributor

X

 

X

X

ClassifiedConsumer

 

 

 

 

ClassifiedContributor

X

 

X

X


5.5.3.6 Accounts and Users Table

It would be sufficient to give David Smith RWDA permission on London, New York, and Paris accounts.

Account David Smith Helene Chirac Jim McGuire Catherine Godfrey

London/Finance

RWDA

R

 

R

London/Sales

RWDA

 

RWDA

 

NewYork/Finance

RWDA

 

 

RW

Paris/Finance

RWDA

 

 

R

Paris/Sales

RWDA

 

R

 


5.6 Access Control List Security

In addition to the standard Content Server security roles, security groups, and accounts, the Content Server system can be configured to support access control lists (ACLs). An access control list is a list of users, groups, or Enterprise roles with permission to access or interact with a content item.

When access control list security is configured, three new fields are available for use in several locations in the interface, including checking in content items, updating content items, and searching for content items. The fields are:

  • User Access List

  • Group Access List

  • Role Access List

After the access control list security feature is configured for the Content Server system, you can use Oracle Platform Security Services (OPSS) to manage the access control lists, including the Oracle Access Manager (OAM) Authentication provider, which works with the Oracle WebLogic Server domain. For information, see Oracle Fusion Middleware Application Security Guide and Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Content Server access control lists are supported in Oracle Secure Enterprise Search, and users can perform searches using access control list information. For more information, see Section 7.2, "Oracle Secure Enterprise Search."

Note:

When using the RoleEntityACL component with Oracle WebCenter Content: Records, the component does not affect any retention objects such as categories or records folders. Therefore, the ability to use ACLs on a Records role is not enabled on the category creation page or folder creation page even if the RoleEntityACL component is enabled. The role ACL functionality is, however, enabled on the content checkin page.

Caution:

The Need to Know (NtkDocDisclosure, or NTK) component supports customization for Content Server security; however, it may not work together with access control lists because of conflicting security models.

For more information, see Appendix B, "Need to Know Component."

5.6.1 Configuring Access Control List Security

To set up access control lists (ACLs), configure the following items on the Content Server system:

  • To support user and group access control lists, the following configuration variables must be set in the Content Server config.cfg file:

    • UseEntitySecurity: Set this variable to true.

    • SpecialAuthGroups: Set this variable to the name of the Oracle WebCenter Content Server security group that will use the ACL security. Out-of-the-box Content Server has only two security groups: Public and Secure. Usually a site will create a third security group for which ACL security is to be applied.

    Enter the variables in the Additional Configuration Variables field of the General Configuration screen, which you can access from the Admin Server screen for your Content Server instance. For details, see Section A.1.2.1.2, "Admin Server: General Configuration Page."

    The configuration variable UseEntitySecurity=true sets Content Server security to always evaluate the user and group access control lists for content items. This parameter creates two metadata fields: xClbraUserList and xClbraAliasList.

  • To support the enterprise role access control list, the RoleEntityACL component must be enabled in the Content Server system.

    This component is installed (disabled) by default with the Content Server system. Use the Content Server advanced component manager to enable the component. For details, see Section A.3.6, "Advanced Component Manager Page."

    The RoleEntityACL component configures the Content Server system to work with other applications to evaluate the enterprise role access control list. This component turns on the UseRoleSecurity parameter, which sets Content Server security to integrate enterprise role access list information for content items. The UseRoleSecurity parameter creates the xClbraRoleList metadata field.

  • If you want non-administrator users to be able to use the Add User menu to select users for the User Access List when checking in content items, set the configuration variable AllowQuerySafeUserColumns=true. If this variable is not set, no values are displayed in the menu for the User Access List field.

5.6.2 Metadata Fields

Access control lists are computed based on the values in three metadata fields: xClbraUserList, xClbraAliasList, and xClbraRoleList. When the metadata values are populated with user, group, or enterprise role names and permissions to a content item, they affect which users, groups, and enterprise roles are allowed to search or act on the content item.

These metadata fields are populated from the User Access List, Group Access List, and Role Access List fields, which can be viewed or accessed when checking in a content item, updating a content item, and performing a search using the expanded form.

Administrators can use scripts to specify values to populate the metadata fields for the access lists.

5.6.2.1 xClbraUserList Metadata Field

The xClbraUserList metadata field is used to specify users and their permissions for a content item.

The following list describes requirements for administrators to specify xClbraUserList values in scripts:

  • Each user name is preceded by an ampersand (&) symbol.

  • Each user's permissions follow the user name in parentheses.

  • User names are separated by commas.

  • Example: xClbraUserList=&sysadmin(RWDA),&user1(RW),&guest(R)

5.6.2.2 xClbraAliasList Metadata Field

The xClbraAliasList metadata field is used to specify groups and their permissions for a content item.

Note:

In the Content Server system, an alias could be used to specify a group of users (which is not the same as a LDAP group). For ACLs, instead of calling the implementation an alias access list, it is called a group access list. However, the metadata field name still uses the term alias.

The following list describes requirements for administrators to specify xClbraAliasList values in scripts:

  • Each group name is preceded by an "at" (@) symbol.

  • Each group's permissions follow the group name in parentheses.

  • Group names are separated by commas.

  • Example: xClbraAliasList=@Mktg(RWDA),@Mktg_ext(RW)

5.6.2.3 xClbraRoleList Metadata Field

The xClbraRoleList metadata field is used to specify enterprise roles and their permissions for a content item.

The following describes requirements for administrators to specify xClbraRoleList values in scripts:

  • Each role name is preceded by a colon (:) symbol.

  • Each role's permissions follow the role name in parentheses.

  • Role names are separated by commas.

  • Example: xClbraRoleList=:role1(RWDA),:role2(RW)

5.6.3 Access Control List Permissions

Access control list permissions determine what type of access a user, group, or enterprise role has to a content item. The following permissions can be granted:

Permission Description

Read (R)

Allowed to view the content item.

Write (W)

Allowed to view, check in, check out, update, and get a copy of the content item.

Delete (D)

Allowed to view, check in, check out, update, get a copy, and delete the content item.

Admin (A)

Allowed to view, check in, check out, update, get a copy, and delete the content item, and check in a content item with another user specified as the Author.


Note:

Access control list permissions do not apply to users with the Content Server admin role.

To associate access control lists with a content item, you add one or more users, groups, or enterprise roles when checking in or updating a content item. For each user, group, or role you add to an access list, you assign the appropriate permission: Read (R), Write (W), Delete (D), or Admin (A). Access control list permission levels are the same as defined for Content Server security groups and accounts. When users are added to any one of the access lists, the users have the specified permissions to access the content item.

At least one of the following must be true for a user to be granted a particular permission:

  • The user's name appears in the xClbraUserList metadata field with the appropriate permission.

  • The user belongs to a group that appears in the xClbraAliasList metadata field with the appropriate permission.

  • The user is part of an Enterprise role that appears in the xClbraRoleList metadata field with the appropriate permission.

Access control list permissions are cumulative. If you assign Write, you automatically assign Read. If you assign Admin, you automatically assign Read, Write, and Delete. However, users must also satisfy security criteria for access through the Content Server security group and the account (if Accounts are enabled). If any of these security criteria deny a certain permission, users will not have that permission to the content item.

5.6.3.1 Empty Access Control List Fields

If all the User Access List, Group Access List, and Role Access List fields are empty, then by default permission is granted to all users. If only the User Access List and Group Access List fields are blank (and the RoleEntityACL component is not enabled so there is no Role Access List), permission is granted to all users. This behavior is configured with the AccessListPrivilegesGrantedWhenEmpty variable, which is set to true by default.

If the AccessListPrivilegesGrantedWhenEmpty variable is set to false, then when all access control lists are blank, permission is denied to all users except those with the admin role. For a user without the admin role to be able to checkin documents, the user must have an access control list role (such as testrole) with Read/Write (RW) privileges and specify the role when checking in documents.

Note:

If the Content Server instance has been upgraded from release 10g, be aware that empty access control lists will behave differently in Release 11g. Release 10g and earlier had the equivalent configuration of AccessListPrivilegesGrantedWhenEmpty=false. The default for release 11g is AccessListPrivilegesGrantedWhenEmpty=true.

5.7 Content Server User Information Provider

The JpsUserProvider provider is the default provider for the Content Server instance to communicate user information and credentials managed through the Oracle WebLogic Server Administration Console. For WebCenter Content and the Content Server instance, it is recommended that you use JpsUserProvider. For details, see Section 4.5.1.2.6, "When to Use JpsUserProvider."

If a site is upgrading from an earlier release of Content Server software and is using Active Directory, LDAP, or Active Directory with LDAP, information about those providers is available in the Release 10gR3 document Managing Security and User Access. It is strongly recommended that sites upgrade to use JpsUserProvider.

5.8 Additional Content Server Security Connections

This section provides information about additional security communication connection options for the Content Server system. It covers the following:

5.8.1 About Proxy Connections

Proxy connections, or connections between Content Server instances, provide additional levels of security for a Content Server system through the following functions:

  • Security credentials mapping from one Content Server instance to another Content Server instance.

  • Secured "named" password connections to Content Server instances (password protected provider connections).

  • HTTP protocol communication between Content Server instances.

While it is possible to use both named password connections and HTTP-based Content Server communication, it is most likely that one type of connection will be more useful. For both types of connections, credentials mapping can provide additional security.

Note:

A site can have multiple Content Server instances, but each Content Server instance must be installed on its own Oracle WebLogic Server domain.

The Proxy Connections component is installed (enabled) by default with Content Server software. Typical uses of the Proxy Connections component include the following:

  • To provide the capability to perform archive replication of content items over HTTP or HTTPS. For example, a company has acquired another company, but they do not a have common infrastructure for sharing information. Both companies have a secure sockets layer (SSL) connection to the Internet. The company wants to share content between the two sites. Proxy Connections can be used to set up a secure Internet connection between the companies' servers so that content can be securely accessed from one site, replicated, and archived at the other site.

  • To better restrict access to Content Server instances by using named passwords to target proxy connections. For example, a company wants to apply additional security to connections coming from one Content Server instance to another Content Server instance. Using named passwords, an administrator can restrict access by incoming connections to those with preset proxy connections and named passwords.

5.8.2 Credential Mapping

A credential map is a mapping of credentials used by a Content Server instance to credentials used in a remote system, which tell the Content Server instance how to connect to a given resource in that system. Administrators can create multiple credential maps for users, roles, and accounts. Credential mapping can be useful in a proxy scenario, for example, where credentials for users, roles, or accounts created on one Content Server instance can be mapped to the users, roles, or accounts on another Content Server instance, thus allowing users controlled access to information on more than one Content Server instance.

This section covers the following topics:

5.8.2.1 About Credential Mapping

When you create a credential map you enter a unique identifier for the map and specific credential values for users, roles, and accounts. In a proxy connection, when user credentials match an input value, then the user is granted the credentials specified in the output value. The user credentials are evaluated in the following order:

  1. All the roles.

  2. All the accounts.

  3. The user name.

After the translation is performed, the user only has the attribute values that were successfully mapped from input values.

When you have created credential maps, you can specify a credential map along with a named password connection when configuring an outgoing provider. You also can specify a credential map when configuring a user provider (such as LDAP).

The default behavior for a LDAP provider is that the guest role is not automatically assigned to users.

Credential mapping implementation is duplicated in the Web server plug-in and in WebCenter Content. It is designed and implemented for optimal performance, so that any changes in the mapping are applied immediately. (This can be compared to performance in NT or ADSI user storage using the NT administrator interfaces, where changes are cached and not reflected in the Content Server instance for up to a couple of minutes.)

Note:

For information on credential mapping outside of a Content Server instance, see "Credential Mapping Providers" in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.

5.8.2.2 Credential Values

A credential input value is matched if there is an exact match in the case of a role or user name. An input account value is matched if one of the user accounts has a prefix, except for the case of a filter (see Section 5.8.2.3, "Matching Accounts and Roles"). For example, the following credential values reduce all users who might otherwise have the admin role to instead have the guest role:

admin, guest

The following table lists the basic syntax for credential values:

Value Prefix or Sequence Example

User name

&

&name

Role

 
admin

Account

@

@marketing

Empty account

@#none

@#none

All accounts

@#all

@#all

Ignore the value or "comment out" the value

#

#comment

You can view which credentials are applied by default if no credential map is assigned. Use the following mapping, which maps everything without change. This mapping first filters all roles, then all accounts.

|#all|,%%
@|#all|,@%%

For more information about mapping syntax see Section 5.8.2.3, "Matching Accounts and Roles."

Caution:

If your credential map does not at least assign the minimum set of privileges that an anonymous user gets when visiting the Content Server web site, then logged in users may experience unusual behavior. For example, a common reaction for a browser that receives an ACCESS DENIED response is to revert back to being an anonymous user. In particular, a user may experience unpredictable moments when it is possible or not possible to access a document (depending on whether at that moment the browser chooses to send or not to send the user's authentication credentials). This is particularly true of NTLM authentication because that authentication has to be renewed periodically.

5.8.2.3 Matching Accounts and Roles

A special filter is available for matching accounts and roles. For example, the syntax for an account filter is designated by starting the account value with specifying the prefix @| and ending with a | (for example, @|accountname|). The pipe (|) represents a command redirection operator that processes values through the filter. For proxied connections a space-separated list of accounts is specified; each account optionally starts with a dash (-) to denote a negative value. A filter is matched if any of the specified account strings that do not start with a dash are a prefix for a user account and all of the account strings that do start with a dash are not prefixes for that user account.

Caution:

The filter will not map the account @#all. The all accounts account value must be mapped explicitly by using @#all, @#all mapping.

Roles can be mapped (using the same rules) by removing the @ sign from the beginning of the filter. For example, the following input value passes through all roles except those that begin with the prefix visitor. Note that the expression #all matches all roles.

|#all -visitor|, %%
5.8.2.3.1 Reference Input Value

The special sequence %% in the output value can be used to reference the input value. For example, given the following mapping, any account that did not start with financial as a prefix would map to the same account but with the prefix employee/ attached at the front:

@|#all -financial|, @employee/%%

If a user had the account marketing, then after the mapping the user would have the account employee/marketing.

5.8.2.3.2 Privilege Levels

A particular privilege level (read, write, delete, all) can be granted to an account in the output value by following the account specification with the letters "R", "W", "D", or "A" enclosed in parentheses. For example, all the privilege levels for all the accounts could be reduced to having read privilege by the following syntax:

@|#all -financial|, @employee/%%(R)
5.8.2.3.3 Substitution

In certain cases it is useful to remove a prefix before the substitution %% is applied. An offset for the substitution can be specified by using the syntax %%[n] where n is the starting offset to use before mapping the input value into the %% expression. The offset is zero based so that %%[1] removes the first character from the input value. For example, to remove the prefix DOMAIN1\ from all roles, the following expression can be used:

|domain1\|, %%[8]

Another use for this function might be to replace all accounts that begin with the prefix marketing/ and replace it with the prefix org1/mkt. The expression for this would look like the following:

@|marketing/|, @org1/mkt/%%[10]
5.8.2.3.4 Special Characters

In certain cases roles have unusual characters that may be hard to specify in the input values. The escape sequence %xx (where xx is the ASCII hexadecimal value) can be used to specify characters in the input value. For example, to pass through all roles that begin with #,& |@ (hash, comma, ampersand, space, pipe, at) the following expression can be used:

|%35%2c%26%20%7c%40|, %%

5.8.2.4 Proxy Credentials Map

A proxied credentials map is applied after initial credentials are assigned to the user. This mapping example takes an account value assigned to the user (not to a LDAP group) and grants them the same account value:

@|Public|,         @Public

If you do not apply a suffix such as (R), then whatever privileges the account had before the mapping, it will have after the mapping. If you want to degrade the privileges from the defaults assigned by the LDAP map, try this construction:

@|Public|,         @%%(R)

The %% refers to the input account value that was matched by the prefix: Public. For example, if the user has the account Public/mysuffix, then %% would have the value Public/mysuffix when it is picked up by the |Public| prefix filter.

5.8.2.5 Creating a Credential Map

To create a credential map, follow these steps:

  1. Open a new browser window and log in to the Content Server instance as the system administrator.

  2. Select Administration then Credential Maps.

    The Credential Maps Screen is displayed.

  3. Enter the unique identifier for the credentials map you are creating.

    More than one named password connection can be used to connect to a Content Server instance. Each named password connection can have a different credential map.

  4. Enter values in two columns with a comma to separate the columns and a carriage return between each row of values. The first column specifies input values and the second column specifies output values.

  5. Click Update.

To apply a credential map to roles and accounts retrieved using NT integration, set the Content Server configuration entry ExternalCredentialsMap to the name of the credential map of your choice.

5.8.3 Secured Connections to Content Servers

Secured connections to Content Server instances can be supported by creating password protection on incoming requests. A Content Server instance can communicate with another Content Server instance in a password protected fashion.

This section covers the following topics:

5.8.3.1 About Named Password Connections

Using the Proxied Connection Authentication/Authorization Information Screen you can create named passwords, which are passwords that you assign to specific connections by name. Each named password can be associated with a host and IP address filter on both the direct socket communication to a Content Server instance and on any communication performed through the controlling web server (the HTTP filter) for a Content Server instance. When an outside agent (such as a web server for another Content Server instance) wants to communicate with the Content Server instance, it can use a named password connection. A named password connection also can be associated with a credentials map so that the privileges of users accessing the Content Server instance can be reduced or changed.

Proxy connections entry fields are provided in the forms for configuring outgoing socket providers and outgoing HTTP providers in which you can specify a named password connection. (To view provider selections for your instance, choose Administration then Providers.)

Passwords are hashed (SHA1 message digest) with their allowed host and IP address wildcard filter on the client side. If the copy of a stored password is exposed, it will only allow access from clients that satisfy both the host and IP address filter.

The expiration implementation for passwords means that the various servers involved must have their clocks reasonably synchronized (within a few minutes at least).

Caution:

All passwords are hashed by a time-out value before being sent to a server. If a password value is exposed while in communication to a server, the password will only be usable until the expiration time (approximately fifteen minutes after the time the request is issued). Also, the password will only be usable in a replay attack from the same source host and IP address, as previously described. If firewall-protected internal host and IP addresses are not being used, a very committed attacker could spoof the host and IP addresses by hijacking any of the major DNS servers, an event that has occurred in at least a couple of cases.

5.8.3.2 Guidelines for Proxy Connections Data

The data you enter in the Proxied Connection Authentication/Authorization Information Screen defines different passwords that can be used by external agents to connect to a Content Server instance. Instead of an external agent being forced to provide a password for each user, which may be unavailable to the client for many reasons (such as message digest algorithms that do not use clear text passwords), proxy connections enable the agent to authenticate using a single named connection password. Each named password connection can be linked to rules to restrict which hosts can connect to the Content Server instance and to control the privileges granted to users. Each named password connection is uniquely identified, and the calling agent must supply the identifier along with the password.

The host name and IP address filters are used to determine which host names or IP addresses are allowed to use a named password connection when performing direct socket connections to a Content Server instance. The rules for defining the filters are identical to those defined in the System Properties editor (the wildcard symbols * = match 0 or many and | = match either or can be used to create flexible rules). If an entry is empty then it provides no restriction on its target attribute (either the host name or IP address of the client depending on which of the following two fields is involved).

Two options are implemented through the Providers page:

  • Whenever you add an outgoing provider you have the option to use named password connections and to choose whether the provider is a connecting server (so that Web access and security is controlled through a remote server).

  • Whenever you add a user provider (such as LDAP) you can choose to use an available credentials map.

No credentials maps are defined in the Proxied Connection Authentication/Authorization Information Screen. For information on creating a credentials map, see Section 5.8.2, "Credential Mapping."

5.8.3.3 Creating a Proxied Connection

To create a proxied connection, follow these steps:

  1. Open a new web browser window and log in to the Content Server instance as the system administrator.

  2. Choose Administration.

  3. Choose Connection Passwords.

    The Proxied Connection Authentication/Authorization Information Screen is displayed.

  4. Enter information for the fields in the Proxied Connections page.

    If credentials maps exist, you can choose to use an existing credentials map, or you can create one to be used for the proxied connection.

  5. Click Update.

5.8.4 Connections Using the HTTP Protocol

Administrators can create a proxy connection between Content Server instances using the HTTP protocol. For example, you could have two Content Server instances where both have web servers for accessing their functionality. If you have a large number of users who want to use Web browsers to access information on one of the Content Server instances, but not all the users can access that server directly, this feature can be useful.

The HTTP protocol can be useful for transferring Content Server archives. The HTTP provider works with Secure Sockets Layer (SSL), the HTTPS protocol, which enables secure communication between two Content Server instances.

This section covers the following topic:

5.8.4.1 About Using HTTP Protocol for Content Server Connection

Administrators can implement a httpoutgoing provider, configurable through the Providers page, which allows communication from one Content Server instance to another Content Server instance.

If you choose to add a httpoutgoing HTTP provider, you have the following additional options:

  • Specify a CGI URL.

  • Specify a named password connection and client IP filter.

To view the httpoutgoing HTTP provider selection, choose Administration then Providers from the WebCenter Content navigation panel.

Creating a proxy connection between Content Server instances can take some preparation. The Content Server instances must not use the same relative web root for their weblayout directories. It may require some component architecture changes to provide the extra navigation links between the servers.

If you set up one Content Server instance with its web server using SSL and the other server's front end uses HTTP, then users who try to access the first server by modifying the other server's URL in a Web browser can get an error because of the differences between HTTPS (requiring a credential) and HTTP. To resolve this issue, use the BrowserUrlPath component, available with the Content Server system. For more information, see Section 5.9.2, "Browser URL Customization."

5.8.4.2 Configuring the HTTP Provider

To configure the HTTP provider, complete the following steps.

  1. Add a httpoutgoing provider on the first Content Server instance.

    1. In a browser, go to the Administration page and click Providers.

    2. Click Add next to the httpoutgoing provider type.

    3. Enter the necessary information for the httpoutgoing provider. For more information see the table for the Outgoing Http Provider Page:

  2. Create a proxy connection on the second Content Server instance that uses the named password connection and connection password that you specified in the previous step.

    1. On this server, choose Administration then Connection Passwords.

    2. Fill in the information for the connection. The IP address filter entry should have the IP address of the first server.

5.9 Content Server Communication Customization

The following sections provide information on how to customize access to and communication with Content Server instances. It includes the following:

5.9.1 Login/Logout Customization

The Extranet Look component can be used to customize user access by suppressing the interface for users who are not authenticated by an Oracle WebLogic Server user store through error and challenge pages issued by the web server. For details about changing the interface, see Oracle WebCenter Content Developer's Guide for Content Server.

The Extranet Look component is installed (disabled) by default with the Content Server system. To use the component you must enable it with the Advanced Component Manager.

5.9.2 Browser URL Customization

The BrowserUrlPath component provides support for determining URL paths used in certain configurations of the Content Server system and web servers. This component is installed (disabled) by default with the Content Server system. To use this component you must enable it with the Advanced Component Manager.

This component is valid for a Content Server instance deployed on an Oracle WebLogic Server domain and located behind a load balancer.

The following topics are discussed in this section:

5.9.2.1 About BrowserUrlPath Customization

The BrowserUrlPath component overrides certain Idoc Script variables and functions, adds computation to certain variables, and provides additional configuration entries for determining URL paths. The BrowserUrlPath component is only supported with Trays and Top Menu layouts for the Content Server user interface.

  • You can configure a system with different web server front ends. One front end can use HTTP and the other can use HTTPS so that the Content Server instance can be accessed simultaneously by web sites using HTTP and HTTPS. You then must apply the BrowserUrlPath component to enable the Content Server instance to handle both types of access.

  • If you are using a load balancer that forwards itself as the HTTP host header, then you must apply the BrowserUrlPath component.

BrowserUrlPath configuration variables are located in the WL_WEBCENTER_CONTENT_HOME/ucm/idc/components/ BrowserUrlPath/config.cfg file.

Caution:

The BrowserUrlPath component requires extensive configuration using the variables. You may want to back up your configuration before modifying variables

In typical scenarios, the web server will forward to the Content Server instance two critical pieces of information:

  • HTTP_HOST: The host header that the browser sends, identifying the host as it appears to the user in their browser address bar.

  • SERVER_PORT: The port the browser uses in connecting to the Content Server instance.

The browser-based full address is used for two critical pieces of functionality:

  1. Automatic creation of URLs in the side frame of the Trays layout for the Content Server instance. In particular, the side mini-search requires a prediction of the full URL, not just the relative URL.

  2. The secondary URL (the #xml-http... piece following the PDF URL) that does highlighting for PDF documents.

Without any additional configuration, the BrowserUrlPath component augments the functionality of certain variables, so if SERVER_PORT has the value 433, then the component assumes the protocol is HTTPS instead of HTTP. Likewise, if SERVER_PORT does not have the value 433, then the component assumes the browser issued the request using HTTP and not HTTPS. This enhancement allows both a SSL (HTTPS) and non-SSL web server (HTTP) to access the same Content Server instance.

This component also has special functionality for WebDAV access. The configuration entry WebDavBaseUrl is augmented so that its usage is dynamic (its host and protocol vary using the "absolute" path rules).

Caution:

The functionality for WebDAV access alters the behavior of CHECKOUT and OPEN functions on some Content Server pages, and alters some behavior in the Site Studio client.

5.9.2.2 Affected Idoc Script Variables and Functions

The BrowserUrlPath component overrides the computation of the following Idoc Script variables and functions:

  • HttpBrowserFullCgiPath

  • HttpWebRoot

  • HttpCgiPath

  • HttpAdminCgiPath

  • HttpImagesRoot

The BrowserUrlPath component adds computation for the following variables:

  • HttpBrowserFullWebRoot: Defines the full URL path to the web root of the current Content Server instance using values supplied from the user's current browser's address bar. This variable is similar to HttpBrowserFullCgiPath except it is for the web root instead.

  • HttpAbsoluteWebRoot: Defines the universal full URL path to the web root of the current Content Server instance. It can have a different protocol or host name than the path in HttpBrowerFullWebRoot. For example, if the user specifies an IP address for the host name, the HttpBrowserFullWebRoot variable might pick up the IP address, but the HttpAbsoluteWebRoot variable would ignore it and use the appropriate internally configured host name.

  • HttpAbsoluteCgiPath: Defines the universal full dynamic root URL for the current Content Server instance. This is the path that executes the plug-in code in the web server that makes calls for dynamic content from the Content Server instance. It can have a different protocol or host name than the path in HttpBrowserFullCgiPath. For example, if the user specifies an IP address for the host name, the HttpBrowserFullCgiPath variable might pick up the IP address, but the HttpAbsoluteCgiPath variable would ignore it and use the appropriately internally configured host name.

In the case of the browser path variables HttpBrowserFullCgiPath and HttpBrowserFullWebRoot, the implementation code determines what the user is currently using for protocol (HTTP versus HTTPS), port number, and host name in the browser. It bases this determination on what the web server receives in its request.

5.9.2.3 Determining the URL Path

The BrowserUrlPath component supports the following configuration entries for guessing the URL path as the browser determines it:

  • HttpIgnoreWebServerInternalPortNumber: When set to true, this disables the use of the SERVER_PORT parameter. This entry is useful in a load balancing scenario where SERVER_PORT is not the port used by the browser, but is the port used by the load balancer to communicate with the web server. Enabling this entry will make it impossible (without the BrowserUrlPath component) for the Content Server instance to determine which port the browser used to access the web server. Without additional BrowserUrlPath configuration, this variable makes it impossible to both support a SSL and non-SSL address to the same Content Server instance. Using this variable prevents a load balancing configuration problem in which the load balancing server is using a different port number than the internal web server actually delivering the response to the request.

  • HttpIgnoreServerNameForHostName: When set to true, this disables the fallback logic where if the HTTP_HOST parameter is missing, the Content Server system will typically look for the parameter SERVER_NAME (the web server's self identification).

  • HttpBrowserSSLPort: Only use this configuration entry if the SERVER_PORT entry is forwarded to the web server that communicates to the Content Server instance. This entry is used to decide whether a request is HTTPS or HTTP by comparing it with the SERVER_PORT parameter. The default SERVER_PORT value is 443. If you use HTTPS, but use a port other than 443, you must use this entry to set the expected HTTPS port number.

  • HttpBrowserUseIsSslCookie: If you want to look in the cookie to see if it indicates whether to use SSL or not, set this entry to true.

  • HttpBrowserIsSslCookieName: Only use this entry if the HttpBrowserUseIsSslCookie entry is enabled. Set the entry to the name of the cookie used to determine whether the server believes the browser is using SSL or not. The default is the cookie name UseSSL. The value of the cookie can be 1 or 0 (zero). If a cookie with this name is present, then it will supersede other rules for determining whether to use SSL.

  • HttpBrowserUseHostAddressCookie: When set to true, this specifies to use a cookie to determine the full host name of the browser (the part between the protocol and the relative Web address).

  • HttpBrowserHostAddressCookieName: This entry is enabled only if HttpBrowserUseHostAddressCookie is enabled. Use this entry to specify the name of the cookie used to determine what the server believes is the browser's current host name. The host name part of the protocol can include the port number. For example, HttpbrowserHostAddressCookieName=myhost:81 would specify the host myhost using the webport 81. If you do use this cookie, then it is unlikely that you need to enable HttpBrowserUseIsSslCookie, because if you use myhost:433, that will translate to https://myhost/%rest-of-url%.

5.9.2.4 Changing Absolute Full Path Computation

The BrowserUrlPath component supports the following configuration entries for changing how the absolute full path is computed. This is useful for e-mail, where it is better to use a specific host name and protocol, even if the browser shows a different URL. This path is considered the absolute or universal path.

  • HttpBrowserAbsoluteUrlHasRelativeSSL: When set to true, this variable allows a URL computed on the Content Info page to change from HTTP to HTTPS (or the other way if UseSSL is enabled in the config.cfg file), depending on what the Content Server system determines as the current use in the user's browser. The change between HTTP and HTTPS also changes the computation of the URL for creating the e-mail body for the "email to" links. This configuration has no effect on automatically generated e-mail.

  • HttpBrowserAlternateWebAddress: Specifies an alternate absolute host web address (host name plus optional port number). For example, HttpBrowserAlternateWebAddresss=host_name:447. This web address is used for the absolute path computation if the current SSL choice is different from the default for the Content Server instance. This configuration has no effect on automatically generated e-mail.

  • HttpBrowserAbsoluteUrlUsesBrowserPath: When set to true, if browser path information can be computed, then the absolute path will use the browser path. This essentially turns off the absolute path except for background activities (such as sending notification e-mail).

5.9.2.5 Changing Administration Path Computation

The BrowserUrlPath component supports the following configuration entries for changing how paths are computed for the Administration tray or top menu links. For example, the variable HttpAdminCgiPath, which retrieves the Admin Server CGI as a relative URL to the Admin Server, computes an administration path.

  • HttpBrowserAdminUsesAbsolutePath: When set to true, instead of using the browser-based path (which is the default with the BrowserUrlPath component), the absolute path is used as the basis for computing administration paths, except for the protocol that is dictated by the configuration variable HttpBrowserUseAdminSSL.

  • HttpBrowserUseAdminSSL: This configuration entry is only relevant if the HttpBrowserAdminUsesAbsolutePath variable is set. When set to true, this variable dictates the protocol in the administration paths (HTTP or HTTPS) even if HttpBrowserAbsoluteUrlHasRelativeSSL is set. The default value of HttpBrowserUseAdminSSL is the opposite of UseSSL. This allows the administration path to be nonstandard from the default URL constructions for all other paths. The variable HttpBrowserAlternateWebAddress, if set, can be used to also give the administration path a different web address in the case that HttpBrowserUseAdminSSL is set to the opposite of UseSSL.

For further information on variables and enabling the BrowserUrlPath component, see Oracle WebCenter Content Idoc Script Reference Guide and Oracle WebCenter Content Installation Guide.

5.9.3 Extended User Attributes

The Extended User Attributes component enables administrators to add extended security attributes to Content Server users. The extended security attributes are merged into pre-existing user attributes and enable additional flexibility in managing users. For example, roles and accounts attributes can be added to external LDAP users without needing to perform internal setup. Also, roles and accounts attributes can be added to users for a customized application separately from base user attributes.

The Extended User Attributes component is installed (enabled) by default with the Content Server system. Services installed for the Extended User Attributes component are described in the Oracle WebCenter Content Services Reference Guide.

This section covers the following Extended User Attributes topics:

In addition to these resources, there are added queries which can be used to gather data for extended user attributes. The queries can be viewed in the Component Wizard or by looking in the WC_CONTENT_ORACLE_HOME/ucm/idc/components/ExtendedUserAttributes/resources/extendeduserattributes_query.htm file.

5.9.3.1 ExtUserAttribInfo ResultSet

ExtUserAttribInfo is the ResultSet used by the Content Server system to handle extended user attributes. It is similar to the UserAttribInfo ResultSet used for handling regular user attributes, with some additional information.

This ResultSet has three columns. You can supply one attribute per row or multiple attributes on a single row (per application). The following columns are included:

  • dUserName: The user whose attributes are being described.

  • dApplication: The application to which those attributes are linked.

  • AttributeInfo: The attribute information. This is a comma-separated entry consisting of three items:

    • attribute type: usually either a role or account, depending on if a security group or account is being defined for the user

    • attribute name: the title of the role or account

    • attribute privilege: a definition of rights given to the user. Rights are defined according to UNIX conventions:

      • 1: read permission

      • 2: write permission

      • 4: delete permission

      • 8: admin

      For example, the entry role,contributor,3 gives the user permission to read and write in the contributor security group.

      Multiple AttributeInfo entries can be added in a single row, separated by commas. For example, this entry adds two attributes into the AttributeInfo row: role,guest,15,account,\#all,15.

The following is an example of this ResultSet:

@ResultSet ExtUserAttribInfo
3
dUserName
dApplication
AttributeInfo
jsmith
appl
role,contributor,15
jsmith
app2
account,abc,15,account,xyz,15
@end

5.9.3.2 Configuration Variable for ExtendedUserAttributes

The following configuration variable can be set in the Content Server system and is useful if you are working with default attributes:

  • DefaultAttributesCacheTimeoutInSeconds: Defines how long the default attribute cache remains active (default = 600).

5.9.4 Filter Data Input

The Content Server system can be customized to filter data input for illegal or corruptive HTML constructs by using the encodeHtml Idoc Script function and a filter hook to automatically scrub all input data for dangerous HTML constructions. The encodeHtml function can be applied to a specific string. The HtmlDataInputFilterLevel configuration variable can be used to apply a level of encoding to filter all data input to the Content Server system.

This section covers the following topics:

5.9.4.1 encodeHtml Function

The encodeHtml Idoc function can be used to filter data input for illegal or corrupted HTML constructs. The output is an encoded string. The encodeHtml function is applied by default to the discussions in the Threaded Discussions component.

The encodeHtml function is generally used at the exceptsafe or higher level of encoding because the HtmlDataInputFilterLevel configuration variable will already have been encoded as unsafe (assuming it uses the default configuration).

The encodeHtml function is defined as follows:

encodeHtml (string, rule, wordbreakrules)
  • string: The string to encode.

  • rule: The rule to apply when encoding HTML constructs. The following values are allowed:

    • none: No conversion is done to HTML constructs.

    • unsafe: Only well-known unsafe script tags are encoded. The list includes: script, applet, object, html, body, head, form, input, select, option, textarea.

    • exceptsafe: Only well-known safe script tags are not encoded. The list includes: font, span, strong, p, b, i, br, a, img, hr, center, link, blockquote, bq, fn, note, tab, code, credit, del, dfn, em, h1, h2, h3, h4, h5, blink, s, small, sub, sup, tt, u, ins, kbd, q, person, samp, var, ul, li, math, over, left, right, text, above, below, bar, dot, ddot, hat, tilde, vec, sqrt, root, of, array, row, item.

    • lfexceptsafe: (Recommended where extended comments are entered by a user and they want to preserve the line feed breaks of the original text.) Similar to exceptsafe, however, line feed (ASCII 10) characters are turned into HTML break tags (br). Line feeds inside of HTML tags are not turned into break tags. The following script tags that are safe with exceptsafe are not safe with lfexceptsafe: br, p, ul, li.

    Except for the rule none, all the rules have special HTML comment handling. In particular, all HTML comments are allowed through the filter. However, when inside a HTML comment, all less than (<) and greater than (>) symbols are encoded. This does not apply to the HTML closing signature (-->). Also, if there is an unterminated comment, the encoding function appends the HTML comment close signature (-->).

    Additionally, except for the rule none, any attribute value located inside a tag has any parenthesis encoded to %28 (for '(') or %29 (for ')'). Otherwise, if any character is escaped it is escaped using the XML (&xxxx;) type encoding.

    wordbreakrules: This is an optional parameter that specifies if long strings without space characters are to be broken up and what maximum word size to apply. Either the string wordbreak or nowordbreak can be specified. This parameter can be used with any of the encodeHtml rules. The default is to turn on wordbreak if the rule lfexceptsafe is specified, and to use a maxlinelength of 120 characters.

    The additional parameter maxlinelength=xxx can be used with the wordbreak parameter to specify a desired maximum line length. For example:

    encodeHtml ("exceptsafe", "<bad> text", "wordbreak, maxlinelength=80")
    

    The wordbreak functionality is only usable by the encodeHtml function because the function is used for display and not applied before the data is stored.

For information about Idoc Script see Oracle WebCenter Content Idoc Script Reference Guide.

5.9.4.2 HtmlDataInputFilterLevel Configuration Variable

The HtmlDataInputFilterLevel configuration variable can be used to apply a level of encoding to filter all input data to the Content Server system for bad HTML constructions. The HtmlDataInputEncodingRulesForSpecialFields table in the std_resources.htm file is used for special case encoding rules and may override this configuration entry for certain parameters.

Note that if you change the HtmlDataInputFilterLevel value, you must restart the Content Server instance.

Using the HtmlDataInputFilterLevel variable has no effect on the behavior of the Idoc Script encodeHtml function.

You can set the HtmlDataInputFilterLevel configuration variable to the following values:

  • none: (Not recommended.) All filtering is turned off.

  • unsafe: (Default. Recommended.) Protects against bad HTML constructions. Examples of bad constructions include: script, applet, object, html, body, head, form, input, select, option, textarea.

  • exceptsafe: (Not recommended.) Allows only well known safe constructions through the filter. If exceptsafe is chosen, then the unsafe option will be applied to requests using GET style requests. Doing a higher level of encoding on GET requests breaks Content Server operation because <$...$> and other tags are routinely passed in as part of the parameter data or URLs. The higher level of filtering is only applied to non-scriptable services (those services that are usually called with POST).

    Examples of well known safe constructions include: font, span, strong, p, b, i, br, a, img, hr, center, link, blockquote, bq, fn, note, tab, code, credit, del, dfn, em, h1, h2, h3, h4, h5, blink, s, small, sub, sup, tt, u, ins, kbd, q, person, samp, var, ul, li, math, over, left, right, text, above, below, bar, dot, ddot, hat, tilde, vec, sqrt, root, of, array, row, item.

See the encodeHtml Function rule description for information about HTML comment handling, which also applies to HtmlDataInputFilterLevel configuration values.

The value lfexceptsafe is not supported for the HtmlDataInputFilterLevel configuration variable. It is only supported with the encodeHtml function.