12
Security

The Oracle Message Broker security features are integrated with the Oracle Message Broker. To ensure a secure system, it is essential that the Oracle Message Broker administrator understand the security requirements for the installation, and the security features available with the Oracle Message Broker.

This chapter covers the following:

• Features and Assumptions

• Security Components

• LDAP Directory Server Security Administration

• Oracle Message Broker Security Administration

• Provider Security Administration

Figure 12-1 shows the components of a sample Oracle Message Broker deployment.

Figure 12-1 Sample Oracle Message Broker Deployment

Features and Assumptions

To implement its security features, the Oracle Message Broker supports security in the following areas:

• LDAP Server Security - including mechanisms for protecting the LDAP Directory information from unauthorized access. Also, Secure Sockets Layer (SSL) is used for securing the network connections to the LDAP server.

• Oracle Message Broker and JMS Client Security - including SSL for securing network connections and authentication and authorization. This security area secures the connection between a JMS Client and an active Oracle Message Broker, and between Oracle Message Brokers when using propagation. This security area also includes the Oracle Message Broker Security Service to control access to Oracle Message Broker destinations (queues and topics).

• Oracle Message Broker Provider Security - the Oracle Message Broker drivers support several different providers, called message servers, for storing messages. The Oracle Message Broker supports provider defined security features specific to particular message servers.

In addition, the Oracle Message Broker supports the following security features:

• An encryption facility to store passwords in the LDAP Directory.

• Security for all network connections. This provides support for data integrity, privacy, certificate based authentication, and non-repudiation.

• Customization of the security features that a particular installation utilizes.

• Allowing administrators to specify a username and password in connection factories and using this information as credentials while accessing an underlying provider (driver).

SSL Overview

Secure Sockets Layer (SSL) is an industry standard protocol for securing network connections. SSL provides:

• Encrypted connections (privacy)

• Authentication - server-side or server-side and client-side

• Integrity (a third party cannot modify data)

• Non repudiation

SSL provides authentication through the exchange of certificates that are verified by trusted certificate authorities. A certificate ensures that an entity's identity information is correct. Additional information on SSL is available at the following web site,

http://home.netscape.com/eng/ssl3/ssl-toc.html

Programming and Administration Control and Assumptions

In order to ensure that an Oracle Message Broker installation is as secure as possible, in this chapter we assume that an administrator understands the following:

• The LDAP Server and its administration

• SSL

• JNDI

• Provider security (Oracle Message Broker drivers)

Furthermore, to ensure Oracle Message Broker security, the application programmer is responsible for making the correct JNDI and JMS API calls.

Administration Summary

The following components can be configured independent of each other:

• LDAP server authentication/authorization - users/groups configuration and access control information setup for the LDAP server is performed using the LDAP server configuration tools. If using OiD, ldapsearch/ldapmodify and/or oidadmin can be used for this purpose.

• Enabling SSL for the LDAP server SSL configuration is performed using the LDAP server configuration tools. If using OiD, ldapsearch/ldapmodify and/or oidadmin can be used for this purpose.

• Enabling SSL for the ORB - Enabling SSL for the ORB is done through ORB tools. For SSL connections, Oracle Message Broker uses Oracle Wallets. The administrator needs to use the Oracle Wallet Manager to manage wallets.

• Configuring message provider specific security.

• Enabling proxy and SSL for HTTP propagation.

• Protecting Oracle Message Broker destinations.

Administration Tasks

It is the administrator's responsibility to setup security. By default, on installation security is not enabled. The administrator needs to perform the following optional tasks to secure Oracle Message Broker:

• Enabling SSL for the ORB

• Enabling SSL for the LDAP Directory directory

• Controlling access to the LDAP Directory entries

• Using provider/driver specific security features

• Enabling proxy and SSL for HTTP propagation

• Creating Oracle Message Broker users, groups, and ACLs.

Error Reporting

All fatal errors and malicious attempts to breach Oracle Message Broker security are logged in the Oracle Message Broker log file. Security related non-fatal errors are logged in the Oracle Message Broker log file if the Java property oracle.oas.mercury.sec.trace is defined.

The Oracle Message Broker never logs passwords in exception messages.

Security Components

This section covers the following:

• LDAP Server Security

• Oracle Message Broker Security

• Provider Security

• Security Priority

• Network Security Overview

• Supported Cipher Suites

LDAP Server Security

Using LDAP based configuration the Oracle Message Broker stores its configuration information in the LDAP Directory. By controlling read access to LDAP Directory entries containing destinations, connection factories, and the msg_broker entry, the Oracle Message Broker administrator can control access for the JMS Client to the Oracle Message Broker and to its destinations.

Note: This chapter does not cover security with Lightweight Configuration security.

If a JMS client cannot read the msg_broker entry in an OMB Instance stored in an entry in the LDAP Directory, then it cannot connect to the Oracle Message Broker. A connection factory is required to connect to the Oracle Message Broker.

If a JMS client does not have read access to a particular Oracle Message Broker destination entry (topic or queue), it is not aware of the destination and therefore will not be able to request access to it from the broker.

Access limitations for information in the directory consists of authentication and authorization. When an LDAP client connects to an LDAP server, the client uses a username/password to authenticate itself. The server then evaluates the access control information (ACI) for the directory entry/attribute requested and based on this evaluation allows the client access to the information or denies it.

This section covers the following areas of LDAP Server security:

• LDAP Directory Authentication

• LDAP Directory Authorization

• LDAP Directory Secure Sockets Layer Connections

• Security Roles

LDAP Directory Authentication

Authentication is the process by which the LDAP Server establishes the true identity of the user connecting to the LDAP Directory (for information on setting up user entries, refer to "LDAP Directory Server Security Administration").

Directory authentication occurs when an LDAP session is established by connecting to a directory. Every LDAP session has an associated user identity. This user identity is also referred to as the authorization ID. To ensure that LDAP Directory users' and clients' identities are correctly known, the Oracle Message Broker provides two options for connecting to the LDAP Directory: anonymous and simple authentication. Table 12-1 describes these authentication options.

