Oracle Message Broker Adminstration Guide Release 2.0.1.0 Part Number A65435-01 |
|
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:
Figure 12-1 shows the components of a sample Oracle Message Broker deployment.
To implement its security features, the Oracle Message Broker supports security in the following areas:
In addition, the Oracle Message Broker supports the following security features:
Secure Sockets Layer (SSL) is an industry standard protocol for securing network connections. SSL provides:
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
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:
Furthermore, to ensure Oracle Message Broker security, the application programmer is responsible for making the correct JNDI and JMS API calls.
The following components can be configured independent of each other:
ldapsearch
/ldapmodify
and/or oidadmin
can be used for this purpose.
ldapsearch
/ldapmodify
and/or oidadmin
can be used for this purpose.
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:
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.
This section covers the following:
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.
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:
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.
The following Oracle Message Broker components use LDAP Authentication when they contact the LDAP Directory:
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.
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:
|
|
|
|
|
|
|
JMS Client Programs |
|
|
|
Oracle Message Broker Installation Guide |
|
|
Oracle Message Broker Installation Guide |
|
|
|
|
|
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.
ACLs are stored as special operational attributes of an entry. ACLs are inherited by an entry from its parents and can be overridden.
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.
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.
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.
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.
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:
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 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++ 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.
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.
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".
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".
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:
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.
The AQ Driver authenticates Database Server connections with credentials provided by the following choices:
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.
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.
Oracle Message Broker has three, optional levels of authentication/authorization for JMS Client to Oracle Message Broker interactions.
The Oracle Message Broker as a whole uses the following order for assuring security:
If security access fails for any reason at a higher level, access is completely denied for the lower level.
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 shows components linked with the following four labels:
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.
Note: All the cipher suites shown in Table 12-6 and Table 12-7 provide encryption and data integrity. |
This section covers the following security administration areas:
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.
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.
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.
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.
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
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
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
This section covers the following security administration areas:
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.
When ombadmin starts, you need to enter an SSL level. Table 12-10 shows the SSL levels supported 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 |
See the section, "Propagation Security" for information on propagation security.
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:
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.
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.
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).
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.
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.
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.
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.
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 |
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.
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:
TopicConnectionFactory.createTopicConnection()
QueueConnectionFactory.createQueueConnection()
TopicConnectionFactory.createTopicConnection(String username, String password)
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.
This section covers the following security administration areas:
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:
TopicConnectionFactory.createTopicConnection()
QueueConnectionFactory.createQueueConnection()
TopicConnectionFactory.createTopicConnection(String username, String password)
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".
|
![]() Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|