This chapter explains the security features for Oracle Communications Convergence.
When using the iwcadmin command, you cannot include the -W password_file parameter unless the password file is encrypted. For this reason, the -W parameter is omitted from all examples in this guide.
Use the iwcadmin command to encrypt a password file:
iwcadmin -o admin.adminpwd
If you exclude the -W password_file parameter from your commands, the iwcadmin command prompts you for the administrator password.
See Convergence System Administrator’s Guide for more information about the iwcadmin command.
Identify the http-listener for the publicly accessible port that has SSL/TLS enabled (security-enabled=true) on which requests for Convergence are received. Ensure that SSLv3 is disabled for this listener by setting the option ssl3-enabled to false.
Identify the HTTP listeners that have SSL/TLS enabled (security-enabled=true) and verify whether SSLv3 is enabled on that listener (ssl3-enabled=true).
asadmin get configs.config.server-config.network-config.protocols.protocol.* | grep http-listener.*security-enabled=true configs.config.server-config.network-config.protocols.protocol.http-listener-2.security-enabled=true asadmin get configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.ssl3-enabled configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.ssl3-enabled=true Command get executed successfully.
Disable SSL3 for those HTTP listeners.
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.ssl3-enabled=false configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.ssl3-enabled=false Command set executed successfully.
Restart the GlassFish server.
Administering encryption for secure authentication includes:
Configuring Convergence for SSL
See "Secure Sockets Layer (SSL)" for more information.
Setting up Certificate-based Authentication
See "About Certificate-Based Authentication" for more information.
Configuring Convergence for S/MIME
See Convergence System Administrator’s Guide for more information.
This section explains key concepts about certificate-based authentication and how to set it up.
To enable SSL and client authentication for a listener in a GlassFish server:
Log into the GlassFish Server Administration Console.
Click on Configurations, then on server-config, then on HTTP Service, then on HTTP Listener.
Select a listener where SSL is enabled.
The listener details appear.
Click the SSL tab.
Select the Client Authentication Enabled box.
Click Save.
Restart the GlassFish server.
Use the Java keytool for managing certificates. See your Oracle GlassFish Server documentation for more information.
There are two types of Certificate Revocation Lists, static and dynamic. The following methods of certificate revocation are supported:
Static Certificate Revocation List (CRL) checking
Dynamic Certificate Revocation List (CRL) checking
Revocation Checking using OCSP (Online Certificate Status Protocol)
See the Oracle GlassFish Server documentation for information about revocation checking.
A certificate mapper is used to map a certificate presented by a client to the user in the directory that should be associated with that certificate. Certificate mapping determines how Convergence server scans user entries in the LDAP directory. Use certmap.conf to configure how a client certificate is mapped to an LDAP entry. You can edit the certmap.conf file to add entries to match the structure of your LDAP directory and to list the certificates you want your users to have. Users can be authenticated based on attributes and their corresponding values used in the subjectDN.
The mapping file defines the following information:
The LDAP tree location the server from where begins its search (Base DN)
Certificate attributes the server should use as search criteria when searching for the entry in the LDAP directory
Whether the server must go through an additional verification process
The file contains one or more named mappings, each applying to a different CA. Note that only lower-case entries can be used in <name>. A mapping has the following syntax:
certmap=<name1>,<name2>,<name3>... <name1>.<property1>=<value> <name1>.<property2>=<value>
For example:
certmap default,<name>,<name1> default.<property1> =<value> default.<property2> =<value> <name>.<property1> =<value> <name>.<property2> =<value> <name1>.<property1> =<value> <name1>.<property2> =<value>
The first line specifies a name(s) for the entry. You can use any name for the entry. If a mapper entry for a specific CA (as present in the IssuerDN in the client certificate) does not exist, the default configuration/mapping is used. Thus, it is recommended to configure default mappings.
The certmap.conf file has the following properties:
The certificate authority IssuerDN of the certificates to which the map applies. (DN format as defined in RFC 2253). The IssuerDN must match the IssuerDN of the CA that issued the client certificate. For example, the following two IssuerDN lines have different space separating the attributes, but the server treats these as two separate entries:
certmap sun1 ou=Sun Certificate Authority,o=Sun, c=US certmap sun2 ou=Sun Certificate Authority, o=Sun, c=US
The following are the valid syntax for IssuerDN:
empty - The corresponding map is invalid. The server will fall back to use the default map. (For example: usps.IssuerDN=).
commented out/not set - The corresponding map is invalid. The server will fall back to use the default map.
Valid RFC 2253 DN - This map will be used for all the certificates, whose IssuerDN matches this DN.
The DNComps property is used to configure the LDAP tree location from where the server begins its search (Base DN).
Specifies a comma separated list of relative distinguished name components of the base DN for an LDAP search to find the user entry matching the certificate. The components are taken from the subject DN of the certificate.
The server gathers values for these attributes from the client certificate and uses the values to form an LDAP DN, which determines where the server starts its search in the LDAP directory. For example, if you set DNComps to use the o and c attributes of the DN, the server starts the search from the o=<org>, c=<country> entry in the LDAP directory, where <org> and <country> are replaced with values from the DN in the certificate.
Any attribute for which a mapping is defined but is not contained in the certificate subject is not included in the generated base DN.
The following are the valid syntax for DNComps:
empty - The server performs a sub-tree search with base DN as the configured Base DN (dcroot) in convergence configuration. (For example: default.DNComps=)
commented out - take the existing user's DN from the cert and this becomes the Base DN. (For example: #default.DNComps=ou,o)
attribute names - a comma separated list of attributes to form DN. The attribute values are taken from the subject DN of the certificate.
Attribute substitutions - attribute and their corresponding LDAP attribute to be used as a substitute while constructing the Base DN. The attribute values are taken from the subject DN of the certificate. (For example: default.DNComps=ou=OrgUnit,o).
Table 3-1 lists the supported attributes for this mapper (as per RFC 2253 and RFC 5280).
Table 3-1 Supported attributes for DNComps
| Attribute Keyword | Description |
|---|---|
|
cn |
Common name |
|
l |
Location |
|
street |
Street |
|
ou |
Organization unit |
|
o |
Organization |
|
c |
Country |
|
uid |
Unique ID |
|
emailaddress |
Email address (RFC 822) |
|
s |
State |
|
serialsnumber |
Serial number for a name |
|
dnq/dnqqualifier |
DN specific information |
|
t |
Person's title (rank) |
|
surname |
Last name |
|
givenname |
First name |
|
initials |
Initials |
|
generation |
Example, jr, III |
|
ip |
IP address |
FilterComps specifies a comma separated list of attributes to form a filter for an LDAP search to find the user entry matching the certificate. The values for the filter are taken from the Subject DN of the client certificate.
If multiple attribute mappings are defined, then the server combines them with an AND search. For example, if two mappings are defined cn and uid, and the server is presented with a certificate having a subject of UID=john.doe@example.com,CN=John Doe,O=Example Corp,C=US, then it generates a search filter of (&(cn=John Doe)(uid=john.doe@example.com)).
Any attribute for which a mapping is defined but is not contained in the certificate subject is not included in the generated search filter. All attributes that can be used in generated search filters should have corresponding indexes in all back-end databases that can be searched by this certificate mapper. For the mapping to be successful, the generated search filter must match one user in the directory (within the scope of the base DNs for the mapper). If no users or multiple users match the generated criteria, the mapping fails.
The following are the valid syntax for FilterComps:
empty - The generated search filter is (objectclass=*) (For example: default.FilterComps=)
commented out - The generated search filter is (objectclass=*) (For example: #default.DNComps=cn)
attribute names - a comma separated list of attributes to form search. The attribute values are taken from the subject DN of the certificate. If multiple attribute mappings are defined, then the server combines them with an AND search.
Attribute substitutions - attribute and their corresponding LDAP attribute to be used as a substitute while constructing the search filter. The attribute values are taken from the subject DN of the certificate. (For example: default.FilterComps=uid=employeeID,emailaddress=mail)
Table 3-2 lists the supported attributes for this mapper (as per RFC 2253 and RFC 5280).
Table 3-2 Supported attributes for FilterComps
| Attribute Keyword | Description |
|---|---|
|
cn |
Common name |
|
l |
Location |
|
street |
Street |
|
ou |
Organization unit |
|
o |
Organization |
|
c |
Country |
|
uid |
Unique ID |
|
emailaddress |
Email address (RFC 822) |
|
s |
State |
|
serialsnumber |
Serial number for a name |
|
dnq/dnqqualifier |
DN specific information |
|
t |
Person's title (rank) |
|
surname |
Last name |
|
givenname |
First name |
|
initials |
Initials |
|
generation |
Example, jr, III |
|
ip |
IP address |
CmapLdapAttr specifies the name of the LDAP attribute in the directory containing the subject DN of the certificate.
Unless this attribute is empty, the baseDN is the convergence configured Base DN (DC root) with a search filter containing subject DN. For the mapping to be successful, the certificate mapper must match exactly one user (within the scope of the base DNs for the mapper). If no entries or multiple entries match, the server performs a search with the baseDN generated from the corresponding DNComps and the search filter from the corresponding FilterComps.
The following is the valid syntax for CmapLdapAttr:
Attribute name - is a name for the attribute in the LDAP directory that contains subject DNs from all certificates belonging to the user. (For example: default.CmapLdapAttr=certSubjectDN)
VerifyCert tells the server whether it should compare the client's certificate with the certificate found in the LDAP directory. It takes two values: on and off. This feature is useful to ensure your end-users have a valid, un-revoked certificate. However, you should only use this property if your LDAP directory contains certificates.
The default behavior is the same as off, meaning client certificates are not checked to be valid and not revoked.
The following is the valid syntax for VerifyCert:
on - compare's client certificate with the certificate found in the userCertificate attribute in user's LDAP entry (For example: default.VerifyCert=on)
The certmap.conf file should have at least one entry. The following examples illustrate the different ways you can use the certmap.conf file.
The following example represents a certmap.conf file with only one default mapping:
certmap=default default.DNComps=ou, o, c default.FilterComps= emailaddress=mail, uid default:verifycert=on default.issuerDN=default
Using this example, the server starts its search at the LDAP branch point containing the entry {{ou=<orgunit>, o=<org>, c=<country>}} where the text within <> is replaced with the values from the subject's DN in the client certificate.
The server then uses the values for email address and user ID from the certificate to search for a match in the LDAP directory. The search filter would be &(mail=<email>)(uid=<uid>)). When it finds an entry, the server verifies the certificate by comparing the one the client sent to the one stored in the directory.
The following example file has two mappings, one for default and another for the US Postal Service:
certmap=default,usps default.DNComps= default.FilterComps=emailaddress, uid usps.IssuerDN=ou=United States Postal Service, o=usps, c=US usps.DNComps=ou,o,c usps.FilterComps=emailaddress=mail usps.verifycert=on default.issuerDN=default
When the server gets a certificate from someone other than the USPS, it uses the default mapping, which starts at the configured base DN (DC root) and searches for an entry matching the client's user ID and email address. If the certificate is from the USPS, the server starts its search at the base DN containing the organizational unit and searches for matching email addresses. Note that if the certificate is from the USPS, the server verifies the certificate; other certificates are not verified.
Note:
The IssuerDN in the certificate must be identical to the IssuerDN listed in the first line of the mapping. In the previous example, a certificate from an issuer DN that is o=United States Postal Service,c=US will not match because there is no space between the o and the c attributes.The following example uses CmapLdapAttr to scan the LDAP database for the certSubjectDN attribute whose value exactly matches the entire subject DN taken from the client certificate.
certmap=myco myco.IssuerDN=ou=My Company Inc, o=myco, c=US myco.CmapLdapAttr=certSubjectDN myco.DNComps=o, c myco.FilterComps=emailaddress=mail, uid myco.verifycert=on
If the client certificate subject is:
uid=Walt Whitman, o=LeavesOfGrass Inc, c=US
the server first searches for entries that contain the following information:
certSubjectDN=uid=Walt Whitman, o=LeavesOfGrass Inc, c=US
If a matching entry is found, the server verifies the entry. If no matching entries are found, the server uses DNComps and FilterComps to search for matching entries. In this example, the server would search for uid=Walt Whitman in all entries under o=LeavesOfGrass Inc, c=US.
To enable certificate authentication support using the iwcadmin command, set the auth.cert.enable property to true. Then restart the GlassFish server.
Note:
In GlassFish Server, if certificate authentication support is enabled when a user accesses Convergence without certificate authentication, then certificate authentication support will fall back to form-based authentication. To ensure proper fallback, add the <property name="com.sun.grizzly.ssl.auth" value="want"/> to the http-listener on your GlassFish server.If the form-based option is set to true, and certificate-based authentication is disabled, when the user accesses Convergence without certificate authentication, a login page is displayed. Additionally, Convergence can be accessed on another port.
To enable fallback to form-based authentication when certification authentication is enabled, set auth.cert.enablefallback to true using the iwcadmin command.
You can enhance Convergence security with single sign-on (SSO).
Oracle recommends that you deliver SSO functionality using Oracle Access Manager. You can also use Trusted Circle SSO.
See Convergence System Administrator’s Guide for information about enabling SSO.
You can write your own customized SSO module for Convergence. See "Writing a Custom Pluggable SSO Module" for more information. The SSO module is not an SSO provider, but rather enables an entire site with the same SSO provider to use SSO between Convergence and other web applications.
You can configure Convergence to enable email encryption and digital signing. Convergence uses S/MIME to encrypt and sign email messages.
See Convergence System Administrator’s Guide for information about enabling S/MIME for email encryption.
Inform and educate users about sending encrypted email messages. The Convergence online Help explains how to encrypt email messages.
The following sections can help monitor Convergence for security threats and prevent possible attacks.
Email spam detection and prevention is a complex issue that is difficult to eliminate. You can reduce its impact on your system, internal users, and external email recipients.
See Messaging Server Security Guide for more information.
Messaging Server provides a number of mechanisms to limit or throttle email delivery. These mechanisms can help prevent intentional or accidental Denial-of-Service attacks.
See Messaging Server Security Guide for more information.
The following article on the Oracle technology web site explains several ways you can configure Messaging Server to prevent denial of service (DoS) attacks:
http://www.oracle.com/technetwork/systems/articles/preventingdosattacks-jsp-138891.html
Repeated login failures could be indicative of an external party trying to gain access to an account. You can review LDAP server logs for failed logon attempts. With Oracle Internet Directory, logon failures are recorded as Bind Failures in the access log file access.txt. See your LDAP or directory server documentation for more information about logging.
You can install Oracle Outside Transformation Server In to enable Convergence to preview all kinds of attachments in the browser. Oracle Outside In is an optional module.
The Convergence server authenticates users before they can view attachments. Convergence generates a session cookie that contains a server-generated URL for each attachment request to the Outside In proxy. The proxy sends the request to the Transformation Server, which renders the attachment for the user to view.
The server generated URL is not displayed in Convergence.
If you integrate Convergence with Oracle Outside In Transformation Server, you must configure the Outside In Transformation Server to prevent security attacks.
Configure a time out to purge files stored in the transformation server. By default, the time out is set to 5 minutes.
Configure each user directory to store a maximum number of files before replacing existing older files. By default, each user directory can hold a maximum of 10 files.
See the discussion about managing attachment life cycles in Convergence System Administrator’s Guide for more information.
By default, Convergence imposes a maximum size on outgoing email attachments of 5MB. Depending on how Oracle Outside In Transformation Server is set up, you may need to adjust the maximum attachment size to decrease the risk of overloading the transformation server.