Table 12-1  Directory Authentication Options in Oracle Message Broker

Authentication	Description
Anonymous	If the LDAP Directory is available to everyone, then you can allow users to log in to the directory anonymously. In this case, when using Oracle Message Broker commands, administrators simply leave the user name and password fields blank when they are prompted (or specify blank values using the command line options, or use the -noauth option). Each anonymous user then exercises whatever privileges are specified for anonymous users.
Simple	In this case, the client identifies itself to the server by means of a bind DN and a password. The values are sent in the clear over the network (unless SSL is enabled, in which case the information sent over the network can be encrypted, depending on the SSL level specified). The LDAP server verifies that the DN and password sent by the client match the DN and password stored in the LDAP Directory.

The following Oracle Message Broker components use LDAP Authentication when they contact the LDAP Directory:

• The MsgBroker command at startup - the Oracle Message Broker uses authentication to validate the user and password for the Oracle Message Broker whenever, during it execution, it accesses the directory.

• JMS Client programs that access the LDAP Directory to obtain Oracle Message Broker administration information (through JNDI) - these programs use authentication to validate the user and password for LDAP Directory access.

• The administration utilities, including AdminUtil, AdminDirCheck, ombadmin, LDAPSchema, and InitDir. These utilities use authentication to validate the user and password for their LDAP Directory access.

  See the following references for more information on providing options for LDAP Authentication:

  	AdminUtil	"Command-line Administration Utility - AdminUtil"
  	AdminDirCheck	"Checking Directory Entries with AdminDirCheck"
  	JMS Client Programs	"Enabling Propagation Security"
  	InitDir	Oracle Message Broker Installation Guide
  	LDAPSchema	Oracle Message Broker Installation Guide
  	MsgBroker	"Starting and Stopping the Oracle Message Broker"
  	ombadmin	"Starting Oracle Message Broker Manager"

LDAP Directory Authorization

Authorization is the process of ensuring that a user reads or updates only the information for which that user has privileges. When directory operations are attempted within a directory session, the directory server ensures that the user- identified by the authorization ID associated with the session has the requisite permissions to perform those operations. Otherwise, the operation is disallowed. Through this mechanism, the directory server enforces authorization policies in order to protect the directory data from unauthorized operations. This mechanism is called access control.

Access Control Information (ACI) is the directory metadata that captures the administrative policies relating to access control.

ACI is stored in the directory as user-modifiable operational attributes. Typically, a list of these ACI attribute values, called an Access Control List (ACL), is associated with directory objects. The attribute values on that list govern the access policies for those directory objects.

ACIs are represented and stored as text strings in the directory. These strings must conform to a well defined format. Each valid value of an ACI attribute represents a distinct access control policy. These individual policy components are referred to as ACI Directives or ACI Items and their format is called the ACI Directive format.

Note: The following information on ACLs is specific to the Oracle Internet Directory implementation of LDAP. This may not apply for other LDAP implementations.

ACLs are stored as special operational attributes of an entry. ACLs are inherited by an entry from its parents and can be overridden.

LDAP Directory Secure Sockets Layer Connections

The Oracle Message Broker supports SSL for connections to the directory from any of its components (for an overview of SSL, see "SSL Overview"). Each of the Oracle Message Broker commands that access the directory support options to specify an SSL connection mode. JMS Clients need to set properties to specify an SSL connection mode. Note that JMS Clients can have two SSL connections, one from the JMS Client to the Oracle Message Broker, and another from the JMS Client to the LDAP Directory. SSL can be enabled for none, one, or both of these JMS Client connections (for details on JMS Client properties, refer to "Oracle Message Broker SSL Options").

Table 12-2 lists the supported SSL connection modes. In the descriptions in Table 12-2, client refers to an LDAP client.

Note: The Oracle Message Broker also supports a connection mode where SSL is disabled. In this mode, the SSL encryption/decryption and SSL authentication are both disabled.

Table 12-2  SSL Connection Modes

SSL Connection Mode	Description
No authentication	Neither the client nor the LDAP server authenticates itself. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used. In this configuration, there is no requirement for certificate management.
One-way authentication	Only the LDAP Server authenticates itself to the client. The LDAP Server sends the client a certificate verifying that the server is authentic.
Two-way authentication	Both client and the LDAP Server authenticate themselves to each other. Both the client and the LDAP Server send certificates to each other.

There are performance considerations to keep in mind when using an LDAP Directory to lookup configuration information. When the Oracle Message Broker operates using a remote LDAP Directory, each access to the directory involves network activity. When SSL is enabled, data is encrypted for transmission over the network. This data encryption, and subsequent decryption can have an impact on performance. When SSL security is required, and performance is an issue, an SSL hardware accelerator should be considered.

Security Roles

To limit directory access, and the potential for erroneous or malicious directory modification, different types of Oracle Message Broker users can be set up to have different security roles for accessing the LDAP Directory. Each role should be given a different set of access permissions. The access, and modification of directory entries is enforced by the LDAP Directory's access control mechanism.

Table 12-3 shows the recommended security roles that can be setup in the LDAP Directory to support the Oracle Message Broker.

Table 12-3  Security Roles

