This chapter provides information on additional security connection options for use with Content Server.
This chapter covers the following topics:
Proxy connections, orconnections between Content Server instances, provide additional levels of security for Content Server 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 ProxyConnections component is installed (enabled) by default with Content Server. Typical uses of Proxy Connections 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.
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:
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:
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 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 Oracle 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.
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 22.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 22.2.3.
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 website, 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 proxy 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 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|, %%
A proxy 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.
To create a credential map:
Open a new browser window and log in to the Content Server instance as the system administrator.
Choose Administration, then Credential Maps.
In the Credential Maps page, 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.
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 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.
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:
Using the Proxied Connection Authentication/Authorization Information page 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.
The data you enter in the Proxied Connection Authentication/Authorization Information page 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 page. For information on creating a credentials map, see Section 22.2.
To create a proxy connection:
Open a new web browser window and log in to the Content Server instance as the system administrator.
Choose Administration, then Connection Passwords.
In the Proxied Connection Authentication/Authorization Information page, enter information for the fields. If credentials maps exist, you can choose to use an existing credentials map, or you can create one to be used for the proxy connection.
Click Update.
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 topics:
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, from the Content Server portal, choose Administration, then Providers.
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 Content Server. For more information, see Section 23.2.
To configure the HTTP provider:
Add a httpoutgoing provider on the first Content Server instance.
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 instance that uses the named password connection and connection password that you specified in the previous step.
On this server, choose 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.