| Oracle® Communications Instant Messaging Server Security Guide Release 9.0.2 E53652-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Instant Messaging Server Security Guide Release 9.0.2 E53652-01 |
|
|
PDF · Mobi · ePub |
This chapter explains the security features of Oracle Communications Instant Messaging Server and the following tasks:
Security requirements arise from the need to protect data: first, from accidental loss and corruption, and second, from deliberate unauthorized attempts to access or alter that data. Secondary concerns include protecting against undue delays in accessing or using data, or even against interference to the point of denial of service. The global costs of such security breaches run up to billions of dollars annually, and the cost to individual companies can be severe, sometimes catastrophic.
The critical security features that provide these protections are:
Authentication
Access Control
Secure Communications
Authentication is the way in which an entity (a user, an application, or a component) determines that another entity is who it claims to be. An entity uses security credentials to authenticate itself. The credentials might be a user name and password, a digital certificate, or something else. Usually, servers or applications require clients to authenticate themselves. Additionally, clients might require servers to authenticate themselves. When authentication is bidirectional, it is called mutual authentication.
Access Control, also known as authorization, is the means by which users are granted permission to access data or perform operations. After a user is authenticated, the user's level of authorization determines what operations the user can perform.
Instant Messaging Server supports TLS for secure communications. This section provides instructions for setting up security for Instant Messaging Server by using TLS.
Instant Messaging Server uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers.
Communication between multiplexor and server is over an unsecured transport. When you use TLS for client-to-server communication, the multiplexor simply passes the data from the client to the server and back and does not perform any encryption or decryption.
TLS is fully compatible with SSL and includes all necessary SSL functionality. TLS and SSL function as protocol layers beneath the application layers of XMPP and HTTP.
For Java requirements to use TLS with Instant Messaging Server, see the topic on required software in Instant Messaging Server Installation and Configuration Guide.
For information on TLS and StartTLS in XMPP, see Use of TLS in RFC 3920, Extensible Messaging and Presence Protocol: Core, at:
http://www.ietf.org/rfc/rfc3920.txt
For an overview of certificates, SSL, and TLS, see Sun GlassFish Enterprise Server v2.1.1 Administration Guide. These procedures assume that you are using the GlassFish Server (formerly Sun Java System Application Server) to generate certificates. If you are using another web container, such as Oracle iPlanet Web Server (formerly Sun Java System Web Server), refer to that web container's documentation for specific instructions on generating keystores and certificates.
Enabling TLS for Instant Messaging Server server-to-server and client-to-server communication requires the following general steps:
Creating a Java keystore (JKS) and a private key by using the keytool utility.
For an overview of the keytool utility, see "Tools for Managing Security" in Sun GlassFish Enterprise Server v2.1.1 Administration Guide. For instructions on generating the JKS by using GlassFish Server, see "Working with Certificates and SSL" in Sun GlassFish Enterprise Server v2.1.1 Administration Guide.
Using the private key to generate a server certificate for the Instant Messaging server.
See "Generating a Certificate Using the keytool Utility" in Sun GlassFish Enterprise Server v2.1.1 Administration Guide for instructions.
Getting the Instant Messaging server certificate signed by a Certificate Authority (CA).
See "Signing a Digital Certificate Using the keytool Utility" in Sun GlassFish Enterprise Server v2.1.1 Administration Guide for instructions. Replace GlassFish Server with Instant Messaging Server where applicable.
Restarting Instant Messaging Server.
See Instant Messaging Server System Administrator's Guide for details.
Obtaining the CA's root certificate.
Contact your CA for instructions on obtaining the CA's root certificate.
Importing the certificates into the keystore.
You import the CA root certificate and the signed server certificate into the keystore by using the keytool utility as described in "Using the keytool Utility" in Sun GlassFish Enterprise Server v2.1.1 Administration Guide.
Activating TLS in the server by setting the appropriate configuration properties.
For instructions see "Activating TLS on Instant Messaging Server".
For server-to-server communication over TLS, you need to repeat these steps for each server that communicates over TLS. You also do not need to configure the multiplexor for TLS.
Configuring the gateway to communicate directly with the Instant Messaging server and not the multiplexor, if you are using the XMPP/HTTP Gateway in your deployment.
If you are using GlassFish Server, steps 1 through 6 are documented in "Working with Certificates and SSL" in Sun GlassFish Enterprise Server v2.1.1 Administration Guide. Step 7 is described in "Activating TLS on Instant Messaging Server".
Before you can activate TLS on the server, you must create a JKS, obtain and install a signed server certificate, and trust the CA's certificate as described in "Setting Up TLS for Instant Messaging Server". You activate TLS on the server when you want to use TLS for server-to-server and/or client-to-server communication.
Table 3-1 lists the configuration properties used to enable TLS in Instant Messaging Server. It also contains the description and the default values for these properties.
Table 3-1 Instant Messaging Server TLS Configuration Properties
| Property | Default Value | Description |
|---|---|---|
|
iim_server.sslkeystore |
None |
Contains the relative path and file name for the server's Java keystore (JKS). For example: InstantMessaging_home/server-keystore.jks |
|
iim_server.keystorepasswordfile |
sslpassword.conf |
Contains the relative path and the name of the file that contains the password for the keystore. This file should contain the following line:
Internal (Software) Token:password
where password is the password protecting the keystore. |
|
iim_server.requiressl |
false |
If this value is true, the server terminates any connection that does not request a TLS connection after the initial stream session is set up. |
|
iim_server.trust_all_cert |
false |
If this value is true, the server trusts all certificates, including expired and self-signed certificates, and also adds the certificate information into the log files. If false, the server does not log certificate information and trusts only valid certificates signed by a CA. |
Use this procedure to configure Instant Messaging Server to use secure communication over TLS in the following ways:
Require TLS for all client and server connections.
Require TLS only for specific server-to-server connections.
Allow TLS connections for clients and servers that request a secure transport after the initial communication session has been set up.
A combination of requiring TLS for specific server-to-server connections and allowing TLS connections for other clients and servers.
Ensure that you have created a JKS, obtained and installed a server certificate, and configured the server to trust the CA's certificate as described in "Setting Up TLS for Instant Messaging Server".
For server-to-server TLS communication, you must complete this procedure on each server you want to configure to use TLS.
Set the iim_server.sslkeystore and iim_server.keystorepasswordfile configuration properties.
For example:
imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop iim_server.sslkeystore=/opt/sun/comms/im/config/server-keystore.jks
iim_server.keystorepasswordfile=sslpassword.conf
The server now responds to a connection request from any client or another Instant Messaging server with the information that it is able to communicate over TLS. The requesting client or server then chooses whether to establish a secure connection over TLS.
If you want the server to require TLS for all connections from clients, and remote and peer servers, add the iim_server.requiressl=true configuration property.
For example:
imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop iim_server.requiressl=true
When you set this configuration property to true, the server terminates a connection with any client or remote or peer server that does not support TLS. Use this parameter to require secure client-server communication over TLS.
For more information about server-to-server communication, see Instant Messaging Server System Administrator's Guide.
If you want to require TLS for communication with a specific remote or peer server, set the requiressl coserver property.
For example:
imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-coserver-prop coserver1 requiressl=true
Set this property for each coserver for which you want to require TLS.
When you set iim_server.requiressl to true, the server requires a TLS connection for any server with which it communicates. In this case, you do not need to set this parameter for specific coservers.
(Optional) If you want the server to trust all certificates it receives, and to add certificate information to the log files, add the iim_server.trust_all_cert=true configuration property:
For example:
imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop iim_server.trust_all_cert=true
WARNING:
You might need to use this feature to test your deployment before you go live. However, you typically should not do this on a deployed system as it presents severe security risks. When this value is true, the server trusts all certificates, including expired and self-signed certificates, and also adds the certificate information into the log files. When this value is false, the server does not log certificate information and trusts only valid certificates signed by a CA.
Refresh the server configuration by using the imadmin command.
imadmin refresh server
Verify that TLS is working properly.
You can use the passwordtool command to encrypt a password for either the Instant Messaging HTTPBIND Web component or the Web Presence API and use the encrypted password in the component's configuration file. For more information, see the passwordtool reference information in Instant Messaging Server System Administrator's Guide.
This information describes how to write a custom SSO module for Instant Messaging Server so that SSO support can be added for third-party SSO solutions.
As with any SSO aware application, when a user is authenticated, Instant Messaging Server loads the authentication module to validate the user. On successful validation, the user is allowed to access the application. If the validation is not successful, the standard password validation occurs.
The SSOProvider API documentation is provided as part of the Instant Messaging Server installation. You can find the documentation in InstantMessaging_home/html/apidoc, which, by default, is /opt/sun/comms/im/html/apidoc.
Instant Messaging Server calls the verify method provided by the custom SSO provider with the uid and token arguments.
The token argument is the password provided by the Instant Messaging client during the SASL PLAIN authentication. For example the client has sent the following:
<body rid='607740' sid='7675823097240743042' xmlns='http://jabber.org/protocol/httpbind' key='c654f46426c6d12cf2a0e1a9beb218915e0afd6f' ><auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'>c2hqb3J0aEBhdS5vcmFjbGUuY29tAHNoam9ydGgAc2VjcmV0dG9rZW4=</auth></body>
c2hqb3J0aEBhdS5vcmFjbGUuY29tAHNoam9ydGgAc2VjcmV0dG9rZW4= is the base64 encoded SASL PLAIN string as per the XEP-0034 standard. This string decodes to:
shj@example.com<NUL>shjorth<NUL>secrettoken
where:
shj@example.com is the authorization identity
shj is the authentication identity
secrettoken is the password (or in this case the SSO token) provided by the IM client
<NUL> is the NUL character
Before designing a solution for the custom SSO module, the Instant Messaging Server SSO provider framework needs to be implemented:
All custom SSO modules must implement SSOProvider interface.
The SSO verification implementation must provide the domain of the authenticating user if iim.userprops.store is set to ldap.
The SSO implementation can use any other classes that are required to make the custom SSO module work.
Create the Custom SSO Java file.
mkdir -p com/client/sample/
Use the following sample code to create the file.
com/client/sample/CustomSSOProvider.java
import java.util.Map;
import com.iplanet.im.server.RealmManager;
import com.iplanet.im.server.LocalUser;
import com.iplanet.im.server.LDAPUserSettings;
import com.iplanet.im.common.util.Log;
public class CustomSSOProvider implements SSOProvider {
// This is called for each authentication. It can return true or false.
public boolean verify(String uid, String token, java.util.Map attributes, java.util.Set attributeNames){
String domain = "your.domain.com";
Log.debug(String.format("CustomSSO: Trying to authenticate user: %s, token = %s\n", uid, token));
// Replace the following check with your SSO token verification routine
if (token.equalsIgnoreCase("secrettoken") == false) {
Log.debug("CustomSSO: 'secrettoken' not provided as password, SSO login attempt failed");
return false;
}
// If user properties are stored in LDAP then need to retrieve them
if (RealmManager.getUserSettingsStorageProvider() instanceof LDAPUserSettings) {
Log.debug("CustomSSO: iim.userprops.store = \"ldap\"");
try{
LocalUser u = RealmManager.getUser(uid, domain, true);
// the domain is mandatory if using a hosted domain configuration
// the boolean third parameter forces an LDAP fetch
// (disregarding previously cached entries)
if(u != null){
for(Object o: attributeNames){
String s = (String) o;
Log.debug("CustomSSO: attributeName: " + s);
Set prop = u.getAttributeValues(s);
attributes.put(s, prop);
}
return true;
}
}
catch(RealmException ex){
Log.error("CustomSSO: could not load user: " + uid + " in domain: " + domain);
return false;
}
}
else {
Log.debug("CustomSSO: iim.userprops.store = \"file\"");
return true;
}
return false;
}
// This is called each time there's some XMPP activity by the user. The
// SSO implementation can use this to keep the session from timing out.
public boolean refresh(String uid) {
Log.debug("CustomSSO: refresh called " + uid);
return true;
}
// This is for any SSO initialization and is called once on server startup
public void open() throws Exception {
Log.debug("CustomSSO: open called");
}
// this is called before the server is shutdown, though its not guaranteed
public void close() {
Log.debug("CustomSSO: close called");
}
}
Compile the source.
Make sure to compile with JDK1.6. This example uses the JDK installed by the Communications Suite installer under /usr/jdk/latest on Solaris OS and Instant Messaging Server under /opt/sun/comms/im.
/usr/jdk/latest/bin/javac -classpath /usr/share/lib/xmpp/improvider.jar:/opt/sun/comms/im/lib/xmppd.jar:/opt/sun/com ms/im/lib/imcommon.jar:/opt/sun/comms/im/lib/imnet.jar com/client/sample/CustomSSOProvider.java
Create the jar archive from the compiled files.
/usr/jdk/latest/bin/jar -cvf CustomSSOProvider.jar com/client/sample/CustomSSOProvider.class
Move the compiled jar file to the Instant Messaging Server library directory.
chown bin:bin CustomSSOProvider.jar cp -p CustomSSOProvider.jar /opt/sun/comms/im/lib
Add the jar file to the imadmin command.
cp imadmin imadmin.orig
Edit the imadmin command and add the following to the end of the server_classpath variable setting:
$PCD/CustomSSOProvider.jar
Run the imconfutil command with the following properties to enable the provider.
iim_server.usesso = "1" iim_server.ssoprovider = "com.client.sample.CustomSSOProvider"
Restart the XMPP server.
cd /opt/sun/comms/im/ ./imadmin stop ./imadmin start
You should now see the following in the xmppd.log file (when debug log-level is enabled in the log4j.conf file) when logging in by using the password secrettoken:
[13 Sep 2010 08:53:34,857] DEBUG xmppd [Thread-15] CustomSSO: Trying to authenticate user: shjorth, token = secrettoken [13 Sep 2010 08:53:34,857] DEBUG xmppd [Thread-15] CustomSSO: iim.userprops.store = "ldap" [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: uid [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: uniquemember [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: givenname [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunPresenceAccessPermitted [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunIMUserNewsRoster [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunIMUserConferenceRoster [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: userpassword [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunIMRoster [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunIMConferenceRoster [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunIMNewsRoster [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunIMUserProperties [13 Sep 2010 08:53:34,898] DEBUG xmppd [Thread-15] CustomSSO: attributeName: sunPresenceEntityDefaultAccess ...
For Solaris OS installations of Instant Messaging Server, check the following file for errors when starting the Instant Messaging server:
/var/svc/log/application-sunim:default.log
Different sites using Instant Messaging Server have different needs in terms of enabling and restricting the type of access end users have to the Instant Messaging service. The process of controlling end user and administrator Instant Messaging Server features and privileges is referred to as policy management. You administer policy management through access file controls. The access control file method for managing policies enables you to adjust end-user privileges for conference room management and the ability to change user preferences. It also enables specific end users to be assigned as system administrators.
Table 3-2 lists Instant Messaging Server policy configuration properties.
Table 3-2 Policy Configuration Properties
| Property | Use | Values |
|---|---|---|
|
iim.policy.modules |
Indicates the schema to be used by Instant Messaging Server. |
iim_ldap (default), iim_ldap_schema1, or iim_ldap_schema2 |
|
iim.userprops.store |
Indicates whether the user properties are in a user properties file or stored in LDAP. Only significant when the service definitions for the Presence and Instant Messaging services have been installed. |
One of the following:
|
The iim.policy.modules configuration property identifies iim_ldap for the access control file method, which is also the default.
Use the imconfutil command to set the iim.policy.modules configuration property to iim_ldap (default, the access control file method).
Use the imconfutil command to set the iim.userprops.store configuration property to one of the following:
ldap (default, for storing user properties in LDAP)
If you choose ldap, you can run imadmin assign_services to add the required object classes that store user properties to user entries in the directory.
file (for storing user properties in files, no longer recommended.)
Refresh the configuration.
By editing access control files you control the following end-user privileges:
Access to the presence status of the other end users
Save properties on the server
Create new conference rooms
By default, end users are provided the privileges to access the presence status of other end users and save properties to the server. For most deployments, default values do not need to be changed.
Although certain privileges can be set globally, the administrator can also define exceptions for these privileges. For example, the administrator can deny certain default privileges to select end users or groups.
In addition, if you are enforcing policy through access control files in your deployment, those files must be the same for all servers in a server pool.
Table 3-3 lists the global access control files for Instant Messaging Server and the privileges these files provide end users.
Table 3-3 Access Control Files
| ACL File | Privileges |
|---|---|
|
sysSaveUserSettings.acl |
Defines who can and cannot change their own preferences. Users who do not have this privilege cannot add contacts, create conferences, and so on. |
|
sysRoomsAdd.acl |
Defines who can and cannot create Conference rooms. |
|
sysWatch.acl |
Defines who can and cannot watch changes of other end users. |
|
sysAdmin.acl |
Reserved for administrators only. This file sets administrative privileges to all Instant Messaging Server features for all end users. This privilege overrides all the other privileges and gives the administrator the ability to create and manage conference rooms as well as access to end user presence information, settings, and properties. |
Change to the InstantMessaging_cfg_home/acls directory.
See the configuration and file directory structure content in the Instant Messaging Server System Administrator's Guide for information on locating InstantMessaging_cfg_home.
Edit the appropriate access control file.
For example:
vi sysRoomsAdd.acl
See "Access Control File Location" for a list of access control files.
Save the changes.
End users need to refresh Instant Messaging client to see the changes.
If you are enforcing policy through access control files in your deployment, the content of the files must be the same for all servers in a server pool. To ensure this, copy the files from one server to each of the other nodes in the pool. See "Access Control File Location" for information on finding these files.
The location of the access control files is InstantMessaging_cfg_home/acls. See the configuration and file directory structure content in the Instant Messaging Server System Administrator's Guide for information about the default location of the configuration directory.
The access control file contains a series of entries that define the privileges. Each entry starts with a tag as follows:
d: - default
u: - user
g: - group
The tag is followed by a colon (:). In case of the default tag it is followed by true or false.
End-user and group tags are followed by the end-user or group name.
Multiple end users and groups are specified by having multiple end users (u) and groups (g) in lines.
The d: tag must be the last entry in an access control file. The server ignores all entries after a d: tag. If the d: tag is true, all other entries in the file are redundant and are ignored. You cannot set the d: tag as true in an access control file and selectively disallow end users that privilege. If default is set to false, only the end users and groups specified in the file will have that particular privilege.
The following are the default d: tag entries in the ACL files for a new installation:
sysAdmin.acl - Contains d:false
sysRoomsAdd.acl - Contains d:true
sysSaveUserSettings.acl - Contains d:true
sysWatch.acl - Contains d:true
|
 Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|