Role	Purpose
Administrator	Creates, modifies, and deletes OMB Instances, drivers, queues, topics, servers, and other Oracle Message Broker administrative entries. The Oracle Message Broker administrator needs to have authorization and permissions that allows for adding, deleting, and searching entries underneath the following entry: cn=OMB,cn=Products,cn=OracleContext,....
MsgBroker Instance User	Accesses all the entries underneath a single OMB Instance. A MsgBroker Instance User creates, updates, and deletes entries underneath an OMB Instance. When the Oracle Message Broker is running, any changes that are made to the LDAP Directory within the active OMB Instance using either AdminUtil or ombadmin are channeled through the Oracle Message Broker. This allows the MsgBroker Instance User to act as the administrator for the active, OMB Instance. MsgBroker Instance User authentication is set with the user DN and password specified when the Oracle Message Broker is started using the MsgBroker command. In Local Mode, the MsgBroker Instance User authentication is set in the call that starts the Oracle Message Broker. The MsgBroker's authentication should have access permissions similar to the Oracle Message Broker Administrator, but permissions for a MsgBroker user could be limited to a single OMB Instance.
JMS Client User	A JMS Client user does not need to create, delete, or modify OMB Instance entries. JMS Client users require read and search permissions for an Oracle Message Broker's msg_broker entry within the OMB Instance, and for queues, topics, and connection factories. When the Oracle Message Broker is running in Local Mode, the JMS Client user requires the same permissions as the MsgBroker Instance User.

Protecting Credentials

Oracle Message Broker encrypts all passwords that it stores in the LDAP Directory. The passwords that are encrypted include: AQServerEntry password, Oracle Wallet password, and passwords used for Oracle Message Broker propagation. This allows administrators to disable LDAP authentication/authorization without compromising the passwords used by Oracle Message Broker.

Oracle Message Broker Security

This section covers the Oracle Message Broker security facilities that allow you to protect Oracle Message Broker connections and Oracle Message Broker data. This section covers the following security areas:

• Oracle Message Broker Connections to Directory Server

• JMS Client Connections to Directory Server

• C++ Client Connections to Directory Server

• JMS Client Connections to Oracle Message Broker

• Propagation Security

• Security Service - Application Level Authentication and Authorization

Oracle Message Broker Connections to Directory Server

The Oracle Message Broker and its administration utilities support SSL for their connections with the LDAP Directory Server. See the section, "LDAP Directory Secure Sockets Layer Connections" for a description of the SSL options available for these directory connections.

JMS Client Connections to Directory Server

JMS Clients support SSL for their connections with the LDAP Directory Server. See the section, "LDAP Directory Secure Sockets Layer Connections" for a description of the options available for these SSL connections.

C++ Client Connections to Directory Server

C++ Clients support SSL for their connections with the LDAP Directory server. See the section, "LDAP Directory Secure Sockets Layer Connections" for a description of the options available for these SSL connections.

JMS Client Connections to Oracle Message Broker

When a JMS Client is connecting to the Oracle Message Broker it can use SSL in one of three authentication modes, as shown in Table 12-4.

Table 12-4  JMS Client SSL Connection Modes

SSL Connection Mode	Description
No authentication	Neither the client nor the Oracle Message Broker authenticates itself. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used. In this case, there is no requirement for certificate management.
One-way authentication	Only the Oracle Message Broker authenticates itself to the client. The Oracle Message Broker sends the client a certificate verifying that the server is authentic.
Two-way authentication	Both client and the Oracle Message Broker authenticate themselves to each other. Both the client and the Oracle Message Broker send certificates to each other.

Note: For one-way or two-way authentication, both the JMS Client and the Oracle Message Broker has to manage certificates using the Oracle Wallet Manager.

Propagation Security

The server-to-server interaction, using Oracle Message Broker propagation, is made secure using IIOP/SSL or HTTP/SSL. A receiving broker authenticates and authorizes a sending broker, if it is configured to do so, while accepting requests for propagation. For details on setting up security for propagation, refer to "Propagation Security".

Security Service - Application Level Authentication and Authorization

The Oracle Message Broker security service support authentication and authorization of Oracle Message Broker clients. The security service allows the Oracle Message Broker to provide an additional level of control for its operations, including controlling whether a particular user can access and use JMS destinations. This level of security uses the LDAP Directory for obtaining names and passwords and storing authentication and authorization information.

Oracle Message Broker uses the security service to provide a finer grained access control mechanism. The LDAP security provides an all-or-nothing access for Oracle Message Broker users. The security service provides more control. For example, the security service allows Oracle Message Broker to distinguish between subscribing to a topic and publishing to a topic, or sending a message to a queue and receiving a message from a queue.

The security service allows Oracle Message Broker administrator to associate access control lists (ACL)s with destinations. The security service uses the LDAP Directory to store its configuration information. The Oracle Message Broker management tools, AdminUtil and ombadmin, are available to manage the security service. The security service configuration information consists of users, groups and ACLs. For details on working with these security service components, refer to "Using the Oracle Message Broker Security Service".

Provider Security

This section describes the Oracle Message Broker provider facilities that allow you to protect messages stored using an Oracle Message Broker driver. Administrators need to manage security features of underlying providers (drivers) using provider specific facilities.

This section covers the following security areas:

• Provider Security Summary

• AQ Driver Security Features

• Provider Security Limitations

Provider Security Summary

The Oracle Message Broker acts a client of the underlying message provider. If the message provider is on a separate machine, the data sent between the Oracle Message Broker and the underlying message provider is sent over the network. Depending on the security requirements, it may be necessary to protect the privacy and integrity of this data. In addition, the underlying message provider may have its own authentication/authorization mechanisms. Table 12-5 shows Oracle Message Broker support for underlying message provider security.

Table 12-5  Message Provider Security in Oracle Message Broker

