This section provides information about additional security communication connection options for Content Server. It covers the following:
Proxy connections, or connections between content server instances, provide additional levels of security for Content Server through the following functions:
Security credentials mapping from one content server to another content server.
Secured "named" password connections to content servers (password protected provider connections).
HTTP protocol communication between content servers.
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.Typical uses of the ProxyConnections8 component include the following:
To provide the capability to perform archive replication of content items. 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. ProxyConnections 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 Servers by using named passwords to target proxy connections. For example, a company wants to apply additional security to connections coming from one Content Server to another Content Server. Using named passwords, an administrator can restrict access by incoming connections to those with preset proxy connections and named passwords.
The ProxyConnections8 component is installed (enabled) by default with Content Server.
Administrators can create multiple credentials maps for users, roles, and accounts. Credentials mapping can be useful in a master-to-master scenario, for example, where credentials for users, roles, or accounts created on a 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 Oracle Content Server.
This section covers the following topics:
When you create a credentials 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:
All the roles.
All the accounts.
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 credentials map along with a named password connection when configuring an outgoing provider. You also can specify a credentials map when configuring a user provider (such as LDAP).
The default behavior for an LDAP provider is that the guest role is not automatically assigned to users.
Credentials mapping implementation is duplicated in the Web server plug-in and in Content Server. 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 for up to a couple of minutes.)
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 "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. For additional information about mapping syntax see "Matching Accounts and Roles".
|#all|,%% @|#all|,@%%
Caution:
If your credentials 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.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|, %%
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.
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)
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]
In certain cases roles will 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|, %%
To create a credentials map, follow these steps:
Open a new browser window and log in to Content Server as the system administrator.
Select Administration and then select Credential Maps.
The Credential Maps Screen is displayed.
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. Each named password connection can have a different credentials map.
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.
Click Update.
To apply a credentials map to roles and accounts retrieved using NT integration, set the Content Server configuration entry ExternalCredentialsMap to the name of the credentials map of your choice.
Secured connections to Content Servers can be supported by creating password protection on incoming requests. A Content Server instance can communication with another Content Server instance in a password protected fashion.
This section covers the following topics:
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 and on any communication performed through the controlling Web server (the HTTP filter) for a Content Server. When an outside agent (such as a Web server for another Content Server) wants to communicate with the Content Server, 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 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, select Administration, 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.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. 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 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. 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 "Credentials Mapping".
To create a proxied connection, follow these steps:
Open a new Web browser window and log in to Content Server as the system administrator.
Click Administration.
Click Connection Passwords.
The Proxied Connection Authentication/Authorization Information Screen is displayed.
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.
Click Update.
Administrators can create a proxy connection between content servers using the HTTP protocol. For example, you could have two content servers 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 servers, 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 servers.
This section covers the following topic:
Administrators can implement an httpoutgoing provider, configurable through the Providers page, which allows communication from one content server to another content server.
If you choose to add an 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, select Administration and then Providers from the Content Server navigation panel.
Creating a proxy connection between content server instances can take some preparation. The content server instances should 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 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 Oracle Content Server. For more information, see "Browser URL Customization".
To configure the HTTP provider, complete the following steps.
Add an httpoutgoing provider on the first content server.
In a browser, go to the Administration page and click Providers.
Click Add next to the httpoutgoing provider type.
Enter the necessary information for the httpoutgoing provider. For more information see the table for the Outgoing Http Provider Page:
Create a proxy connection on the second content server that uses the named password connection and connection password that you specified in the previous step.
On this server, select Administration, then Connection Passwords.
Fill in the information for the connection. The IP address filter entry should have the IP address of the first server.