Provider	Security Available
AQ Driver	Oracle Message Broker uses the username and password specified in the connection factory entry stored in the LDAP Directory. That is the credentials used by the JMS Client to create a JMS connection are used to access AQ. If the username and password are not defined in the connection factory entry then the username and password specified in the JMS call that created the connection are used. The Oracle Message Broker process uses the value of the distinguished attribute as the username. For example, if the username is, cn=bjensen,cn=users then the username used for the AQ connection would be `bjensen'. Both the AQ OCI driver and AQ JDBC driver can be configured for data privacy and integrity using the Oracle 8i advanced security option. This is independent of Oracle Message Broker. See the Oracle 8i administration guide for more information.
Oracle Mcast Driver	Does not provide any message provider specific mechanism for authentication/authorization or for data privacy/integrity.
Tibco Driver	Does not provide any message provider specific mechanism for authentication/authorization.
Volatile Driver	Does not provide any message provider specific mechanism for authentication/authorization or for data privacy/integrity.
MQ Series Driver	Authenticates users using the underlying operating system users/groups. The active Oracle Message Broker and MQ Series must run on the same system. In addition, the user running the Oracle Message Broker process should have permissions to access all the MQ Series queues used by the Oracle Message Broker. The JMS Client credentials are not used to access MQ Series.

AQ Driver Security Features

The AQ Driver authenticates Database Server connections with credentials provided by the following choices:

1. Using LDAP Directory Configuration Options - a user name and password can be provided using the administrative facilities. These credentials are used to authenticate the JDBC connections created to support administrative operations. These credentials are also used to authenticate JDBC connections created for each user's JMS session when the user does not specify a user name and password in the connection methods, as shown in option 2 (below). When credentials are stored in the LDAP Directory, the passwords are always encrypted.

2. Invocation Methods in Oracle Message Broker JMS Clients - a user name and password can be supplied when the Oracle Message Broker JMS Clients create a topic connection or a queue connection. These credentials authenticate the JDBC connection when a JMS session is created within the topic or queue connection.

3. Using Lightweight Configuration Properties, the user name and password are used to authenticate Database Server (AQ Driver) connections.

However the credentials are provided, the user name and password may be used to authenticate access to the LDAP Directory, to make access control decisions for the Oracle Message Broker, and to provide access control to the AQ Driver for message store access.

When the Oracle Message Broker is started with lightweight configuration. The user name and password used by the AQ Driver must either be stored in a file or specified on the command line. The Oracle Message Broker administrator should understand the security risks of both options.

AQ security functionality can be configured external to the Oracle Message Broker by modifying the sqlnet.ora and tnsnames.ora file.

Provider Security Limitations

Several Oracle Message Broker drivers have resources that Oracle Message Broker security facilities cannot protect, including the following:

Oracle Mcast Driver - the IP Address and port number

Oracle AQ Driver - Database Server access using PL/SQL, OCI, or JDBC

MQSeries Driver - Native access to MQSeries Queues

Oracle Message Broker security facilities and access control do not and cannot provide access control for the underlying providers, beyond what the providers have in place for access control.

Security Priority

Oracle Message Broker has three, optional levels of authentication/authorization for JMS Client to Oracle Message Broker interactions.

1. LDAP Directory Authentication and Authorization: A JMS Client must be able to read the LDAP Directory to get access to topics, queues, connection factories, or the Oracle Message Broker. All Oracle Message Broker configuration data is stored in an LDAP Directory (unless Oracle Message Broker is run using Lightweight Configuration). A JMS client must be able to read information from the LDAP Server to access destinations managed by the Oracle Message Broker. Access to this information can be controlled through the use of LDAP authentication and authorization mechanism.

2. Oracle Message Broker Security Service ACLs.

3. Provider Access Control. Once the JMS client has access to the information in the LDAP Directory, it can connect to the Oracle Message Broker. If an Oracle Message Broker destination is mapped to a message provider (such as AQ), then operations on the Oracle Message Broker destination get mapped to operations on the message provider destination. The broker uses the client's credentials to request access from the message provider.

The Oracle Message Broker as a whole uses the following order for assuring security:

1. LDAP Directory Level Authentication and Authorization

2. Oracle Message Broker Security Service ACLs

3. Provider-Level Access Control (for example AQ authentication/authorization)

If security access fails for any reason at a higher level, access is completely denied for the lower level.

Network Security Overview

Oracle Message Broker components can use three protocols for communicating between different components: HTTP, LDAP, and IIOP. All these three protocols can be layered over SSL. SSL provides encryption and optional server/client side authentication. SSL provides Oracle Message Broker with privacy of data over the network, data integrity, and certificate based SSL authentication.

Figure 12-2 shows all the components of an Oracle Message Broker deployment.

Figure 12-2 Overview of Network Security

Figure 12-2 shows components linked with the following four labels:

1. P1 - Connections between client side ORBs and server side ORBs. Oracle Message Broker uses the ORB for communicating between the Oracle Message Broker and JMS Clients. The ORB uses IIOP protocol for communication between the client and the server. The ORB allows one to run IIOP over SSL. For more information, refer to "Oracle Message Broker SSL Options" .

2. P2 - Connections between the LDAP Directory Server and LDAP Clients. LDAP clients are any of the following: the Oracle Message Broker, JMS Clients, Oracle Message Broker administration tools. These connections use LDAP over SSL to the LDAP Directory Server. An SSL socket factory is provided for this purpose. For more information, refer to "Enabling SSL and Authentication for the LDAP Directory" .

3. P3 - Connections between Oracle Message Brokers for propagation using HTTP. Oracle Message Broker supports propagation over HTTP and HTTP over SSL (HTTPS). Oracle Message Broker propagation also supports HTTP proxies. For more information, refer to "Enabling Propagation Security" .

4. P4 - Connections between Oracle Message Brokers and underlying message providers (such as Oracle AQ). Oracle Message Broker supports security provided by the underlying message provider. For more information, refer to "Provider Security Administration" .

Supported Cipher Suites

When you use the Oracle Message Broker, SSL is preconfigured to support a default set of cipher suites. The set of cipher suites supported depends on the SSL level associated with a connection.

A cipher suite is a set of authentication, encryption, and data integrity algorithms used for exchanging messages between network nodes. During an SSL handshake, the two nodes negotiate to see which cipher suite they will use when transmitting messages back and forth.

To establish an SSL connection between a client and a server, the client and the server must have at least one common cipher suite. During the SSL handshake the client and the server agree on the cipher suite to use for the connection.

The Oracle Message Broker supports prioritized cipher suites as shown in Table 12-6 and Table 12-7. These cipher suites support SSL connections to the LDAP Directory, and for propagation between Oracle Message Brokers using HTTPS.

Table 12-6  Authenticated SSL Connections (SSL level 2 and SSL level 3).

Cipher Suite	Priority Level
SSL_RSA_WITH_3DES_EDE_CBC_SHA	1
SSL_RSA_WITH_RC4_128_SHA	2
SSL_RSA_WITH_RC4_128_MD5	3
SSL_RSA_WITH_DES_CBC_SHA	4
SSL_RSA_EXPORT_WITH_RC4_40_MD5	5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA	6

Table 12-7  Un-authenticated SSL Connection (SSL Level 1)

Cipher Suite	Priority Level
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA	1
SSL_DH_anon_WITH_RC4_128_MD5	2
SSL_DH_anon_WITH_DES_CBC_SHA	3
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5	4
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA	5

Note: All the cipher suites shown in Table 12-6 and Table 12-7 provide encryption and data integrity.

LDAP Directory Server Security Administration

This section covers the following security administration areas:

• Creating LDAP Users and Working with Access Control Lists

• Enabling SSL and Authentication for the LDAP Directory

Creating LDAP Users and Working with Access Control Lists

To create LDAP users and groups, and to manage LDAP Directory access control lists for the users and the groups, use the administrative tools supplied with your directory, or use the LDAP command line utilities (ldapadd, ldapmodify, or other commands that modify directory entries).

Before you create users and groups in your LDAP Directory, refer to the section, "LDAP Server Security" for a description of the types of users you may want to create (security roles), and the permissions required to control access to the Oracle Message Broker.

Note: This section describes Oracle Message Broker sample scripts that set up LDAP authentication. Oracle Message Broker administrators should modify these scripts, depending on the security policies needed for their LDAP Directory.

Oracle Internet Directory Authentication Sample Scripts

The Oracle Message Broker provides sample ldif scripts for setting up directory authentication in $OMB_HOME/samples/admin/security/ldap/oid (%OMB_HOME%\samples\admin\security\ldap\oid on Windows NT). Refer to the README file for instructions on running the authentication setup scripts.

Netscape Directory Server Authentication Sample Scripts (Windows NT Only)

The Oracle Message Broker provides sample ldif scripts for setting up directory authentication in $OMB_HOME/samples/admin/security/ldap/netscape (%OMB_HOME%\samples\admin\security\ldap\netscape on Windows NT). Refer to the README file for instructions on running the authentication setup scripts.

Enabling SSL and Authentication for the LDAP Directory

When you use Oracle Message Broker components that access the LDAP Directory, they internally set properties that control simple authentication and SSL, either based on the values supplied in prompts to the user, or based on values supplied with command line arguments. JMS Client programs that access the LDAP Directory and connect with the Oracle Message Broker need to explicitly set these properties.

JMS clients use JNDI to access the configuration information in the LDAP Directory, specifically the connection factories and destinations, therefore a JMS client needs to set JNDI properties to their appropriate values to enable authentication and to provide credentials.Table 12-8 shows the Java properties must be set to enable LDAP authentication and SSL for JMS Client connections.

Table 12-8  Oracle Message Broker Client SSL and Authentication Java Properties

Java Property	Description
java.naming.security.authentication	When the authentication property is set to the value "simple", LDAP authentication is used. If the principal property or the credentials property are not specified, then anonymous directory authentication is used.
java.naming.security.credentials	Use the credentials value to supply a password. where: password is the password associated with the specified user of the username set in the property java.naming.security.principal.
java.naming.security.principal	Use the principal property to provide a user_name_dn. where: user_name_dn is the user's DN in the LDAP Directory. If this is not set an anonymous bind will be used).
java.naming.security.protocol	Set to `ssl' to use SSL connections to the directory.
SSLSocketFactoryImplClass	This property should be set to the following value: oracle.oas.admin.dir.AdminSSLSocketFactoryImpl
oracle.oas.admin.dir.wltloc	Set to the location of the exported wallet that is to be used for SSL authentication. Note: this requires exported wallets.
oracle.oas.admin.dir.wltpassword	Set to the wallet password for the wallet to be used for SSL authentication.

Configuring SSL for OiD

When an instance of OiD is started through the OiD Control Utility, a configuration set entry can be specified. This configuration set entry determines the SSL configuration for that instance of OiD. A configuration set entry can be created/modified/deleted using either Oracle Directory Manager or command line tools. When using Oracle Directory Manager, expand the `Server Management-->Directory Server' entry (this is for non-replicated directory servers, for replication refer to the OiD Administration Manual). This will list all the configuration set entries for the directory server. Add/delete/update operations can be performed on configuration set entries using Oracle Directory Manager (for details on configuration sets refer to the OiD Administration Guide).

Configuration Set entries for LDAP server are stored under the container, cn=osdldapd,cn=subconfigsubentry

The config set entries should belong to the objectclass `orclConfigSet' and `orclLDAPSubConfig', the attribute `orclsslenable' sets (value of 1) or unsets (value of 0) SSL. The attribute `orclsslauthentication' sets the authentication level for SSL (value of 1 => no authentication, value of 32 => server side authentication and value of 64 => server and client side authentication). The attribute `orclsslwalleturl' points to the wallet location and the attribute `orclsslwalletpasswd' contains the value of the wallet password.

Note: Default ACLs in OiD do not protect the subtree cn=subconfigsubentry for read operations. Since this subtree can possibly contain wallet passwords, read operations on this subtree must be protected.

(for replication configuration set entries refer to the OiD Administration Guide)

Sample configuration set entry for SSL without any authentication:

dn: cn=configset1, cn=osdldapd, cn=subconfigsubentry
objectclass: orclConfigSet
objectclass: orclLDAPSubConfig
objectclass: top
cn: configset1
orcldebuglevel: 0
orclsslenable: 1
orclsslport: 636
orclserverprocs: 1
orclsslauthentication: 1
orclmaxcc: 10

Sample configuration set entry for SSL with server side authentication:

dn: cn=configset2, cn=osdldapd, cn=subconfigsubentry
objectclass: top
objectclass: orclConfigSet
objectclass: orclLDAPSubConfig
orclmaxcc: 10
orcldebuglevel: 0
cn: configset2
orclsslauthentication: 32
orclsslenable: 1
orclsslport: 6666
orclsslwalletpasswd: welcome88
orclsslwalleturl: file:/private/oracle/product/oracle/8.1.6/wallets/test_wallet1
orclserverprocs: 1

Sample configuration set entry for SSL with server side and client side authentication:

dn: cn=configset3, cn=osdldapd, cn=subconfigsubentry
orclsslport: 7777
objectclass: orclConfigSet
objectclass: top
objectclass: orclLDAPSubConfig
cn: configset3
orcldebuglevel: 0
orclmaxcc: 10
orclsslauthentication: 64
orclserverprocs: 1
orclsslenable: 1
orclsslwalleturl: file:/private/oracle/product/oracle/8.1.6/wallets/test_wallet1
orclsslwalletpasswd: welcome88

OiD Access Control and Authorization

Authorization is the process of ensuring that a user reads or updates only the information for which that user has privileges. When directory operations are attempted within a directory session, the directory server ensures that the user, identified by the authorization ID associated with the session, has the requisite permissions to perform those operations. Otherwise, the operation is disallowed. Through this mechanism, the directory server protects directory data from unauthorized operations by directory users. This mechanism is called access control. Access Control Information (ACI) is the directory meta data that captures the administrative policies relating to access control. ACI is stored in Oracle Internet Directory as user-modifiable operational attributes. Typically, a list of these ACI attribute values, called an Access Control List (ACL), is associated with directory objects. The attribute values on that list govern the access policies for those directory objects. ACIs are represented and stored as text strings in the directory. These strings must conform to a well defined format. Each valid value of an ACI attribute represents a distinct access control policy. These individual policy components are referred to as ACI Directives or ACI Items and their format is called the ACI Directive format.

orclACI is a user modifiable optional attribute that represents Access Control List (ACL) policy information for a subtree starting with the entry where that subtree is defined. Any entry in the directory can contain values for this attribute. Access to this attribute itself can be controlled the same way access to any other attributes is controlled. Access Control Policy Points (ACPs) are entries in which the orclACI attribute value is set. The orclACI attribute value represents the access policies inherited by a subtree of entries starting with the ACP as the root of the subtree. When a hierarchy of multiple ACPs exists in a directory subtree, the subordinate entries in that subtree inherit the access policies from all of the ACPs that are superior to the entry. The resulting policy is an aggregation of the policies within the ACP hierarchy above the entry. When there are conflicting policies represented among a hierarchy of ACPs, the directory applies well defined precedence rules while evaluating the aggregate policy.

The orclACI attribute contains ACL directives that are prescriptive in nature, that is, the directives apply to all entries in the subtree below the ACP where this attribute is defined. In addition, it is often convenient to maintain ACL directives specific to a single entry within that entry. Oracle Internet Directory enables you to do this through a user modifiable operational attribute called orclEntryLevelACI. Any directory entry can optionally carry a value for this attribute. This is accomplished in the Oracle Internet Directory base schema by extending the abstract class top to include orclEntryLevelACI as an optional attribute. The orclEntryLevelACI attribute is multivalued and has a structure similar to that of orclACI.

Access Control Information associated with a directory object represents the permissions on the given object that various directory user entities (or subjects) have. Thus, semantically, an ACI is a tuple consisting of three components: Object (to what are you granting access?), Subject (to whom are you granting access, Operations (what access are you granting?).

Example of ACIs set on the container cn=omb:

dn: cn=OMB,cn=Products,cn=OracleContext,ou=asg,o=oracle,c=us
objectclass: top
objectclass: orcloasentry
objectclass: orclcontainer
cn: OMB
orclaci: access to attr=(*) by * (search , read, nowrite, compare) by group= 
"cn=ombdev,cn=groups" (search, read, write, compare)
orclaci: access to entry by * (browse, noadd, nodelete) by group= 
"cn=ombdev,cn=groups" (browse, add, delete)
orcloasentrytype: omb_container

Creating users and groups in OiD

A user of OiD (other than cn=orcladmin, cn=guest and cn=proxy) is the DN of the entry in the directory. This entry should have the attribute, `userpassword'. For example,

dn: cn=bjensen,cn=users
objectclass: top
objectclass: person
cn: bjenson
sn: Jensen
userpassword: welcome

The username is "cn=bjensen,cn=users" and the password is "welcome".

Group entries in Oracle Internet Directory are associated with either the `groupOfNames' or the `groupOfUniqueNames' objectclass. Membership in the group is specified as a value of the `member' or `uniqueMember' attribute respectively. It is possible to specify access rights for a group of people or entities. Such groups are called privilege groups and are associated with the `orclPrivilegeGroup' object class. To grant access rights to a group of users, one has to create a group entry in the usual way, then associate it with the `orclPrivilegeGroup' object class. The access policies applicable to that group are then specified. Entries can have either direct memberships to groups, or indirect memberships to other groups by means of nested groups, thus forming a forest of privilege groups.

Access policies specified at a given level are applicable to all the members directly or indirectly below it. Because Oracle Internet Directory evaluates for access control purposes only groups marked as privilege groups, it does not allow setting access policies for non-privilege groups. When a user binds with a specific DN, Oracle Internet Directory computes his or her direct membership in privilege groups. Once it knows the first level groups for the given DN, Oracle Internet Directory computes nesting of all these first level groups into other privilege groups. This process continues until there are no more nested groups to be evaluated. It is imperative that all groups created for access control purposes, nested or otherwise, be marked as privilege groups by associating them with the `orclPrivilegeGroup' object class. A normal group will not be considered for access control purposes even though it may be a member of a privilege group. Example of a group,

dn: cn=ombdev,cn=groups
objectclass: top
objectclass: groupofnames
objectclass: orclprivilegegroup
cn: ombdev
member: cn=bjensen,cn=users
member: cn=akarmark,cn=users

Oracle Message Broker Security Administration

This section covers the following security administration areas:

• Oracle Message Broker SSL Options

• Enabling Propagation Security

• Using the Oracle Message Broker Security Service

Oracle Message Broker SSL Options

The Oracle Message Broker commands, including the following commands support a set of options to control SSL: AdminUtil, AdminDirCheck, MsgBroker, LDAPSchema, and InitDir. Table 12-9 describes the command line options that control SSL.

If the -U2 or -U3 option is used with the commands, and the -W or -P is not used, then the Oracle Message Broker commands prompt for the SSL wallet directory, the SSL wallet password, or for both.

Note: These options specify SSL connections to the LDAP Directory.

Table 12-9  SSL Command Line Options

Option	Description
-U value	Specifies if SSL is used, and the authentication level. Valid values are: 0, 1, 2, and 3. 0 - no SSL. This is the default if -U is not specified. 1 - SSL with no authentication. 2 - SSL with server-side authentication. 3 - SSL with server-side and client-side authentication.
-W wallet_path	Specifies the path to an exported wallet file. This is ignored if the value of -U is 0 or 1.
-P wallet_password	Specifies the wallet password. This is ignored if the value of -U is 0 or 1.

Graphical Command SSL Options

When ombadmin starts, you need to enter an SSL level. Table 12-10 shows the SSL levels supported for ombadmin.

Table 12-10  SSL Levels for ombadmin

SSL Level	Description
none	No SSL
noauth	SSL with no authentication
server auth	SSL with server-side authentication
server and client auth	SSL with server-side and client-side authentication

Enabling Propagation Security

See the section, "Propagation Security" for information on propagation security.

Using the Oracle Message Broker Security Service

The Oracle Message Broker security service provides authentication and authorization to control whether a user can access JMS destinations. This level of security uses the LDAP Directory to obtain names and passwords and for storing authentication and authorization information.

This section covers the following:

• Managing Users

• Managing Groups

• Managing Access Control Lists (ACL)s

• Security Service Cache

• Netscape Directory Password Encryption

• Client Connections using Authentication and Authorization

The security service allows the Oracle Message Broker administrator to associate access control lists (ACL)s with destinations. The Oracle Message Broker management tools, AdminUtil and ombadmin, are available to manage the security service. The security service configuration information consists of users, groups and ACLs that are stored in the Users, Groups, and ACLs fixed name containers (see Figure 12-3).

The users, groups, and ACLs defined are not tied to a specific OMB Instance. They can be used across all OMB Instances defines within the LDAP Directory.

Figure 12-3 Top Level Directory Organization with Users, Groups, and ACLs Containers

Managing Users

A user for the Oracle Message Broker security service consists of a DN, which represents a user entry. Authentication consists of looking up the DN and matching the password attribute.

Since the user entry is a DN, standard LDAP user entries and the Oracle Message Broker security service user entries are both valid user entries. The security service has the same requirements for a user entry as an LDAP server. Using LDAP server user entries as security service user entries can reduce the number of administration tasks.

An LDAP user can be used as an Oracle Message Broker user. However, the Oracle Message Broker tools, AdminUtil and ombadmin can only modify Oracle Message Broker user entries (these are defined as user entries under the cn=users container in the OMB entry in the LDAP Directory).

Table 12-11 shows the user entry attributes. To configure a user entry, create the user entry and then set the appropriate attributes.

Table 12-11  User Attributes

Attribute	Description
description	A description of the user.
password	Password associated with the user. This value is encrypted. This attribute is mapped to the LDAP attribute userpassword. The LDAP server controls whether this attribute is encrypted.
surname	The user's surname.

Managing Groups

A group entry specifies an Oracle Message Broker group. Table 12-12 shows the group entry attributes. To configure a group, create the group entry and then define the appropriate attributes.

Oracle Message Broker group entries are not always LDAP group entries. However, LDAP group entries are valid to use as Oracle Message Broker group entries (when using either LDAP as provided by Oracle Internet Directory or Nestscape Directory Server).

Table 12-12  Group Attributes

Attribute	Description
description	A description of the group.
uniquemember	This is a DN that points to a user entry, or to multiple user entries. The value can also point to other groups. A group cannot have nested subgroups that include more than 10 levels of nesting.

Managing Access Control Lists (ACL)s

Destinations have an optional attribute called acl_dn (see Table 4-17 and Table 4-18 for destination attributes). The acl_dn value is a DN which points to an LDAP ACL entry containing security service configuration information. Oracle Message Broker security service authorization is based on checking the ACL associated with the destination (to which access is requested).

ACL entries are stored in the ACLs container in the LDAP Directory.

Table 12-13 shows the ACL entry attributes. To configure an ACL entry, create the entry and then define the access control list.

Table 12-13  Access Control List (ACL) Attributes

Attribute	Description
aclEntry	Defines the access control list, with a value of the form DN=num (see the explanation below for details).

The value for an aclEntry is of the form:

DN=num

Where:

DN is the DN for a group, a user, or is the string `anonymous'.

num is the permission associated with the user or group, or for the anonymous user.

Table 12-14 shows the possible values for the aclEntry permission, num.

Table 12-14 ACL Entry Permissions

Value	Permissions
1	Read access. For topics, read access implies granting subscription rights. For queues, read access implies granting receive rights.
2	Write access. For topics, write access implies granting publication rights.For queues, write access implies granting send rights.
3	Read and write access.

If an ACL is not specified for a destination, topic or queue, the destination is open, and anyone can subscribe/publish or send/receive messages for that destination.

If an ACL is specified, but no users are given permissions in the ACL, then no one can subscribe/publish or send/receive messages for that destination. This means permissions in an ACL have to be explicitly granted. For example, if permission for a user cn=foo, or a group that user cn=foo belongs to, is not granted in the ACL, it implies that the permission is denied for that user (also see the description of the anonymous ACL for information on granting permissions to everyone).

For example, an aclEntry could have the following value:

cn=group1,cn=Groups,cn=OMB,cn=Products,cn=OracleContext,ou=name1,o=acme,c=us=3

This specifies that all the users in the group defined by group1 have read and write access to the destination.

If an aclEntry is specified, and the DN value is specified as the string, "anonymous", then everyone, that is any user, is given the permissions specified for the anonymous aclEntry. When a user attempts to use the destination, and either a user name is supplied, or a user name is not supplied, the user is granted the permissions to the destination that are associated with anonymous. In this case, permissions in an aclEntry do not have to be explicitly granted by user or group.

For example, an aclEntry could have the following value:

anonymous=1

For this example, the permission for anonymous is set to 1, which grants receive or subscribe permission for all of the destination's users.

Security Service Cache

The Oracle Message Broker caches security service related LDAP data. This cache is per JMS connection. The Java property oracle.oas.mercury.sec.cache.expiration specifies the cache expiration time in milliseconds.

Table 12-15 Security Service Java Properties

Java Property	Description
oracle.oas.mercury.sec.cache.expiration	Specifies the cache expiration time in milliseconds. If the value < 0, then the cache never expires. The default value is -1

Netscape Directory Password Encryption

The Netscape directory server allows passwords to be encrypted, using SHA or unix crypt, or passwords may be unencrypted. If the passwords are encrypted, the security service needs to perform a heavy-weight ldap_bind operation (and create a new tcp/IP connection) to verify passwords.

If Netscape directory server is used with password encryption, the default setting, then the property oracle.oas.security.nocompare should be set to true. If this property is not set for Netscape directory server, with password encryption enabled, then the Oracle Message Broker always throws a SecException.

Client Connections using Authentication and Authorization

To access the Oracle Message Broker, a JMS client has to create a JMS connection to the Oracle Message Broker.

There are four JMS APIs to do this:

1. To create an anonymous topic connection to the Oracle Message Broker, use:

   TopicConnectionFactory.createTopicConnection() 
   
   

2. To create an anonymous queue connection to the Oracle Message Broker, use:

   QueueConnectionFactory.createQueueConnection() 
   
   

3. To create a non-anonymous topic connection to the Oracle Message Broker, use:

   TopicConnectionFactory.createTopicConnection(String username, String 
   password)
   
   

4. To create a non-anonymous queue connection to the Oracle Message Broker, use:

   QueueConnectionFactory.createQueueConnection(String username, String 
   password)
   

If TopicConnectionFactory.createTopicConnection() or QueueConnectionFactory.createQueueConnection() are used, then the connections are treated as anonymous.

The username provided in (2) and (4) above should be a DN of a security service user entry or an LDAP user entry and the password must be the password for the specified user.

Oracle Message Broker uses the security service to authenticate a user. On a successful authentication, the Oracle Message Broker gets a `ticket' from the security service for the specified credentials. The credentials are cached on the client side runtime and the Oracle Message Broker. The Oracle Message Broker also caches the ticket. The client side runtime sends these credentials to the Oracle Message Broker when requesting any operation using this connection. The Oracle Message Broker authenticates the credentials in memory, without using the security service, and then uses the security service to authorizes the client request using the cached ticket.

JMS client credentials are per connection. A new connection should be created for different credentials. The Oracle Message Broker also uses the same credentials when it calls the client-side callbacks.

Any authentication or authorization error results in a JMSSecurityException being thrown.

To use SSL connections to the directory an SSL socket factory is provided. For details on the properties to set to use LDAP authentication/authorization and SSL connections to the directory refer to "Enabling SSL and Authentication for the LDAP Directory".

Caching of tickets results in a performance improvement, as this avoids a round trip to the LDAP server. ACL information is not cached, so any change in the ACL associated with a destination will be seen by the Oracle Message Broker immediately.

Note: Since the credentials (username/password) used by security service are stored in the directory credentials used for directory authentication can also be used for security service (in methods (2) and (4) above).

Provider Security Administration

This section covers the following security administration areas:

• Client Connections to the Oracle Message Broker using Authentication

Client Connections to the Oracle Message Broker using Authentication

To access the Oracle Message Broker, a JMS client has to create a JMS connection to the Oracle Message Broker.

There are four JMS APIs to do this:

1. To create an anonymous topic connection to the Oracle Message Broker, use:

   TopicConnectionFactory.createTopicConnection() 
   
   

2. To create an anonymous queue connection to the Oracle Message Broker, use:

   QueueConnectionFactory.createQueueConnection() 
   
   

3. To create a non-anonymous topic connection to the Oracle Message Broker, use:

   TopicConnectionFactory.createTopicConnection(String username, String 
   password)
   
   

4. To create a non-anonymous queue connection to the Oracle Message Broker, use:

   QueueConnectionFactory.createQueueConnection(String username, String 
   password)
   

The Oracle Message Broker passes the username and password specified in the non-anonymous methods to the Driver to authenticate the JMS client.

These credentials are cached by the client-side runtime and reused for all subsequent calls made on the connection.

If TopicConnectionFactory.createTopicConnection() or QueueConnectionFactory.createQueueConnection() are used, then the connections are treated as anonymous.

JMS client credentials are per connection. A new connection should be created for different credentials. The Oracle Message Broker also uses the same credentials when it calls the client-side callbacks.

Any authentication or authorization error results in a JMSSecurityException being thrown.

To use SSL connections to the directory an SSL socket factory is provided. For details on the properties to set to use LDAP authentication/authorization and SSL connections to the directory refer to "Enabling SSL and Authentication for the LDAP Directory".